You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
docs(protocols): ESP and AH cite the wrong IANA registry for their extension-header status #931
ESP and AH both 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's protocol-numbers-1.csv marks ESPY in the IPv6 Extension Header column"
pcapkit/protocols/internet/ah.py:54-57 — the same sentence for AH
Both 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) into ExtensionHeader and 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.csv citation with the extension-header registry and the per-header RFC section. Keep the second half of each sentence — that ExtensionHeader agrees — 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.py gained 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.
So: after #929 and #930, in that order. Neither is a long wait — #929 is review: pending with its cross-review in flight, and #930 is a bare re-parent.
Nothing about the finding changes meanwhile. Verified on 4f3d43df7: esp.py:970-973 and ah.py:54-57 both cite protocol-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.
One of the two blockers is gone: #929 merged as af2324522. The subclassing prose these docstrings should agree with is now on main, at docs/source/contributing/conventions.rst under 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.py to re-parent ESPStatus. This issue edits the ESP class 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-973 and ah.py:54-57 both still cite protocol-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.
Activity
JarryShaw commentedon Sep 29, 2026
Blocked, on two things, and the second is the one that matters.
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.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.JarryShaw commentedon 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.docs(protocols): cite the extension-header registry in ESP/AH, not pr…
docs(protocols): cite the extension-header registry in ESP/AH, not pr…
docs(protocols): cite the extension-header registry in ESP/AH, not pr…