design: AppType is str-valued with 1,004 port=-1 members, unlike its int-valued sibling registries

[JarryShaw]

The question

AppType is structurally unlike its sibling registries, and 12.3% of its members carry no port. Raised by the maintainer: should the -1 entries be discarded, and should AppType be represented the way the other registries are — a name → code-number mapping?

Measured

	AppType	TransType	LinkType
members	8,182	151	220
enum value type	str — 'argus [-1 - undefined]'	int	int
aliases	1,919	—	—

Of the 8,182 declarations in pcapkit/const/reg/apptype.py, 1,004 declare port -1 and 7,178 a real port. The -1 group by transport: undefined 580, tcp 300, tcp|udp 64, udp 57, dccp/tcp|sctp/tcp|udp|sctp 1 each. Examples: argus, arp, bbn-rcc-mon, bootp, br-sat-mon, cftp, chaos, clock — several read as IP-protocol names rather than TCP/UDP services.

Why it matters beyond tidiness

• Profile by self time: aenum.extend_enum is 16.7% of extraction, dispatch and imports under 1% #575: extend_enum's cost is linear in the target enum's current member count (measured getattr = members + 4). At 8,182 members every AppType extension is ~40–200× a normal const enum. Dropping the -1 group alone is 8,182 → 7,178.
• fix(docs): stop AppType shadowing six builtins in cross-references #724 — and this is the negative worth stating: dropping them does not fix the builtin-name collisions. Only help (-1) is in that set; dict (2628), exec (512), max (6074), set (257) and sum (6551) all have real ports. fix(docs): stop AppType shadowing six builtins in cross-references #724's fix is needed either way.

Open questions for whoever picks this up

1. Where do the -1 entries come from in the IANA source, and is an entry with a real transport but no port meaningful?
2. Is the formatted str value load-bearing, or incidental? TransType/LinkType prove an int value works for a registry.
3. Would a name → port mapping keep _missing_'s contract and the wire round-trip intact?

Not filed as a defect — nothing is incorrect today. Discarding registry members is a compatibility decision.

[JarryShaw]

1. those -1 entires where likely from when a CSV line does not actually have a port assigned. my take on this is that, we might actually consider dropping them from the Enum class, or preferably, keep comment line about this entry but do not assign actual values or a sentinel value like NotAssigned object, similar to NoValue in Schema.
2. I kinda prefer we move to int based Enums, which might need us to split the AppType class into multiple different ones based on the transport layer protocols. Worth consider subclassing from an abstract AppType Enum which holds shared useful data - for both const and vendor.
3. I say we should keep the _missing_ and extend_enum behaviour as in other Enum classes in this library.

[JarryShaw]

Measured against 1aae1da30. Recommendation, blast radius, PR order, then what I could not settle.

Recommendation

1. -1 — drop from the enum, emit as generated comments. A NotAssigned sentinel is unavailable for three independent reasons: AppType is a StrEnum and aenum rejects a non-str value (TypeError: values must be str); under IntEnum all 1,004 share value -1 so they become 1 member + 1,003 aliases, and an alias loses its own name (AppType.arp.name would read argus); and tests/const/test_const_enum_builtin_parity.py:225 already requires every registry to reject -1 with ValueError (#647) — a member valued -1 resolves instead and fails it. The NoValue analogy inverts rather than holds: NoValueType (corekit/fields/field.py:26-36) overrides only __bool__, is always tested with is, and schema.py:409-411 deliberately discards it — "never be a value" is the one job a member value cannot do. Your CSV reading is confirmed: vendor/reg/apptype.py:255 (port = item[1].strip() or '-1') is the sole origin, ranges go to _missing_ instead. They sit in one contiguous tail (decls 7162–8181) broken by exactly 16 _null split-partners, and none of the 1,004 names is referenced anywhere in pcapkit/, tests/ or docs/.

2. Split: yes — but int only after the -1 rows are gone. One decision, not two. With -1 present an int split demotes 537 members to aliases; drop them first and it is 50, all genuine same-port collisions. Aliasing then picks IANA's first row where __members_proto__ picks the last-declared, so get(80, tcp) goes www-http → http, 3478 → stun, 113 → ident. Three fixes, but 1701 (l2tp→l2f) and 2049 (nfs→shilp) are regressions — so this wants an explicit ~23-port preference list, not file order. Five classes, not four: 704 members carry no transport and _missing_ already treats __members_proto__[undefined] as a shared fallback tier, so keep AppTypeUndefined. Multi-transport services get duplicated into each class they name; the alternative (one primary class) leaves 85% of UDP unreachable from AppTypeUDP.

3. _missing_/extend_enum kept — and the split moves AppType closer to the house pattern, not further: it becomes an IntEnum keyed on the registry code like its 111 siblings, and three of its four current deviations dissolve. _missing_ inherits from the base with no per-class redeclaration (verified).

The abstract base is possible

aenum 3.1.17 refuses subclassing only when base._member_names_ is non-empty anywhere in the MRO, so a memberless base holding __new__, _missing_, .svc/.port/.proto and get() is freely subclassable, and isinstance(x, AppTypeBase) salvages all 7 existing isinstance sites. Three fragilities, each cheap to pin:

• a bare public constant on the base becomes a member and kills subclassability — wrap in nonmember(); a bare public str fails at class creation; __dunder__ is auto-skipped but single-underscore _proto is not;
• extend_enum(base, …) succeeds and permanently bricks every not-yet-imported subclass, so _missing_ must pass cls — today's get is a staticmethod hardcoding AppType, which is exactly that shape;
• a mutable class attribute is shared by all subclasses, so __members_proto__ cannot move up as-is.

Corrections to the issue

stated	measured
1,919 aliases	0 aliases. 1,919 is 8,182 − 6,263 distinct .port values — a port-duplicate count. Nothing equals 8,182+1,919
LinkType 220	220 __members__, 219 canonical (IPMB_LINUX/I2C_LINUX both 209)
set() collapses via the formatted str	all 8,182 values are distinct — the string is what keeps them canonical. The collapse is __eq__/__hash__ on .port (apptype.py:122,128): set() over all members gives 6,263, and only the -1 subset gives 1
the split is the #575 win	~20%. tcp|udp is 5,295 members (65%) and lands in both big classes — TCP 6,513, UDP 6,265, placements 13,586 (+66% duplication). extend_enum is 99.4% of an unknown-port get (3,065 µs; the 767-branch _missing_ scan is 17 µs), so 8,182→6,513 is 1.26×. Splitting also roughly doubles import cost, and apptype is already 162 ms of pcapkit's 640 ms. Partitioning is not the #575 lever; not minting for ephemeral ports is, as corekit/fields/numbers.py:546 already argues

Blast radius — 146 lines across 33 files outside the generated enum

8,346 matched lines total, 8,200 inside apptype.py. Two break silently, and they are the ones to weigh:

• dumpkit/common.py:263-270 — addon is built from the instance __dict__, and AppType is the only registry whose svc/port/proto are instance attributes. Int members have an empty __dict__, so "srcport": {"svc": "www-http", "port": 80, …} becomes the bare string "AppTypeUDP::www_http [80]" in json, tree, text, txt, plist and xml for every TCP/UDP/SCTP packet.
• registry/protocols.py:831-854 — one register_apptype(AppType.www_http, X) writes both TCP.__proto__[80] and UDP.__proto__[80] off code.proto. A split member cannot carry a multi-bit flag, so it reaches one transport and UDP/80 quietly falls to Raw. Pinned by tests/foundation/registry/test_protocols.py:463-469.

Then: 3 near-duplicate PortEnumField classes (schema/transport/udp.py:22, tcp.py:346, sctp.py:175), all deletable since EnumField is already typed for an IntEnum namespace and they exist only because AppType(int) does not work; 7 isinstance sites; _make_port (transport/transport.py:159-186), whose proto argument becomes dead; ~60 annotations across protocols/{data,schema,transport}/; toolkit/{pcap,pcapng}.py .port reads; 6 re-export levels; 3 generic sweeps whose pinned counts all move (test_const_enum_builtin_parity.py:219-223, test_const_enum_get.py:212, test_const_enum_lookup.py:198); and the crawler, where process() builds the proto flag by string concatenation (vendor/reg/apptype.py:287-297) so a split cannot parse it back out — the widest-blast-radius change in the migration. Vendor.__init__ needs no change: N classes in one file is already how TransportProtocol and AppType coexist, so the pinned 117-module count holds.

Good news: every call site already knows its transport. _make_port(port, proto) takes it as a required argument, all six callers pass a literal, each PortEnumField.post_process hardcodes its own. The split deletes a parameter rather than threading a new one.

breaking: yes. AppType is top-level public (pcapkit/__init__.py:107 puts APPTYPE in __all__). The shape that decides it is correct, unchanged code that keeps running and returns different data: json.load(...)['udp']['srcport']['port'] → 80 today, TypeError after.

PR sequence

#	PR	contains	needs
1	fix(reg)	get's string path: __members_proto__ → __members__ at :30620; stop except ValueError bypassing its own 0..65535 guard	nothing — ship now
2	fix(reg)	explicit preference for the ~23 colliding ports, so get(80, tcp) is http not www-http	nothing — independently valuable
3	refactor(vendor)	process() accumulates the proto as a normalised set instead of concatenating text; drops tcp|tcp|udp|udp (86 members) and undefined|undefined	nothing
4	feat(reg)!	drop the 1,004 -1 members, emit as comments (the continue is already commented out at vendor/reg/apptype.py:301-309); re-pin the sweep counts	3
5	refactor(reg)	memberless AppTypeBase, still one subclass — _missing_/__new__/accessors move up, constants nonmember()-wrapped, __members_proto__ per-subclass	3
6	fix(dumpkit)+fix(registry)	make consumers shape-agnostic before the split: render_enum reads accessors not the instance __dict__; register_apptype fans out over an explicit transport set	5
7	feat(reg)!	the split — 5 int-valued per-transport classes; 3 PortEnumFields collapse to EnumField; _make_port's proto and __members_proto__ die	4, 5, 6
8	docs	5 autoclasses, pep.rst:293-297's "out of 8182", reg.rst's list-table	7

1–3 need none of the design settled. 4 is the one needing your ruling; 5 is safe to land even if the split is never taken, since it deletes nothing.

It does not fix #724

Member names stay service names, so dict, exec, help, max, set, sum remain members and a bare dict in a :type: field still suffix-matches. Your reading is right — dict 2628 (:9784), exec 512 (:1946), max 6074 (:20004), set 257 (:1096), sum 6551 (:20734), and help -1 (:28619) is the only one of the six at -1. After a split, #724's :no-index: needs applying to 5 autoclasses instead of 1, so the split makes it slightly more work, never less. One addition: the crawler already has a keyword policy (async → async_, :27895) but none for builtins — the six are a gap in an existing policy, not an absent one.

Found broken, and not settled

• AppType.get(<str>) is dead for every existing name. :30620 tests key in __members_proto__, keyed by TransportProtocol, so a str never matches and it re-registers: AppType.get('http') → TypeError: 'http' already in use. Worse, where the collision-suffix branch freed the bare name it silently mints junk — AppType.get('ssh') returns a new member with port -1, not 22. That is PR 1; fix it once rather than copy it into 5 classes.
• 1,116 __members_proto__ registrations are silently overwritten today (579 undefined, 391 tcp, 145 udp): __new__ assigns with no collision check, which is why port 80 resolves to www-http.
• AppType(80) raises ValueError today — only values inside the 767 hardcoded spans resolve. An int split makes it succeed, flipping the try/except ValueError fallback in EnumField.post_process.
• vendor/reg/apptype.py:216-221 count() keys the Counter '[tcp] http' while Vendor.rename looks up bare 'http', so the dedup path is dead but for the hardcoded RESERVED/UNASSIGNED branch. Pre-existing; worth its own issue.
• Yours to call, not mine to measure: whether the ~23-port preference list follows IANA row order or is hand-curated, and whether the 1,004 dropped rows should also ship as an importable dict[str, TransportProtocol] rather than comments alone.

[JarryShaw]

Correction to this issue's body: AppType has ZERO aliases, not 1,919. All 8,182 members are canonical — len(__members__), len(_member_names_), len(list(AppType)) and the count of distinct _value_ strings are all 8,182.

My 1,919 was 8,182 − 6,263, which is members minus distinct .port values — a different quantity, and the pairing "8,182 members / 1,919 aliases" was internally inconsistent since nothing sums to 10,101.

I also mis-attributed the mechanism. The set() collapse to 6,263 is caused by the overridden __eq__/__hash__ on .port (pcapkit/const/reg/apptype.py:122,128), not by the formatted value string — the string is what keeps all 8,182 canonical. That matters because the original wording sends a reader to the wrong line.

Two consequences for the design:

• Alias behaviour becomes a new problem under int, not an existing one. With the 1,004 -1 rows present, an int-valued split demotes 537 members to aliases; drop them first and it is 50. The current StrEnum has none.
• The formatted str value is load-bearing, but only as the workaround that keeps rows canonical while __eq__/__hash__/__int__ behave like the port.

Also correcting one figure from my earlier comment: LinkType has 220 members / 219 canonical — one real alias, IPMB_LINUX/I2C_LINUX both at 209. That is the case which pins extend_enum's cost as len(cls.__members__) + 4 rather than a count of values.

[JarryShaw]

Module/folder layout preference: pcapkit.{const,vendor}.reg.apptype.{tcp,udp,dccp,sctp}.{TCP,UDP,DCCP,SCTP} for each of the transport layer protocol's registry. discard the old pcapkit/{const,vendor}/reg/apptype.py. we might wanna create a pcapkit.{const,vendor}.reg.apptype.apptype.AppType base class for those transport layer registry to inherit.

For non-assigned ports, either sentinel value like NotAssigned or just generacted cosmetic comment lines (even better, in the Enum's docstring as a list-table so that they can be properly documented in the Sphinx doc through autodoc extension).

For non-assigned protocols, maybe keep in the base class with the same handling.

[JarryShaw]

Design decisions — recorded

Maintainer's rulings, consolidated so the plan has one place to read them from.

Layout. pcapkit.{const,vendor}.reg.apptype.{tcp,udp,dccp,sctp}.{TCP,UDP,DCCP,SCTP} — the file becomes a package, one module per transport. The old pcapkit/{const,vendor}/reg/apptype.py is discarded.

Base class. pcapkit.{const,vendor}.reg.apptype.apptype.AppType, holding only _missing_ and __dunder__ methods — no members. That constraint is load-bearing, not stylistic: aenum refuses to subclass an Enum that has any members —

class TCP(WithMembers): http = 80
-> TypeError: <aenum 'TCP'> cannot extend <aenum 'WithMembers'>

A memberless base subclasses fine and isinstance(TCP.http, AppType) holds, which preserves all 7 existing isinstance sites.

Unassigned ports (port == -1, 1,004 members). Not enum members. Rendered as a list-table in the owning registry's docstring so autodoc documents them. Rules out the NotAssigned sentinel, which was independently unavailable: aenum rejects a non-str value in a StrEnum, an IntEnum collapses all 1,004 to one member plus 1,003 aliases, and test_const_enum_builtin_parity.py already requires every registry to reject -1 (#647).

Undefined-transport ports (704 members). Same treatment, in the base class docstring. No dedicated registry.

_missing_ / extend_enum. Unchanged, matching the library's other registries.

Measured consequences of the last two

Of the 704 undefined-transport members, 580 also have port == -1 and 124 carry a real port — reserved_51, unassigned_81, unassigned_100, unassigned_114, … mostly IANA reserved/unassigned buckets.

Those 124 lose runtime resolution, and it is a real behaviour change rather than a no-op: apptype.py:30636 currently consults __members_proto__[undefined] as a fallback tier when the transport-specific lookup misses. So get(51, proto=tcp) resolves to reserved_51 today and would mint PORT_51_tcp afterwards. The only caller is pcapkit/protocols/transport/transport.py:165, which always passes a transport — so nothing reaches these members directly, only through that fallback.

Not a blocker; it does mean the split PR should state the fallback change explicitly rather than let it surface as a diff in parsed output.

Deferred here: #734 (the get(name) defect — both files are discarded by this design) and, pending a final call, #724.

[JarryShaw]

Two open defects this redesign must answer

Recording these as acceptance criteria rather than leaving them implicit. Both are live, both were deferred here, and neither is fixed by the layout decision alone.

#717 — bare dict in a :type: field resolves to an IANA service. PR #724 was closed unmerged because it edited docs this redesign rewrites, but the defect stands. The split fixes four of six collisions by accident, because Sphinx resolves silently only when exactly one target matches:

collision	port	proto	after the split
dict / max / set / sum	2628 / 6074 / 257 / 6551	tcp|udp	2 targets → warns, renders unlinked
help	−1	undefined	gone with the unassigned rows
exec	512	tcp	1 target → still resolves silently

So exec needs an explicit answer. The mechanism that works, found while fixing #724: :no-typesetting: on a hand-written .. py:class:: stub (sphinx/directives/__init__.py:59,299-313). :no-index: and :no-index-entry: both share one options object across autodoc's recursive member walk, so class-indexed/members-unindexed is impossible via a single autoclass.

#734 — AppType.get(<name>) never matches an existing member and silently mints a port=-1 one. Three requirements the new lookup must satisfy, none derivable from the layout:

• Key the name lookup on .svc, not __members__ — members are stored under suffixed attribute names (ssh_22), so the obvious fix does not work.
• State a tie-break for the 37 .svc names carrying two or more genuinely distinct real ports (admind 3279/8403, contentserver 454/3365, creativepartnr 455/3366, …). Picking arbitrarily reintroduces the same silent-wrong-data defect on different input.
• Decide whether proto= participates; it is currently accepted and ignored on the string branch, and could resolve some but not all of those 37.

Both stay open until the redesign lands and demonstrably fixes them — not closed as superseded, since closing them would discard the requirements rather than the implementations.

[JarryShaw]

Design decisions, part two — undefined transport, and making the registry bookkeeping programmatic

What undefined transport actually means in IANA's registry

Asked and answered: it is neither "supported on all transports" nor arbitrary — it means the Transport Protocol column was empty. pcapkit/vendor/reg/apptype.py:256:

proto = 'TransportProtocol.get(%r)' % (item[2].strip().lower() or 'undefined')

IANA keys assignments on the (service, port, transport) triple, so a blank transport is not an assignment to anything. Measured composition of the 124 entries with a real port but no transport: 94 unassigned, 9 reserved, ~19 administrative markers (de_registered, removed, deprecated, decomissioned_port_04_14_00_ms, possibly_assigned), ~2 plausibly real services (boe-cms 6400, boe-was 6401). The 580 with port == -1 are historic service and IP-protocol names with no port at all: argus, arp, bbn-rcc-mon, bootp, chaos, clock.

So documentation-only is the semantically correct treatment. The old behaviour's de facto all-transport resolution is an implementation artifact: apptype.py:124-125 files every undefined member into __members_proto__[undefined], and :30636 consults that bucket as a fallback after the transport-specific lookup misses — so get(51, proto=tcp) returns reserved_51 today, claiming a TCP assignment IANA never made.

Making it programmatic rather than docs-only

Three mechanisms tested on aenum 3.1.17:

approach	result
bare public dict, UNASSIGNED = {...}	fails — TypeError: int() argument must be... not 'dict'; aenum makes it a member
dunder-named, __unassigned__ = {...}	works — base stays memberless, inherits to subclasses, isinstance holds
aenum.nonmember({...})	works; nonmember exists in 3.1.17

The dunder route is the pattern already in use — __members_proto__ at apptype.py:81 is a bare defaultdict class attribute that works for exactly this reason.

Because the three populations answer different questions, one dict[int, str] under-serves them: something like __unassigned__: dict[int, str] keyed by port (the 103 unassigned/reserved plus ~19 withdrawn) and __portless__: dict[str, TransportProtocol] keyed by service name (the 580) matches the two real lookup directions.

.get() behaviour — decided

No-transport and no-port entries get a warning or error, not a member. Maintainer's words: "we dont know if it should be a member." So .get() returns a genuine member or raises — never a half-member — and the bookkeeping is reached through the maps above or explicit accessors.

This also settles a return-contract problem: had .get() returned dict data, its type would have widened from AppType to a union, which is caller-visible. It does not.

Worth distinguishing when implementing: an unassigned port is a legitimate query (warn), a withdrawn registration is closer to caller error, and a name with no port cannot answer "what port" at all.

[JarryShaw]

Needed from you: two implementation sub-questions

The design is settled — layout, memberless base, list-tables for unassigned entries, _missing_/extend_enum unchanged, and .get() warning-or-erroring rather than returning a member. Two things below it are not, and both will be decided by whoever writes the first PR if they are not answered here.

1. Warn or error, per population? You ruled .get() must not return a member for no-transport/no-port entries — "we dont know if it should be a member." But the three populations differ in kind, and the honest response differs with them:

population	count	a caller asking for it is…
real port, unassigned / reserved	103	asking a legitimate question — IANA genuinely has it unassigned
real port, withdrawn (de_registered, removed, deprecated, possibly_assigned)	~19	closer to caller error — the registration was pulled
name with no port	580	asking a question with no answer — there is no port to return

Same treatment for all three, or warn for the first and raise for the others?

2. The 124 real-port undefined entries lose a live fallback, not just documentation. pcapkit/const/reg/apptype.py:30636 consults __members_proto__[undefined] when the transport-specific lookup misses, so today get(51, proto=tcp) returns reserved_51 — a true statement ("IANA has 51 unassigned") that the docstring-only treatment loses programmatically. After the split it would mint PORT_51_tcp instead. Do you want that fallback preserved through __unassigned__, or is losing it acceptable?

Neither blocks the first three PRs in the plan — the dead get(<str>) path, the ~23 colliding-port preferences, and making process() accumulate a normalised proto set. Those carry no design dependency and can start whenever you say.

Answer here or in chat — either way it gets recorded on this issue before any code is written.

[JarryShaw]

I think let's rule like this:

if it's a name with a port assigned, we should return a member; if the port is withdrawn, we add a warning to explicitly specify.

if it's a name with reserved/unassigned port, we return sentinel objects like Reserved and Unassigned respectively, with a warning (same convention).

if it's a name with genuinely no port at all, we throw (and maybe warning, using the same convention).

for no-transport protocols it's the same logic. just that we should likely always throw in all transport apptype (and maybe warning, same as above).

and for any other cases with no concrete (transport, port, name) tuple, they should likely fall under the _missing_ path.

in this way, we dont invent anything but honestly following IANA's registry information.

[JarryShaw]

Adding #736 to this issue's acceptance criteria, alongside #717 and #734.

#736 is AppType.get(port, proto=<combined flag>) minting an unknown member and then permanently displacing the real member in each single-bit bucket — reproduced deterministically, and it affects the 65% of members that are multi-transport. The owner's ruling is that this redesign removes it rather than a separate patch, since per-transport classes have no combined-flag key space at all.

Criterion: in a clean process, get(7, proto=tcp|udp) must not displace what get(7, proto=tcp) returns, and get(m.port, proto=m.proto) must round-trip for a multi-transport member.

Two implementation blockers found while measuring, neither previously noted here:

• pcapkit/vendor/default.py:449-453 derives the output path from a hardcoded two-level vendor/<stem>/<file>.py layout, so vendor/reg/apptype/tcp.py resolves to const/apptype/tcp.py — the wrong tree. Vendor.__init__ has to change for the package form.
• If the memberless base declares __members_proto__, or any mutable class attribute, all four subclasses inherit one dict and recreate today's collision across classes. Each needs its own.

Cost, measured: 5,354 of 8,182 members (65%) are multi-transport, so the four modules need 12,882 member definitions (13,586 including the 704 homeless ones) — 1.76× duplication on the 7,054 distinct transport-bearing real-port members. Your recorded figures cross-validate exactly: 8,182 members, 1,004 with port == -1, 704 with proto is undefined.

Also worth stating plainly, because it is easy to assume otherwise: this split alone does not make the registries enum-keyed. TCP.__proto__/UDP.__proto__ are keyed on plain int today (transport/tcp.py:509, :888); SCTP is the exception. Enum-keying is a second, separable change.

[JarryShaw]

Recording your .get() ruling as a spec, since it answers sub-question 2 and #734's semantics together.

input	result	warning
name, port assigned	the member	—
name, port withdrawn	the member	yes — "explicitly specify"
name, port reserved	Reserved sentinel	yes
name, port unassigned	Unassigned sentinel	yes
name, genuinely no port	throw	yes
no-transport protocol	same logic, but always throw for transport apptype	yes
no concrete (transport, port, name) tuple	_missing_ path	—

Principle taken as binding: invent nothing, follow IANA's registry honestly. That is what rules out today's behaviour of minting a port=-1 member to paper over a miss.

Three consequences worth flagging before anyone implements:

• Reserved and Unassigned are new sentinel objects, not members. They must not be AppType instances, or they re-enter __members__ and the "invent nothing" rule is broken by the fix. A module-level singleton of a small dedicated class is the shape that satisfies this.
• This makes .get() raising a normal outcome, which is a behaviour change for callers who currently get a member back. breaking by the repo's own definition — correct caller code changes meaning. The four in-library call sites (transport/tcp.py:615-616, udp.py:203-204, sctp.py:581-582) need checking against it.
• It also fixes the transport-blind _missing_ path: its 766 range branches take no proto parameter today, so get(6010, proto='udp') returns a tcp member and a second identical call raises TypeError. Under the ruling that case routes to _missing_ with the tuple incomplete, which is the honest answer.

Exceptions come from pcapkit.utilities.exceptions and warnings from pcapkit.utilities.warnings; the "same convention" in your ruling reads as one warning class used consistently across all five rows — confirm if you meant a distinct class per case.

[JarryShaw]

the "same convention" in your ruling reads as one warning class used consistently across all five rows — confirm if you meant a distinct class per case.

same class and similar message format, like this certain port/app is not assigned/reserved/unknown, depending on the actual case and a uniformed wording with clarity to avoid any confusion.