Repository navigation
docs(protocols): ESP and AH cite the wrong IANA registry for their extension-header status #931
Description
Activity
- addeddocsPull requests that change documentation only (docs: subject prefix)Pull requests that change documentation only (docs: subject prefix)
on Sep 29, 2026 Blocked, on two things, and the second is the one that matters.
- docs(conventions): harvest the settled rulings, correct the stale prose (#918) #929 is open and rewrites
docs/source/contributing/conventions.rst's extension-header subclassing section — the very reasoning these two docstrings should agree with. Landing this first would mean reconciling the prose twice, in opposite directions. - refactor(const,protocols): reparent the last seven non-registry enums onto EnumLookup #930 touches
pcapkit/protocols/internet/esp.pyto re-parentESPStatusontoEnumLookup. This issue touches theESPclass docstring in the same file. Different regions, same file — so sequencing them avoids a merge conflict rather than discovering one.
So: after #929 and #930, in that order. Neither is a long wait — #929 is
review: pendingwith its cross-review in flight, and #930 is a bare re-parent.Nothing about the finding changes meanwhile. Verified on
4f3d43df7:esp.py:970-973andah.py:54-57both citeprotocol-numbers-1.csv's IPv6 Extension Header column, which is the derived signal #926 repointed the generator away from. Both sentences remain true about that CSV, which is why this is stale provenance rather than an error.- docs(conventions): harvest the settled rulings, correct the stale prose (#918) #929 is open and rewrites
- addedblockedDeferred pending another issue or decision; see the last comment for what unblocks itDeferred pending another issue or decision; see the last comment for what unblocks it
on Sep 29, 2026 One of the two blockers is gone: #929 merged as
af2324522. The subclassing prose these docstrings should agree with is now onmain, atdocs/source/contributing/conventions.rstunder the new.. _extension-header-subclassing:anchor — so the target wording to match is settled and no longer moving.Still blocked on #930, which is in flight and edits
pcapkit/protocols/internet/esp.pyto re-parentESPStatus. This issue edits theESPclass docstring in the same file. Different regions, so sequencing avoids a conflict rather than discovering one.Unchanged and re-verified on
af2324522:esp.py:970-973andah.py:54-57both still citeprotocol-numbers-1.csv's IPv6 Extension Header column. Both sentences remain true about that CSV, which is why this is stale provenance rather than error — the column is simply the derived signal #926 repointed the generator away from.- addedwipWork in flight - a covering PR is open or an agent is actively on itWork in flight - a covering PR is open or an agent is actively on itand removedblockedDeferred pending another issue or decision; see the last comment for what unblocks itDeferred pending another issue or decision; see the last comment for what unblocks it
on Sep 30, 2026 - removedwipWork in flight - a covering PR is open or an agent is actively on itWork in flight - a covering PR is open or an agent is actively on it
on Sep 30, 2026
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsDone
ESPandAHboth justify their double inheritance by citing the registry that #925/#926 established is the wrong one.On
4f3d43df7:pcapkit/protocols/internet/esp.py:970-973— "IANA'sprotocol-numbers-1.csvmarksESPYin the IPv6 Extension Header column"pcapkit/protocols/internet/ah.py:54-57— the same sentence forAHBoth sentences are still true about that CSV, which is why this is stale provenance rather than a factual error — but the column they cite is the derived signal #926 replaced precisely because it disagrees with the authoritative registry. That disagreement is what put
BIT_EMU(147) intoExtensionHeaderand cost a whole PR to remove.Cite the authoritative source instead. IANA's IPv6 Extension Header Types registry lists both, and #926 repointed the generator at it:
Better still, both classes qualify on a primary source rather than on any registry: RFC 4303 §3.1.1 and RFC 4302 §3.1.1 each place the header after an IPv4 header, which is the operative test under the extension-header subclassing convention — an IPv4-capable header is also a standalone protocol and names a second base. That is the reasoning #929 writes into
docs/source/contributing/conventions.rst, so these two docstrings should agree with it.Scope
Docstring-only, two files. Replace the
protocol-numbers-1.csvcitation with the extension-header registry and the per-header RFC section. Keep the second half of each sentence — thatExtensionHeaderagrees — since that is now the authoritative registry rather than a corroboration of the wrong one.Worth grepping for the same citation elsewhere while there;
hip.pygained a similar docstring in #924 and should be checked for consistency, though it cites RFC 7401 App. C.2 rather than a CSV.Not blocked, but it overlaps #929's subject matter. Land it after #929 merges so the docstrings and the conventions page agree in one direction rather than being reconciled twice.