Skip to content

docs(protocols): ESP and AH cite the wrong IANA registry for their extension-header status #931

Description

@JarryShaw

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 ESP Y 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:

curl https://www.iana.org/assignments/ipv6-parameters/extension-header.csv
  50,Encapsulating Security Payload,[RFC4303]
  51,Authentication Header,[RFC4302]

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.

Activity

  1. added
    docsPull requests that change documentation only (docs: subject prefix)
    on Sep 29, 2026
  2. JarryShaw commented on Sep 29, 2026

    @JarryShaw
    OwnerAuthor

    Blocked, on two things, and the second is the one that matters.

    1. 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.
    2. refactor(const,protocols): reparent the last seven non-registry enums onto EnumLookup #930 touches pcapkit/protocols/internet/esp.py to re-parent ESPStatus onto EnumLookup. This issue touches the ESP class 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: 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.

  3. added
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Sep 29, 2026
  4. JarryShaw commented on Sep 29, 2026

    @JarryShaw
    OwnerAuthor

    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.

  5. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    blockedDeferred pending another issue or decision; see the last comment for what unblocks it
    on Sep 30, 2026
  6. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Sep 30, 2026
  7. added this to the 1.5 milestone on Oct 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsPull requests that change documentation only (docs: subject prefix)

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions