MUST-level requirements the gate HOLDS, across the 147 RFCs Ze implements, out of 3,319 across the 182 RFCs inspected. A population, not a result: the shares beside it are what says how Ze stands
Quality
RFC Compliance Gate Report
Source: internal/le/rfc, rfc/short/*.md, and rfc/audit/*.json.
Overall
the populations every share below is taken over
an obligation that does not bind Ze. A {not-applicable} annotation says it never bound; a {feature-declined} annotation says its condition is an optional feature Ze does not offer, and quotes the RFC sentence that makes it optional. Scope, not coverage: it stays in the denominator every share on this page is taken over
Positive
what Ze has
the share this site publishes everywhere: Tested both ways and One polarity plus reason added together, two of the five shares that partition the same denominator. That denominator keeps the {not-applicable} obligations, so annotating a requirement away cannot raise it
a positive test proves Ze does what the requirement demands and a negative one proves it refuses what the requirement forbids
the requirement admits no counter-case, so one polarity plus a recorded reason is the whole proof available for it
one direction is tested, the other is neither tested nor excused, and nothing states which
a red was observed once under a recorded procedure, and the unit, the claim and the producer it rested on still hash to what was recorded. The break is not re-run. A test pair is not a proof until one has been observed
Neutral
measures that are neither good news nor bad
a {not-applicable} annotation says the obligation does not bind Ze, so no test is owed for it. It stays in the denominator every share here is taken over
a {lower-layer} annotation says a layer under Ze performs the behavior, on state Ze installs into that layer, and names the producer that installs it. The obligation binds Ze and is met; Ze proves none of it, because its own boundary carries no value the behavior reads
a {feature-declined} annotation says the obligation is conditional on a feature the RFC makes optional and Ze does not offer, and it quotes the sentence that makes it optional. The condition is false, so nothing is owed and nothing is missing. It stays in the denominator every share here is taken over
requirements a reader has judged and whose judgement is still current. A missing verdict is not claimed, and the shifted and stale ones are named on their own RFC's page
Negative
what Ze owes
no test carries the requirement id, whether or not a gap states why
whether ./le rfc check passes over this tree
The 7 shares marked as a part above are the whole of the 3,057 gated MUSTs: they add to 100%. Proven by test is the first two of them added together, so it is not a part of its own. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.
How to read the colors
A color names what the measure MEANS, not how well Ze scores on it. Green is a good outcome at any value, red is a bad one, and neither a population nor a scope count is an outcome, so both take no color. The number under the label is what says how far Ze has got.
| Card | Tone here | Why that color |
|---|---|---|
| Gated MUSTs | neutral | no color: a population is a scale, and a larger one is neither good news nor bad. It is the accounting total |
| Out of scope | neutral | no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim |
| Proven by test | ok | green at every value: a proven obligation is the outcome this gate exists to produce, and the number under the label is what says how far Ze has got |
| Tested both ways | ok | green at every value: a test pair is the outcome this gate exists to produce, and the share under the label is what says how far Ze has got |
| One polarity plus reason | ok | green at every value: where no counter-case exists, one polarity IS the complete answer, and a recorded reason is what the gate demands beside it |
| One polarity, unexcused | ok | green at zero, RED above it: half a proof with no reason for the other half |
| No test at all | bad | green at zero, RED above it: a binding obligation nothing exercises is a claim with nothing behind it, whether or not a reason is stated |
| Not applicable | neutral | no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim |
| Met below Ze | neutral | no color: an obligation met below Ze is neither a test Ze wrote nor work Ze owes, and the two green shares above are what says how much Ze proves itself |
| Optional feature declined | neutral | no color: an obligation whose condition Ze never meets is neither an achievement nor a failure. The absent FEATURE is disclosed on the RFC's own status row, as an implementation gap a later scope decision can revisit |
| Proven by a recorded break | ok | green at every value: an observed break is the outcome the discrimination gate exists to produce. The denominator is TAGGED UNITS, not obligations, so this share is not one of the parts above |
| Gate verdict | bad | the verdict IS the value: green when the gate passes, red when it does not |
| Semantic verdicts | neutral | no color: a count of judgements recorded is a scale rather than an outcome, and the shifted and stale counts beside it are the states that need reading |
Gate verdictRED
4 open gate issues. Check results below names them, up to the 25 this page inlines.
Reproduce it with ./le rfc check. The gate's own line reads rfc-requirements: 4 violation(s).
Requirement buckets
- Positive and negative tests: 1,532 (50.1%)
- One polarity plus reason: 360 (11.8%)
- Declared gap: 493 (16.1%)
- Missing, unexcused: 4 (0.1%)
- Not applicable: 635 (20.8%)
- Met below Ze: 29 (0.9%)
- Optional feature declined: 4 (0.1%)
The bar is every one of the 3,057 gated MUST-level requirements. 639 of them are {not-applicable} or {feature-declined}: they do not bind Ze, and they are a named segment of the bar rather than an omission from it.
| Bucket | Count | Share of gated | Source condition |
|---|---|---|---|
| Positive and negative tests | 1,532 | 50.1% | positive tag + negative tag |
| One polarity plus reason | 360 | 11.8% | {single-polarity} annotation + required tag |
| Declared gap | 493 | 16.1% | {gap} annotation + public ledger disclosure |
| One polarity, unexcused | 0 | 0.0% | tag without annotation |
| Missing, unexcused | 4 | 0.1% | no tag, no annotation |
| Not applicable | 635 | 20.8% | {not-applicable} annotation: the obligation does not bind Ze, so it is scope rather than coverage |
| Met below Ze | 29 | 0.9% | {lower-layer} annotation + named producer |
| Optional feature declined | 4 | 0.1% | {feature-declined} annotation + quoted RFC sentence: the obligation does not bind Ze, so it is scope rather than coverage |
| Gated MUST-level requirements | 3,057 | 100.0% | every gated MUST falls in exactly one bucket above, the 639 that do not bind Ze included. This total is the denominator of every share above it |
Gap disclosure
| Public status for RFCs with gaps | RFCs |
|---|---|
| Partial | 64 |
| Experimental | 12 |
| Supported | 3 |
| Not supported | 1 |
| Supported in IPsec | 1 |
Supported rows that still disclose a gap
- RFC 1350: RFC1350-2-3 unmet (Sorcerer's Apprentice fix): sendAndWaitACK retransmits DATA on any non-matching ACK (handler.go) instead of silently ignoring a duplicate or stale ACK.
- RFC 3748: One MUST is unmet. Ze derives no Extended Master Session Key: `exportEAPTLSMSK` (`internal/core/eap/eap_tls.go`) keeps the MSK half of the RFC 9190 Section 2.3 key material and drops the EMSK half, and `DeriveMSK` (`internal/core/eap/mschapv2.go`) returns an MSK alone. Section 7.10 requires a key-deriving method to export both, so `RFC3748-7.10-6`, which confines the EMSK to the peer and the server that derived it, has no key to confine and stays open. Ze reads no Expanded Type (254), which Section 5 states as a SHOULD, and answers a Type-254 Request with the legacy Nak Section 5.7 prescribes rather than composing an Expanded Nak. Ze's authenticator sends no Notification Request, which RFC 3748 Section 5.2 states as an option ("An authenticator MAY send a Notification Request to the peer at any time when there is no outstanding Request, prior to completion of an EAP authentication method") and which the owner declined on 2026-09-01; Ze's peer answers one, which is the mandatory half. Two further features are absent by decision rather than by omission, and neither is a conformance gap. Ze's authenticator terminates every EAP method locally and does not act as a pass-through agent for a backend authentication server; Section 2 says "Support for pass-through is optional". Ze offers neither the One Time Password method (Type 5) nor the Generic Token Card method (Type 6), which Section 5 leaves to the implementation ("Implementations MAY support other Types defined here or in future RFCs"). A later scope decision can revisit any of the three. The Type 4 (MD5-Challenge) deviation authorized on 2026-08-30 was WITHDRAWN by the owner on 2026-09-01, who ordered the method implemented; both roles now run it.
- RFC 6396: One MUST gap gated in rfc/short/rfc6396.md [RFC6396-4.4.3-1]: the live BGP4MP writer always emits the BGP4MP_MESSAGE_AS4 subtype and records the on-wire message verbatim without checking the session's negotiated 4-byte-AS capability, so a message from an OLD (2-byte) peer carries a 2-byte AS_PATH mislabeled as AS4. RIB-path AS_PATH is unaffected (canonicalized to 4-byte).
- RFC 7313: Four MUST-level receive-side gaps annotated in `rfc/short/rfc7313.md`: RFC7313-4-4/4-5 -- a received BoRR/EoRR is log-only (internal/component/bgp/plugins/rib/rib.go), so ze marks no Adj-RIB-In routes stale and purges none; and RFC7313-4-6/4-7 -- neither the send nor receive path applies a Graceful-Restart End-of-RIB gate to BoRR emission or acceptance.
Exclusion disclosure
A reviewer walks an RFC's own text sentence by sentence and decides which sentences become requirements. One that does not is EXCLUDED, with a kind and a reason, and it never reaches the gated ledger at all. That is a different mechanism from the Out of scope card above, which counts requirements that exist and carry a {not-applicable} annotation. Across the sign-offs done so far, 949 sentences were mapped to a requirement and 540 were declined. 13 of those declines are not scope at all: they are obligations Ze OWES, relocated to a named spec, and they are stated apart below.
62 of 201 summaries carry an extraction sign-off, 59 of them among the 184 enrolled. The other 139 have no exclusion ledger at all, so what follows counts the walks that HAVE been done and is not the whole picture.
| Excluded kind | Means | Sites | Summaries | What it means |
|---|---|---|---|---|
binds-another-role |
never bound Ze | 239 | 22 | the obligation is addressed to a role Ze never acts as |
duplicate-of |
never bound Ze | 116 | 24 | the same obligation is already captured under another requirement id |
not-a-requirement |
never bound Ze | 104 | 38 | the sentence states a fact or describes another document, and directs no implementation |
feature-out-of-scope |
never bound Ze | 29 | 5 | the RFC makes a feature OPTIONAL, Ze decided not to offer it, and this obligation is conditional on offering it |
cross-document |
never bound Ze | 26 | 17 | the obligation belongs to another document that this one only cites |
advisory-in-context |
never bound Ze | 13 | 7 | the sentence advises on applying a rule stated elsewhere and adds no obligation of its own |
relocated-to-spec |
Ze owes it | 13 | 2 | the obligation is real and unbuilt, and a named spec owes it |
| Sentences declined | - | 540 | - | 527 say the obligation never bound Ze and 13 say Ze owes it, of 1,489 normative sentences the walks found |
binds-another-role (239): RFC 1035, RFC 1350, RFC 1997, RFC 2545, RFC 2759, RFC 2865, RFC 2866, RFC 2869, RFC 3032, RFC 3579, RFC 3748, RFC 4302, RFC 4303, RFC 4360, RFC 4364, RFC 4456, RFC 4761, RFC 5176, RFC 6396, RFC 7296, RFC 7535, RFC 8654
ai/rules/rfc-compliance.md treats binds-another-role as PRESUMED WRONG until it is justified: Ze rarely implements one side of a protocol, so an obligation addressed to "the sender" or "the receiver" almost always binds it, and the label reads as "not our problem" where the truth is usually "our problem, unbuilt". Each one is justified on its own RFC's page, under Extraction sign-off, and the justification MUST name the role, show Ze never acts as it, and cite the producer that would act as it if Ze did.
duplicate-of (116): RFC 1035, RFC 2759, RFC 2865, RFC 2866, RFC 2869, RFC 3032, RFC 3579, RFC 3748, RFC 3948, RFC 4302, RFC 4303, RFC 4364, RFC 4456, RFC 4760, RFC 5549, RFC 5798, RFC 5880, RFC 7296, RFC 8671, RFC 8950, RFC 9003, RFC 9069, RFC 9190, RFC 9234
not-a-requirement (104): DRAFT-ABRAITIS-BGP-VERSION-CAPABILITY, DRAFT-WALTON-BGP-HOSTNAME-CAPABILITY, RFC 1035, RFC 1350, RFC 2347, RFC 2385, RFC 2545, RFC 2759, RFC 2865, RFC 2869, RFC 2918, RFC 3032, RFC 3579, RFC 3748, RFC 3765, RFC 3948, RFC 4303, RFC 4360, RFC 4364, RFC 4456, RFC 4761, RFC 5176, RFC 5282, RFC 5301, RFC 5492, RFC 5798, RFC 6286, RFC 6396, RFC 7296, RFC 7534, RFC 7535, RFC 7705, RFC 7911, RFC 7999, RFC 8654, RFC 9190, RFC 9384, RFC 9687
feature-out-of-scope (29): RFC 3748, RFC 5082, RFC 5176, RFC 8671, RFC 9069
cross-document (26): DRAFT-ABRAITIS-BGP-VERSION-CAPABILITY, RFC 2545, RFC 2869, RFC 3032, RFC 3579, RFC 3748, RFC 3948, RFC 4303, RFC 4364, RFC 4761, RFC 5082, RFC 5176, RFC 5282, RFC 5492, RFC 7535, RFC 8654, RFC 9069
advisory-in-context (13): RFC 1035, RFC 2866, RFC 3032, RFC 3748, RFC 3948, RFC 4761, RFC 5176
Obligations relocated to a spec
These 13 sentences are NOT scope. Each is an obligation Ze owes and has not built, moved to a named spec that reserves a requirement id for it. ./le rfc check refuses the sign-off unless that spec exists and still reserves the id, so each row is tracked work rather than an obligation that went away.
| RFC | Reserved id | The obligation | The spec that owes it |
|---|---|---|---|
RFC 7296 |
RFC7296-1.7-3 |
Implementations that conform to this document MUST ignore proposals that have configuration attribute type 5, the old value for INTERNAL_ADDRESS_EXPIRY. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7296 |
RFC7296-2.19-2 |
Initiator Responder ------------------------------------------------------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, CP(CFG_REPLY), SAr2, TSi, TSr} In all cases, the CP payload MUST be inserted before the SA payload. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7296 |
RFC7296-2.19-3 |
In variations of the protocol where there are multiple IKE_AUTH exchanges, the CP payloads MUST be inserted in the messages containing the SA payloads. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7296 |
RFC7296-2.19-5 |
The responder MUST NOT send a CFG_REPLY without having first received a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7296 |
RFC7296-2.19-6 |
In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child SA creation with a FAILED_CP_REQUIRED error. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7296 |
RFC7296-2.22-1 |
These payloads MUST NOT occur in messages that do not contain SA payloads. | plan/spec-ipsec-ipcomp.md |
RFC 7296 |
RFC7296-2.22-2 |
Although there has been discussion of allowing multiple compression algorithms to be accepted and to have different compression algorithms available for the two directions of a Child SA, implementations of this specification MUST NOT accept an IPComp algorithm that was not proposed, MUST NOT accept more than one, and MUST NOT compress using an algorithm other than one proposed and accepted in the setup of the Child SA. | plan/spec-ipsec-ipcomp.md |
RFC 7296 |
RFC7296-3.15.1-1 |
Only one netmask is allowed in the request and response messages (e.g., 255.255.255.0), and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7296 |
RFC7296-3.15.1-3 |
o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute MUST be zero-length and specifies a query to the responder to reply back with all of the attributes that it supports. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7296 |
RFC7296-3.15.1-4 |
Unrecognized or unsupported attributes MUST be ignored in both requests and responses. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7296 |
RFC7296-4-2 |
If an implementation supports responding to such requests, it MUST parse the CP payload of type CFG_REQUEST in the first message in the IKE_AUTH exchange and recognize a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7296 |
RFC7296-4-3 |
If it supports leasing an address of the appropriate type, it MUST return a CP payload of type CFG_REPLY containing an address of the requested type. | plan/immediate/spec-ipsec-remote-access.md |
RFC 7947 |
RFC7947-2.1-1 |
A route server MUST accept all UPDATE messages received from each of its clients for inclusion in its Adj-RIB-In. | plan/immediate/spec-rfc7947-adj-rib-in-accepts-filtered-updates.md |
Top gap clusters
| RFC | Declared gaps | Public status |
|---|---|---|
RFC 9012 |
51 | Partial |
DRAFT-IETF-BESS-MUP-SAFI |
37 | Partial |
RFC 1661 |
24 | Partial |
RFC 9830 |
20 | Partial |
RFC 2131 |
18 | Partial |
RFC 4577 |
16 | Not supported |
RFC 4271 |
15 | Partial |
RFC 7432 |
15 | Partial |
RFC 3579 |
14 | Partial |
RFC 5880 |
14 | Partial |
RFC 8665 |
14 | Partial |
RFC 9514 |
13 | Partial |
How this is checked
This gate runs before a commit is verified: ./le rfc check is 1 stage of the 49 that ./le verify current mode full runs.
| Input | Producer | What it answered here |
|---|---|---|
| Reproduce it | ./le rfc check |
1 of 49 full-mode verify stages run it |
| Requirement source | rfc/short/*.md |
3,319 gated MUST-level requirements |
| Enrolment | rfc/short/*.md, the | Enrolment | Meta row |
184 enrolled RFCs |
| Test tags | internal/, pkg/, test/ |
4,667 resolved tags |
| Public ledger | rfc/short/*.md, the | Support | Meta row |
81 RFCs with gaps, 4 Supported with Remaining |
| Semantic audits | rfc/audit/*.json |
56 fresh, 0 shifted, 0 stale, 3,263 missing |
| Pre-commit verification | internal/le/verify/engine/stages.go |
./le rfc check, 1 of 49 full-mode stages |
| Published artifacts | data/rfc-compliance.json, data/rfc-requirements.json |
the same answers this page renders, machine-readable |
Check results
| RFC | Requirement | Level | What is wrong | The requirement |
|---|---|---|---|---|
| RFC 4302 | RFC4302-3.3.4-1 |
MUST | has no test and no annotation | An AH implementation MUST support generation of ICMP PMTU messages, or the equivalent internal signaling for a native host implementation (§3.3.4) |
| RFC 4302 | RFC4302-5-1 |
MUST | has no test and no annotation | An implementation claiming conformance MUST fully implement the AH syntax and processing for unicast traffic, and MUST comply with all requirements of the Security Architecture document (§5) |
| RFC 4302 | RFC4302-5-2 |
MUST | has no test and no annotation | An implementation claiming to support multicast traffic MUST comply with the additional requirements specified for such traffic (§5) |
| RFC 5082 | RFC5082-3-2 |
MUST | has no test and no annotation | The TTL 255 transmit and verify rule also applies to the related ICMP error handling messages of a GTSM-enabled session (§3, restated §6.1) |
Enrolled RFCs
| RFC | Public status | Gated MUSTs | Declared gaps | Gated with no test |
|---|---|---|---|---|
DRAFT-ABRAITIS-BGP-VERSION-CAPABILITY Software Version Capability for BGP |
Partial | 11 | 0 | 0 |
DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT Scalability Considerations for ADD-PATH with PATHS-LIMIT |
Supported | 4 | 0 | 0 |
DRAFT-IETF-BESS-MUP-SAFI BGP Extensions for the Mobile User Plane (MUP) SAFI |
Partial | 40 | 37 | 0 |
DRAFT-IETF-IDR-BGP-BFD-STRICT-MODE BGP BFD Strict-Mode |
Supported | 4 | 0 | 0 |
DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY Link-Local Next Hop Capability for BGP |
Partial | 13 | 5 | 0 |
DRAFT-IETF-SIDROPS-ASPA-VERIFICATION Verification of AS_PATH Using the Resource Certificate PKI and Autonomous System Provider Authorization |
Partial | 8 | 2 | 0 |
DRAFT-WALTON-BGP-HOSTNAME-CAPABILITY Hostname Capability for BGP |
Supported | 0 | 0 | 0 |
RFC 1071 Computing the Internet Checksum |
No public row declared | 8 | 0 | 0 |
RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments |
Experimental | 10 | 0 | 0 |
RFC 1332 The PPP Internet Protocol Control Protocol (IPCP) |
Partial | 6 | 1 | 0 |
RFC 1334 PPP Authentication Protocols |
Partial | 7 | 0 | 0 |
RFC 1350 The TFTP Protocol (Revision 2) |
Supported | 11 | 1 | 0 |
RFC 1661 The Point-to-Point Protocol (PPP) |
Partial | 66 | 24 | 0 |
RFC 1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses |
Partial | 4 | 1 | 0 |
RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP) |
Partial | 17 | 3 | 0 |
RFC 1997 BGP Communities Attribute |
Supported | 5 | 0 | 0 |
RFC 2003 IP Encapsulation within IP |
No public row declared | 13 | 0 | 0 |
RFC 2131 Dynamic Host Configuration Protocol |
Partial | 64 | 18 | 0 |
RFC 2132 DHCP Options and BOOTP Vendor Extensions |
Partial | 34 | 1 | 0 |
RFC 2181 Clarifications to the DNS Specification |
Partial | 23 | 1 | 0 |
RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification |
Experimental | 6 | 2 | 0 |
RFC 2328 OSPF Version 2 |
Partial | 25 | 1 | 0 |
RFC 2347 TFTP Option Extension |
Supported | 4 | 0 | 0 |
RFC 2348 TFTP Blocksize Option |
No public row declared | 5 | 0 | 0 |
RFC 2349 TFTP Timeout Interval and Transfer Size Options |
No public row declared | 4 | 0 | 0 |
RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option |
Supported on Linux; FreeBSD needs a `setkey(8)` SAD entry | 9 | 0 | 0 |
RFC 2473 Generic Packet Tunneling in IPv6 Specification |
No public row declared | 11 | 0 | 0 |
RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE) |
Partial | 22 | 0 | 0 |
RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing |
Supported | 4 | 0 | 0 |
RFC 2661 Layer Two Tunneling Protocol "L2TP" |
Partial | 20 | 1 | 0 |
RFC 2759 Microsoft PPP CHAP Extensions, Version 2 |
Supported | 12 | 0 | 0 |
RFC 2782 A DNS RR for specifying the location of services (DNS SRV) |
No public row declared | 7 | 0 | 0 |
RFC 2784 Generic Routing Encapsulation (GRE) |
No public row declared | 11 | 0 | 0 |
RFC 2865 Remote Authentication Dial In User Service (RADIUS) |
Supported for subscriber access | 30 | 0 | 0 |
RFC 2866 RADIUS Accounting |
Supported for subscriber access | 16 | 0 | 0 |
RFC 2869 RADIUS Extensions |
Supported for subscriber access | 11 | 0 | 0 |
RFC 2890 Key and Sequence Number Extensions to GRE |
No public row declared | 7 | 0 | 0 |
RFC 2918 Route Refresh Capability for BGP-4 |
Supported | 6 | 0 | 0 |
RFC 2966 Domain-wide Prefix Distribution with Two-Level IS-IS |
Experimental | 4 | 0 | 0 |
RFC 3031 Multiprotocol Label Switching Architecture |
No public row declared | 7 | 0 | 0 |
RFC 3032 MPLS Label Stack Encoding |
Partial | 17 | 0 | 0 |
RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option |
Experimental | 17 | 0 | 0 |
RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels |
Experimental | 13 | 2 | 0 |
RFC 3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) |
Partial | 31 | 14 | 0 |
RFC 3623 Graceful OSPF Restart |
Experimental | 13 | 2 | 0 |
RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2 |
Experimental | 5 | 0 | 0 |
RFC 3748 Extensible Authentication Protocol (EAP) |
Supported in IPsec | 61 | 1 | 0 |
RFC 3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control |
Supported | 0 | 0 | 0 |
RFC 3768 Virtual Router Redundancy Protocol (VRRP) |
Experimental | 39 | 0 | 0 |
RFC 3786 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit |
No public row declared | 4 | 0 | 0 |
RFC 3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) |
Partial | 3 | 1 | 0 |
RFC 3948 UDP Encapsulation of IPsec ESP Packets |
Partial | 14 | 1 | 0 |
RFC 3954 Cisco Systems NetFlow Services Export Version 9 |
Experimental | 9 | 1 | 0 |
RFC 4035 Protocol Modifications for the DNS Security Extensions |
Partial | 108 | 3 | 0 |
RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels |
Experimental | 12 | 0 | 0 |
RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers |
No public row declared | 23 | 0 | 0 |
RFC 4271 A Border Gateway Protocol 4 (BGP-4) |
Partial | 101 | 15 | 0 |
RFC 4301 Security Architecture for the Internet Protocol |
Partial | 20 | 1 | 0 |
RFC 4302 IP Authentication Header |
Partial | 34 | 2 | 3 |
RFC 4303 IP Encapsulating Security Payload (ESP) |
Supported | 22 | 0 | 0 |
RFC 4360 BGP Extended Communities Attribute |
Supported | 6 | 0 | 0 |
RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs) |
Partial | 8 | 0 | 0 |
RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) |
Supported | 6 | 0 | 0 |
RFC 4486 Subcodes for BGP Cease NOTIFICATION Message |
Supported | 1 | 0 | 0 |
RFC 4552 Authentication/Confidentiality for OSPFv3 |
Partial | 27 | 5 | 0 |
RFC 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE) |
Unsupported | 6 | 0 | 0 |
RFC 4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) |
No public row declared | 4 | 0 | 0 |
RFC 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) |
Not supported | 36 | 20 | 0 |
RFC 4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) |
Supported | 5 | 0 | 0 |
RFC 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN |
Partial | 16 | 3 | 0 |
RFC 4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) |
Partial | 4 | 4 | 0 |
RFC 4724 Graceful Restart Mechanism for BGP |
Partial | 26 | 8 | 0 |
RFC 4760 Multiprotocol Extensions for BGP-4 |
Supported | 6 | 0 | 0 |
RFC 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling |
Partial | 18 | 0 | 0 |
RFC 4862 IPv6 Stateless Address Autoconfiguration |
No public row declared | 16 | 0 | 0 |
RFC 5036 LDP Specification |
Experimental | 14 | 7 | 0 |
RFC 5072 IP Version 6 over PPP |
Partial | 16 | 3 | 0 |
RFC 5082 The Generalized TTL Security Mechanism (GTSM) |
Supported on Linux | 4 | 0 | 1 |
RFC 5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) |
Supported for subscriber access | 22 | 0 | 0 |
RFC 5187 OSPFv3 Graceful Restart |
Experimental | 4 | 0 | 0 |
RFC 5216 The EAP-TLS Authentication Protocol |
Partial | 21 | 1 | 0 |
RFC 5250 The OSPF Opaque LSA Option |
Experimental | 9 | 0 | 0 |
RFC 5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol |
Supported | 19 | 0 | 0 |
RFC 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates |
Experimental | 6 | 2 | 0 |
RFC 5301 Dynamic Hostname Exchange Mechanism for IS-IS |
Supported | 7 | 0 | 0 |
RFC 5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies |
Experimental | 18 | 7 | 0 |
RFC 5304 IS-IS Cryptographic Authentication |
Experimental | 9 | 0 | 0 |
RFC 5305 IS-IS Extensions for Traffic Engineering |
Experimental | 8 | 0 | 0 |
RFC 5308 Routing IPv6 with IS-IS |
Experimental | 7 | 0 | 0 |
RFC 5310 IS-IS Generic Cryptographic Authentication |
Experimental | 9 | 0 | 0 |
RFC 5340 OSPF for IPv6 |
Partial | 23 | 5 | 0 |
RFC 5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering |
Experimental | 12 | 4 | 0 |
RFC 5443 LDP IGP Synchronization |
Experimental | 8 | 1 | 0 |
RFC 5492 Capabilities Advertisement with BGP-4 |
Supported | 9 | 0 | 0 |
RFC 5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop |
Supported | 6 | 0 | 0 |
RFC 5561 LDP Capabilities |
No public row declared | 5 | 0 | 0 |
RFC 5575 Dissemination of Flow Specification Rules |
Partial | 12 | 4 | 0 |
RFC 5701 IPv6 Address Specific BGP Extended Community Attribute |
Partial | 4 | 1 | 0 |
RFC 5709 OSPFv2 HMAC-SHA Cryptographic Authentication |
Experimental | 15 | 0 | 0 |
RFC 5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 |
Partial | 55 | 7 | 0 |
RFC 5838 Support of Address Families in OSPFv3 |
Experimental | 16 | 8 | 0 |
RFC 5880 Bidirectional Forwarding Detection (BFD) |
Partial | 96 | 14 | 0 |
RFC 5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) |
Partial | 23 | 6 | 0 |
RFC 5882 Generic Application of Bidirectional Forwarding Detection (BFD) |
Partial | 3 | 0 | 0 |
RFC 5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths |
Partial | 8 | 2 | 0 |
RFC 6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap |
No public row declared | 8 | 0 | 0 |
RFC 6138 LDP IGP Synchronization for Broadcast Networks |
No public row declared | 2 | 0 | 0 |
RFC 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4 |
Supported | 4 | 0 | 0 |
RFC 6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format |
Supported | 13 | 1 | 0 |
RFC 6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions |
No public row declared | 4 | 0 | 0 |
RFC 6482 A Profile for Route Origin Authorizations (ROAs) |
No public row declared | 9 | 0 | 0 |
RFC 6549 OSPFv2 Multi-Instance Extensions |
No public row declared | 1 | 0 | 0 |
RFC 6608 Subcodes for BGP Finite State Machine Error |
Partial | 3 | 3 | 0 |
RFC 6793 BGP Support for Four-Octet Autonomous System (AS) Number Space |
Partial | 30 | 1 | 0 |
RFC 6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol |
Partial | 39 | 4 | 0 |
RFC 6811 BGP Prefix Origin Validation |
Supported | 5 | 0 | 0 |
RFC 6996 Autonomous System (AS) Reservation for Private Use |
No public row declared | 1 | 0 | 0 |
RFC 7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information |
Experimental | 19 | 1 | 0 |
RFC 7012 Information Model for IP Flow Information Export (IPFIX) |
No public row declared | 11 | 0 | 0 |
RFC 7166 Supporting Authentication Trailer for OSPFv3 |
Unsupported | 17 | 17 | 0 |
RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2) |
Partial | 222 | 0 | 0 |
RFC 7311 The Accumulated IGP Metric Attribute for BGP |
Partial | 5 | 1 | 0 |
RFC 7313 Enhanced Route Refresh Capability for BGP-4 |
Supported | 10 | 4 | 0 |
RFC 7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) |
No public row declared | 3 | 0 | 0 |
RFC 7432 BGP MPLS-Based Ethernet VPN |
Partial | 82 | 15 | 0 |
RFC 7440 TFTP Windowsize Option |
No public row declared | 9 | 0 | 0 |
RFC 7474 Security Extensions for OSPFv2 when Using Manual Key Management |
Experimental | 10 | 0 | 0 |
RFC 7534 AS112 Nameserver Operations |
Supported | 3 | 0 | 0 |
RFC 7535 AS112 Redirection Using DNAME |
Partial | 1 | 0 | 0 |
RFC 7606 Revised Error Handling for BGP UPDATE Messages |
Partial | 52 | 1 | 0 |
RFC 7607 Codification of AS 0 Processing |
Supported | 5 | 0 | 0 |
RFC 7611 BGP ACCEPT_OWN Community Attribute |
No public row declared | 5 | 0 | 0 |
RFC 7684 OSPFv2 Prefix/Link Attribute Advertisement |
Experimental | 8 | 0 | 0 |
RFC 7705 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute |
Supported | 9 | 0 | 0 |
RFC 7752 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP |
Partial | 26 | 4 | 0 |
RFC 7770 Extensions to OSPF for Advertising Optional Router Capabilities |
Experimental | 11 | 0 | 0 |
RFC 7854 BGP Monitoring Protocol (BMP) |
Partial | 13 | 0 | 0 |
RFC 7858 Specification for DNS over Transport Layer Security (TLS) |
Partial | 19 | 1 | 0 |
RFC 7871 Client Subnet in DNS Queries |
Partial | 38 | 6 | 0 |
RFC 7911 Advertisement of Multiple Paths in BGP |
Supported | 9 | 0 | 0 |
RFC 792 Internet Control Message Protocol |
No public row declared | 6 | 0 | 0 |
RFC 7947 Internet Exchange BGP Route Server |
Supported | 3 | 0 | 0 |
RFC 7950 The YANG 1.1 Data Modeling Language |
No public row declared | 9 | 0 | 0 |
RFC 7999 BLACKHOLE Community |
Partial | 4 | 0 | 0 |
RFC 8050 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions |
Partial | 6 | 1 | 0 |
RFC 8092 BGP Large Communities Attribute |
Supported | 7 | 0 | 0 |
RFC 8097 BGP Prefix Origin Validation State Extended Community |
No public row declared | 5 | 0 | 0 |
RFC 8203 BGP Administrative Shutdown Communication |
Supported | 5 | 0 | 0 |
RFC 8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 |
Partial | 56 | 12 | 0 |
RFC 8277 Using BGP to Bind MPLS Labels to Address Prefixes |
Partial | 34 | 10 | 0 |
RFC 8414 OAuth 2.0 Authorization Server Metadata |
Partial | 7 | 1 | 0 |
RFC 8484 DNS Queries over HTTPS (DoH) |
Partial | 16 | 1 | 0 |
RFC 8571 BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions |
No public row declared | 4 | 0 | 0 |
RFC 8654 Extended Message Support for BGP |
Supported | 12 | 0 | 0 |
RFC 8665 OSPF Extensions for Segment Routing |
Partial | 47 | 14 | 0 |
RFC 8666 OSPFv3 Extensions for Segment Routing |
Partial | 31 | 3 | 0 |
RFC 8669 Segment Routing Prefix Segment Identifier Extensions for BGP |
Partial | 25 | 10 | 0 |
RFC 8671 Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) |
Supported within BMP sender scope | 10 | 0 | 0 |
RFC 8707 Resource Indicators for OAuth 2.0 |
No public row declared | 7 | 0 | 0 |
RFC 8907 The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol |
Partial | 13 | 2 | 0 |
RFC 8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop |
Supported | 6 | 0 | 0 |
RFC 8955 Dissemination of Flow Specification Rules |
Partial | 22 | 4 | 0 |
RFC 8956 Dissemination of Flow Specification Rules for IPv6 |
Partial | 9 | 7 | 0 |
RFC 9003 Extended BGP Administrative Shutdown Communication |
Supported | 4 | 0 | 0 |
RFC 9012 The BGP Tunnel Encapsulation Attribute |
Partial | 75 | 51 | 0 |
RFC 905 ISO Transport Protocol Specification (ISO DP 8073) |
No public row declared | 9 | 0 | 0 |
RFC 9069 Support for Local RIB in the BGP Monitoring Protocol (BMP) |
Supported | 15 | 0 | 0 |
RFC 9072 Extended Optional Parameters Length for BGP OPEN Message |
Partial | 9 | 4 | 0 |
RFC 9085 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing |
Partial | 12 | 9 | 0 |
RFC 9086 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering |
Partial | 12 | 10 | 0 |
RFC 9136 IP Prefix Advertisement in Ethernet VPN (EVPN) |
Partial | 14 | 5 | 0 |
RFC 9234 Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages |
Supported | 19 | 0 | 0 |
RFC 9252 BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) |
Partial | 19 | 8 | 0 |
RFC 9256 Segment Routing Policy Architecture |
Partial | 22 | 6 | 0 |
RFC 9319 The Use of maxLength in the Resource Public Key Infrastructure (RPKI) |
No public row declared | 4 | 0 | 0 |
RFC 9494 Long-Lived Graceful Restart for BGP |
Partial | 25 | 5 | 0 |
RFC 9514 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) |
Partial | 13 | 13 | 0 |
RFC 9552 Distribution of Link-State and Traffic Engineering Information Using BGP |
Partial | 48 | 1 | 0 |
RFC 9568 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 |
Partial | 59 | 2 | 0 |
RFC 9582 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 |
Unsupported | 10 | 0 | 0 |
RFC 9687 Border Gateway Protocol 4 (BGP-4) Send Hold Timer |
Supported | 13 | 0 | 0 |
RFC 9728 OAuth 2.0 Protected Resource Metadata |
No public row declared | 7 | 0 | 0 |
RFC 9830 BGP Extensions for the Advertisement of Segment Routing (SR) Policies |
Partial | 96 | 20 | 0 |
SFLOW-V5 sFlow: A Method for Monitoring Traffic in Switched and Routed Networks |
Experimental | 16 | 3 | 0 |
Summaries that are not enrolled
backlog: the requirements have not been extracted from the document yet; this is work owed rather than a decisionblocked: something outside the summary stops the extraction, and it is named in the reasonnon-normative: the document imposes no MUST-level obligation on an implementation, so there is nothing to gateout-of-scope: the requirements ARE extracted and the owner decided not to offer the feature for now, so the absence is a scope decision rather than a conformance gap
| RFC | Disposition | Reason |
|---|---|---|
DRAFT-IETF-SIDROPS-8210BIS The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 |
backlog | The RPKI to Router Protocol, Version 2. Split out of rfc9582 on 2026-09-01 because the obligations below are stated by this draft and not by RFC 9582, which profiles the ROA certificate. It is not enrolled because its obligations are not yet proven and the draft is still in the RFC Editor queue, so a version bump can restate them. |
RFC 1035 Domain Names - Implementation and Specification |
backlog | Domain Names: Implementation and Specification. Re-authored 2026-07-30 and it now declares 27 MUST-level obligations read from the indicative prose of a 1987 document (0 capitalised keywords, 23 lowercase must), so this is no longer an empty checklist. It is not enrolled because the obligations are not all proven and the unproven ones need an owner ruling, not an implementer's annotation. The obligation with no code path in Ze is zone transfer: Ze performs none, and the owner ruled RFC 1035 out of scope on 2026-08-18, so that work is not to be started. The 512-octet UDP bound and the TC bit ARE enforced -- send calls Msg.Truncate(udpReplyLimit(r)) for a datagram reply in internal/core/dnsserver/handler.go, and udpReplyLimit holds the Section 2.3.4 floor while letting an RFC 6891 Section 6.2.3 OPT record raise it. An unsupported inverse query DOES draw Not Implemented: Authoritative branches on the opcode before any zone lookup, in the same file. It was the one obligation the 73-section walk found OUTSIDE the summary's declared scope and added to it. The response TTL is deliberately not raised to the SOA MINIMUM -- RFC 2308 Section 4 withdrew that rule, hdr in internal/plugins/geodns/server.go applies no floor, and TestRFC2308_NoZoneWideTTLFloor holds the decision. About 6 requirements admit only a positive polarity because miekg/dns owns the wire codec and no Ze-side change can break them. Escalated for scoping per OR-1b. |
RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling |
blocked | VPLS using LDP signaling. Written 2026-09-01 so the public row this RFC has always carried is declared by a summary rather than authored on a page nobody could tie back to a document. It is not enrolled because there is no source text at rfc/full/rfc4762.txt: fetch https://www.rfc-editor.org/rfc/rfc4762.txt, then extract. Ze speaks the BGP-signalled VPLS of RFC 4761 and not this one, so the row claims Unsupported and no obligation here is gated. |
RFC 5065 Autonomous System Confederations for BGP |
blocked | BGP confederations. Written 2026-09-01 for the same reason as the other six rows that had no summary: the public claim now lives in the document it is about. It is not enrolled because there is no source text at rfc/full/rfc5065.txt: fetch https://www.rfc-editor.org/rfc/rfc5065.txt, then extract. The row claims Unsupported, so no obligation here is gated. |
RFC 5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) |
blocked | IS-IS multi-topology routing. Written 2026-09-01 so the public row is declared by a summary. It is not enrolled because there is no source text at rfc/full/rfc5120.txt: fetch https://www.rfc-editor.org/rfc/rfc5120.txt, then extract. Ze runs IS-IS single-topology dual-stack only and the row claims Unsupported, so no obligation here is gated. |
RFC 5925 The TCP Authentication Option |
blocked | The TCP Authentication Option. Written 2026-09-01 so the public row is declared by a summary. It is not enrolled because there is no source text at rfc/full/rfc5925.txt: fetch https://www.rfc-editor.org/rfc/rfc5925.txt, then extract. Ze implements the RFC 2385 TCP MD5 signature option and not TCP-AO, and the row claims Unsupported, so no obligation here is gated. |
RFC 6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs |
out-of-scope | BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs. OUT OF SCOPE by owner decision, 2026-09-01, marked for future development. The extraction is COMPLETE: the source text is at rfc/full/rfc6514.txt and this summary declares all 201 requirements, 133 of them MUST-level, so a later decision to build MVPN starts from the obligations rather than from nothing. What Ze has today is NLRI plumbing and nothing the RFC is about: the Section 4 route-type split (splitMVPN, internal/core/bgp/nlri/nlrisplit/mvpn.go), an NLRI codec, a config route parser for three of the seven route types, and opaque Adj-RIB-In storage. Exactly one MUST-level requirement is met and it is met vacuously -- RFC6514-9.1.1-10 says the Leaf Information Required flag "MUST be set to zero and MUST be ignored on receipt", and Ze ignores it by never parsing a PMSI byte, because knownAttrParsers leaves attribute code 22 nil. Absent entirely: the PMSI Tunnel attribute, the PE Distinguisher Labels attribute (code 27 has no constant), the Source AS and VRF Route Import extended communities, auto-discovery, the C-multicast route exchange, S-PMSI routes, inter-AS and ASBR operation, upstream multicast hop selection (SAFI 129 is unregistered), and every protocol the document leans on -- PIM, mLDP, RSVP-TE P2MP and MSDP. No {gap} annotation is written for any of it: a gap is an ISSUE and this is a DECISION (ai/rules/rfc-compliance.md), and 132 gap rows would record a feature nobody chose to build as 132 conformance failures. |
RFC 6987 OSPF Stub Router Advertisement |
backlog | OSPF Stub Router Advertisement. Its five obligations sit behind bare [LSA]-style category tags, which parse_checklist_line reads as prose rather than as requirements, so the summary captures zero at any level while the source is normative. Declared backlog and not non-normative on purpose: calling it non-normative would launder five unparsed obligations into a decision, which is exactly the shape D5 exists to expose. |
RFC 7454 BGP Operations and Security |
non-normative | BGP Operations and Security, published as BCP 194 with IETF category Best Current Practice. A capitalised MUST / MUST NOT / SHALL / SHALL NOT scan over rfc/full/rfc7454.txt hits four keywords and all four sit inside the RFC 2119 key-words sentence of section 1.1, which tells a reader how to read the other sentences and states no obligation of its own. Outside that sentence the document uses no MUST-level keyword except one NOT REQUIRED in section 5.1, and that phrase negates a requirement instead of stating one. The summary written 2026-08-08 therefore captures 64 requirements and gates none of them: 42 SHOULD, 12 SHOULD NOT, 8 RECOMMENDED, 1 MAY, and the single NOT REQUIRED of section 5.1 recorded at the OPTIONAL level. The document also addresses network administrators rather than protocol implementers, and section 12 states that it "does not aim to describe existing BGP implementations". A zero-MUST BCP can reach the public ledger two ways, as a non-normative disposition or as a manual-walk extraction sign-off with a register-reason, and that choice is a ledger judgement for the owner. Thomas made it on 2026-08-12: non-normative, on the grounds that the scan recorded above finds no MUST-level keyword outside the key-words sentence, so backlog overstated a debt this text does not create. The choice is no longer open. |
RFC 7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension |
backlog | TLS Session Hash and Extended Master Secret Extension. Summary written 2026-08-24 against rfc/full/rfc7627.txt, which was fetched the same day. It declares 27 requirements: 17 MUST-level over 5 sections, 9 at SHOULD level (8 SHOULD / SHOULD NOT plus one NOT RECOMMENDED) and 1 MAY. It is NOT enrolled because not one of the 17 has a producer inside Ze, so neither route to enrolment is an implementer's to take: there is no Ze function a positive and a negative test could tag, and annotating the remainder is a conformance judgement ai/rules/rfc-compliance.md reserves to the owner. WHERE THE OBLIGATIONS ARE DISCHARGED. Go's crypto/tls owns the extension end to end. Its client sets extendedMasterSecret on every ClientHello it builds (makeClientHello, crypto/tls/handshake_client.go), clearing it only for an ECH inner hello; its server copies the client's bit into the ServerHello (serverHandshakeState.processClientHello, crypto/tls/handshake_server.go); the negotiated result lands on Conn.extMasterSecret; and the Section 5.3 abbreviated-handshake mismatch rules are enforced in clientHandshakeState.processServerHello and serverHandshakeState.checkForResumption. Ze holds no ClientHello or ServerHello encoder and no master-secret derivation, so RFC7627-5.1-1, 5.2-1, 5.2-2, 5.2-4, 5.2-6, 5.3-3, 5.3-4, 5.3-6, 5.3-8, 5.3-9, 5.3-10 and 6.4-2 have no Ze-side producer at all. The Section 5.4 downgrade containment (RFC7627-5.4-1 to 5.4-4 and 5.4-6) is enforced below Ze too: Conn.connectionStateLocked selects noEKMBecauseNoEMS on `c.vers != VersionTLS13 && !c.extMasterSecret` (Conn.connectionStateLocked, crypto/tls/conn.go), which is the MUST NOT of RFC7627-5.4-1 executed by the library rather than by its caller. Ze sets no tls.Config.Renegotiation and computes no tls-unique -- the sha256(TLSUnique) fallback was removed from tlsMethod.deriveMSK -- and the authenticator now issues a TLS 1.3 session ticket per RFC 9190 Section 2.1.2, whose resumption is a TLS 1.3 PSK exchange and not the RFC 7627 abbreviated handshake this document governs (newTLSMethod, internal/core/eap/eap_tls.go). WHAT ZE ACTUALLY PRODUCES is the refusal path, and it is two functions in internal/core/eap/eap_tls.go: exportEAPTLSMSK returns the crypto/tls error rather than a zero MSK, and eapTLS12ExportRefused names the peer, the negotiated version, RFC 7627 and the operator's three remedies (move the peer to TLS 1.3 per RFC 9190, add RFC 7627 to its TLS 1.2 stack, or configure another EAP method). RFC 5216 Section 2.3 defines the EAP-TLS MSK as that export, so a TLS 1.2 peer whose session carries no extended master secret cannot authenticate. strongSwan 5.9.14 reaches that state by DEFAULT rather than by limitation: charon ships version_max = 1.2 and negotiates no RFC 7627, while charon.tls.version_max = 1.3 on the same build reaches an established SA (test/interop-ipsec/scenarios/eap-tls13/strongswan.conf, and the failing counterpart is test/interop-ipsec/scenarios/eap-tls). TWO FACTS AN OWNER RULING HAS TO ABSORB. First, RFC 7627 IS OBSOLETE. RFC 9846 (The Transport Layer Security (TLS) Protocol Version 1.3, July 2026) obsoletes RFC 5077, 5246, 6961, 7627, 8422 and 8446; its Appendix D renames the extension to Extended Main Secret and the code point to extended_main_secret, and leaves the Section 4 PRF label unchanged for compatibility; its Appendix E states the only obligation it adds about the extension, a SHOULD that an implementation supporting both TLS 1.3 and earlier versions indicate the use of the Extended Main Secret extension in its APIs whenever TLS 1.3 is used. ai/rules/rfc-compliance.md says the lineage that matters runs FORWARD, so the document that states what Ze owes today is RFC 9846, and rfc/full/rfc9846.txt is not in this repository. Enrolling rfc7627 would gate a superseded text. Second, the tlsunsafeekm override is GONE from this checkout, as of the toolchain bump on 2026-08-25. go.mod pins `toolchain go1.27.0`, whose internal/godebugs/table.go carries `{Name: "tlsunsafeekm", Removed: 27, Old: one}`, so a process that sets it to its old value raises a fatal error before main() rather than getting the unsafe export. crypto/tls agrees at the other end: noEKMBecauseNoEMS (crypto/tls/prf.go) now returns the bare sentence with no override clause at all. So the claim cmd/ze/main.go and the RFC 5216 row of docs/features/rfc-status.md both make, that no override remains, is true of what this tree builds; it was false while the toolchain was 1.26. Escalated for a scoping ruling, per the route rfc1035 and rfc9190 took. |
RFC 8195 Use of BGP Large Communities |
non-normative | Use of BGP Large Communities, IETF category Informational. A capitalised MUST / MUST NOT / SHALL / SHALL NOT / REQUIRED scan over rfc/full/rfc8195.txt hits zero keywords, and the document invokes neither RFC 2119 nor RFC 8174 nor BCP 14 anywhere, so it declares no key-words machinery for a reader to read its prose by. Its own abstract calls it examples and inspiration for operator application of BGP Large Communities. The summary written against it captures 3 requirements and gates none: RFC8195-2-1, RFC8195-2.2-1 and RFC8195-4.3.3-1, all at SHOULD. Section 3.2 and Section 4.1.1 both say an AS could assign a function number, which states a convention rather than an obligation. Thomas ruled on 2026-08-12 that this is non-normative rather than backlog. |
RFC 8326 Graceful BGP Session Shutdown |
blocked | Graceful BGP Session Shutdown. No source text at rfc/full/rfc8326.txt or rfc/drafts/rfc8326.txt, so check_enrolment refuses the enrolment. Fetch https://www.rfc-editor.org/rfc/rfc8326.txt, then extract. |
RFC 8362 OSPFv3 Link State Advertisement (LSA) Extensibility |
out-of-scope | OSPFv3 Link State Advertisement (LSA) Extensibility. OUT OF SCOPE as a document by owner decision, 2026-09-01, marked for future development. The extraction is COMPLETE: the source text is at rfc/full/rfc8362.txt and this summary declares all 50 requirements, 38 of them MUST-level. What Ze has is a by-product of RFC 8666 Segment Routing rather than the framework this document defines: three of the seven Extended LSA types are originated, and only when segment routing is enabled (v6OriginateSR, internal/plugins/ospf/sr_origination_v6.go); receipt decoding is reached from one place and reads Prefix-SIDs alone (v6ReceivedPrefixSIDs, sr_reception_v6.go); no SPF calculation reads an Extended LSA, because the base Router-LSA remains the sole SPF vertex; and there is no RFC 8362 configuration surface and none of its Appendix A or B migration machinery. Nine MUST-level requirements are genuinely unmet and 20 more are met only because Ze performs no action on their subject. The most serious is RFC8362-2-1: the seven LS type constants carry the U-bit clear where Section 2 requires it set, which is recorded as a defect in plan/journal/declared-format-contradicts-payload.md and is a fix rather than a scope question. No {gap} annotation is written here, because the scope decision covers the document and the U-bit defect is tracked where a fix is owed. |
RFC 8538 Notification Message Support for BGP Graceful Restart |
blocked | Notification message support for BGP graceful restart. Written 2026-09-01 so the public row is declared by a summary. It is not enrolled because there is no source text at rfc/full/rfc8538.txt: fetch https://www.rfc-editor.org/rfc/rfc8538.txt, then extract. The row claims Unsupported, so no obligation here is gated. |
RFC 9129 YANG Data Model for the OSPF Protocol |
blocked | YANG Data Model for the OSPF Protocol. No source text at rfc/full/rfc9129.txt or rfc/drafts/rfc9129.txt, so check_enrolment refuses the enrolment. Fetch https://www.rfc-editor.org/rfc/rfc9129.txt, then extract. |
RFC 9190 EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 |
backlog | EAP-TLS 1.3: Using EAP with TLS 1.3. Summary written 2026-08-01, extraction sign-off walked 2026-09-08 (rfc/extraction/rfc9190.json, 52 sites in 36 sections, register prose, 48 mapped and 4 excluded). It declares 52 MUST-level obligations over 20 sections. It is NOT enrolled because 33 of them are not proven in both polarities: 26 carry no tagged test at all and 7 carry a positive only. Measured 2026-09-08 by counting `RFC requirement: RFC9190-<id> <polarity>` tags under internal/, test/, cmd/ and pkg/ against the gated rows of this checklist. Enrolment demands every gated MUST proven in both polarities or annotated, and annotating is the conformance judgement ai/rules/rfc-compliance.md reserves to the owner; the owner ruling of 2026-08-01 chose to implement the features and enrol with everything proven, so the annotation route is closed. WHAT IS BUILT AND PROVEN, all in both polarities. Section 2.3 key derivation: exportEAPTLSMSK (internal/core/eap/eap_tls.go) selects the exporter label EXPORTER_EAP_TLS_Key_Material, the EAP Type octet as context and the 128-octet length whenever the negotiated version is TLS 1.3, and test/interop-ipsec/scenarios/eap-tls13 exercises that path against strongSwan. Section 2.5 protected success indication, both roles: tlsMethod.indicateSuccess (same file) writes the encrypted TLS record carrying application data 0x00 in the round that completes the handshake, and PeerSession.requireSuccessIndication (internal/core/eap/peer_indication.go) refuses the EAP-Success without it; scenario responder-eap-tls13 proves the server half against strongSwan, which logs `missing protected success indication for EAP-TLS with TLS 1.3` when the write is reverted. The peer half is STRICTER than the published RFC, which addresses Section 2.5 only to the server, so no requirement id covers it and its tests carry no RFC requirement tag. Section 2.1.2 and 2.1.3 resumption, both roles: Resumption (internal/core/eap/resumption.go) owns the ticket keys and the client cache per peering, and serverChainCheck.rebuildResumedChains (internal/core/eap/peer_chain.go) rebuilds the chain crypto/tls skips on a resumed handshake so the Section 5.4 check still runs. ALL FIVE Section 5.4 requirements are built as of 2026-09-08: checkChainRevocation (internal/core/eap/revocation.go) walks every certificate on each chain except the trust anchor on both roles (5.4-1), newTLSMethod staples the operator's ocsp-response (5.4-2), checkStapledChainStatus (internal/core/eap/ocsp.go) refuses a CertificateEntry with no valid status while certificate-status-request is set (5.4-3), and startServerCertRecheck (internal/component/ike/engine/postauth_revocation.go) re-checks the chain over https once the Child SA is up, refusing an http responder URL before any connection opens (5.4-4 and 5.4-5). Section 5.10-1 is proven by sixteen tagged units in internal/core/eap/rfc9190_attack_mitigation_test.go over the RFC 7457 Section 2 attacks. THE TWO OBLIGATIONS THAT WERE UNMET IN CODE ARE MET AND PROVEN AS OF 2026-09-08. RFC9190-2.1.9-1, the MUST NOT to set the L bit in an unfragmented message: tlsFragmenter.nextFragment (internal/core/eap/eap_tls.go) is the one producer of outbound EAP-TLS TypeData on both roles, and it now declares a length only where the first fragment is not also the last, so a message that fits in one fragment leaves as a bare flags octet with its TLS data at offset 1. RFC9190-2.1.9-2, the receive half of the same sentence, is proven beside it over tlsFragmenter.reassemble, which takes an unfragmented message with the L bit and without it. RFC9190-1-1, the Section 1 MUST to limit the maximum TLS version to 1.3 unless the administrator enables a later one: newTLSMethod (eap_tls.go) and PeerSession.tlsClientConfig (internal/core/eap/peer.go) each set MaxVersion to tls.VersionTLS13, and ze exposes no leaf that raises that ceiling, so the exception has nothing to switch on. RFC9190-1-1 was added to this checklist by the 2026-09-08 extraction walk, which found the summary had missed it. |
RFC 9384 A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD) |
non-normative | A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD), IETF category Standards Track. The document carries the RFC 2119 / RFC 8174 key-words paragraph at Section 2, and a capitalised MUST / MUST NOT / SHALL / SHALL NOT / REQUIRED scan over rfc/full/rfc9384.txt hits those five words on one line only, line 101, which is the key-words sentence itself. That sentence tells a reader how to read the other sentences and states no obligation of its own. Outside it the text uses no MUST-level keyword anywhere. The summary written 2026-09-01 therefore captures three requirements and gates none: RFC9384-3-1 at Section 3, and RFC9384-4-1 and RFC9384-4-2 at Section 4, all three at SHOULD. Section 5 says the subcode "is purely informational and has no impact on the BGP Finite State Machine beyond that already documented by [RFC4271], Sections 6.6 and 6.7", so the document adds one registry value and three recommendations about using it. A zero-MUST document can reach the public ledger two ways, as this disposition or as a manual-walk extraction sign-off with a register-reason. This disposition is the route taken, because the sign-off at rfc/extraction/rfc9384.json declares the register the source derives, prose, and the second route would need it to declare the weaker manual-walk grade instead. That sign-off bounds the three-row checklist against the source text. |