Quality

RFC Compliance Gate Report

How far Ze meets each RFC it implements, and the tests that prove it. Source: internal/le/rfc, rfc/short/*.md, and rfc/audit/*/*.json.

How to read this page

This page shows how far Ze meets the standards (RFCs) it implements, and how that is proven. For each RFC, Ze keeps a summary that lists every requirement the RFC states and links each requirement to the tests that prove Ze meets it. An automatic check, the gate, reads those summaries and the tests, and the figures on this page are computed from the same summaries and tests.

If you are evaluating Ze for one role, start with Coverage by profile. To check one RFC, find it in the Enrolled RFCs table and open its own page, which lists each requirement and the tests behind it. The terms below are used throughout this page; the per-RFC pages and Ze's source use the same terms.

Glossary of the terms this page uses
Summary
Ze's file for one RFC: it lists the RFC's requirements, the tests behind each one, and the support status Ze publishes for the RFC.
Requirement
one obligation an RFC states, kept in the summary with an identifier such as RFC4271-8.2.2-12 that names the RFC and its section.
MUST-level (mandatory)
a requirement stated with MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT. The optional levels are MAY, NOT RECOMMENDED, OPTIONAL, RECOMMENDED, SHOULD, SHOULD NOT.
Enrolled
an RFC whose summary the gate holds Ze to. Summaries that are not enrolled are listed at the end of the page, each with its reason.
Gate, gated
the gate is the automatic check that reads every summary and the tests. A gated requirement is a MUST-level requirement of an enrolled RFC, one the gate holds Ze to. Every share on this page is taken over the gated requirements.
Positive and negative test (polarity)
a positive test proves Ze does what the requirement demands; a negative test proves Ze refuses what the requirement forbids. Tested both ways means both exist.
Tagged unit
one test that names, in a tag, the requirement it proves. One requirement can have several.
Recorded break
the proof that a test can fail: the code under the test was broken once on purpose, the test was seen to fail, and a record stores what the test, its claim and the code looked like. The break is not run again. Ze's source calls this a discrimination record.
Escaped
a tagged unit whose record claims that no break of the code exists. It is not counted as a proof.
Lapsed
a recorded break whose test, claim or code has changed since it was recorded. It is not counted as a proof.
Gap
a requirement the summary openly declares Ze does not meet yet. Every gap is work Ze owes.
Annotation
a note on a requirement, written in braces, that says why it needs no ordinary pair of tests. {single-polarity}: the requirement admits no counter-case, so one direction plus a recorded reason is the whole proof. {not-applicable}: the obligation does not bind Ze. {feature-declined}: the obligation applies only to a feature the RFC makes optional and Ze does not offer. {lower-layer}: a layer under Ze performs the behavior, on state Ze installs into that layer. {gap}: a declared gap. A partial requirement has tests for part of it; the rest is unmet or unproven and earns no credit.
Linux cannot do this
a verified kernel limitation prevents the required primitive. The obligation still binds Ze and remains unmet. The annotation names the Linux Limitations Register entry; it earns no proof credit and stays in the denominator.
Ceiling
attainable requirements over the same total as the proof figure, under current classifications. This is not an immutable Linux maximum. Not-applicable and feature-declined classifications can be revisited; unwalked RFCs have no ceiling.
Walked, sign-off
a reviewer read the RFC's own text sentence by sentence and checked the requirement list against it; the sign-off records that review. Not walked means the review has not been done, so no figure is counted.
Excluded sentence
a sentence of the RFC that the review decided not to turn into a requirement, with a kind and a reason.
Semantic verdict
a reviewer's recorded judgement that a requirement's tests enforce what the requirement says. Fresh: still current. Shifted: the test is unchanged and only the file around it moved. Stale: what it judged has changed.

The gate holds Ze to every MUST-level requirement of the RFCs it implements. The cards below say how many of those requirements a test proves, how many do not bind Ze, and how many Ze still owes.

Overall

the populations every share below is taken over

Gated MUSTs4,5567,733 extracted from 240 summaries

MUST-level requirements the gate HOLDS, across the 167 RFCs Ze implements, out of 4,715 across the 190 RFCs inspected. A population, not a result: the shares beside it are what says how Ze stands. All 195 were analyzed for every MUST they state, so this population cannot be short.

Out of scope715of 4,556 gated MUSTs

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

Proven by test63.4%2,888 of 4,556 gated MUSTs across the 167 RFCs Ze implements

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

Tested both ways52.8%2,405 of 4,556 gated MUSTs

a positive test proves Ze does what the requirement demands and a negative one proves it refuses what the requirement forbids

One polarity plus reason10.6%483 of 4,556 gated MUSTs

the requirement admits no counter-case, so one polarity plus a recorded reason is the whole proof available for it

One polarity, unexcused0.0%0 of 4,556 gated MUSTs

one direction is tested, the other is neither tested nor excused, and nothing states which

Proven by a recorded break65.8%6,018 of 9,140 tagged units in enrolled RFCs, 4 escaped and 236 lapsed

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

Not applicable14.5%662 of 4,556 gated MUSTs

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

Met below Ze4.7%215 of 4,556 gated MUSTs

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

Optional feature declined1.2%53 of 4,556 gated MUSTs

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

Linux cannot do this0.0%0 of 4,556 gated MUSTs

Linux cannot provide the primitive this requirement needs. The obligation still binds Ze and remains unmet; it stays in every denominator and earns no proof credit

Semantic verdicts2,2023 shifted, 68 stale, 2,442 missing

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

Partial proof; remaining gap0.3%14 of 4,556 gated MUSTs

scoped tests exist; the remaining obligation is unmet or unproven, with zero whole-requirement credit

No test at all15.9%724 of 4,556 gated MUSTs

no test carries the requirement id, whether or not a gap states why

Gate verdictRED151 open gate issues

whether ./le rfc check passes over this tree

The 9 shares marked as a part above are the whole of the 4,556 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.

CardTone hereWhy 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
Partial proof; remaining gap bad green at zero, RED above it: a tested clause cannot prove the whole requirement
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
Linux cannot do this neutral neutral at every value: an evidenced platform limit is neither a proof nor a scope exemption
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

151 open gate issues. Check results below names them, up to the 25 this page inlines.

Contributors reproduce it with ./le rfc check. The gate's own line reads rfc-requirements: 151 violation(s).

Coverage by profile

A profile groups the RFCs one kind of deployment needs. If you are evaluating Ze for one role, its profile page gives the figures for that role alone.

This page covers every RFC. Each use case Ze serves and each technology aggregate has its own page, with its mandatory and optional figures and the RFCs it lists ordered roots to leaves: RFC coverage by profile.

Who implements each document

Some RFCs are carried out by Ze's own code, some by a layer under or beside Ze, and some oblige no implementation at all. This section says which is which, because the figures on this page count only what Ze's own code is held to.

The ledger counts what Ze implements in its own Go. A document another layer performs leaves the gated population and names what performs it, and where Ze can observe the behavior the requirement still carries a test over the state Ze installs.

Implemented bySummariesWhat it means
foundation 8 The document defines, registers or describes, and obliges no implementer.
mixed 26 Ze implements part in Go and another layer performs the rest. The part Ze's Go answers stays gated.
third-party 9 A layer under or beside Ze performs it and Ze holds no Go code for it, so its MUSTs are not gated against Ze.
ze 197 Ze's own Go implements the document, and its MUSTs are gated.

foundation

RFC 3882, RFC 4033, RFC 6071, RFC 7454, RFC 7948, RFC 8195, RFC 9129, RFC 9319

mixed

RFC 2385, RFC 2661, RFC 3022, RFC 3032, RFC 3768, RFC 3948, RFC 4106, RFC 4213, RFC 4301, RFC 4302, RFC 4303, RFC 4552, RFC 4787, RFC 4861, RFC 5082, RFC 5280, RFC 5382, RFC 5635, RFC 5798, RFC 7084, RFC 7634, RFC 792, RFC 7950, RFC 7999, RFC 8221, RFC 9568

third-party

RFC 2003, RFC 2473, RFC 2784, RFC 2890, RFC 3031, RFC 4862, RFC 6482, RFC 7627, RFC 9582

Requirement buckets

The detailed accounting behind the cards: every gated requirement falls in exactly one of these buckets, so the rows add up to the whole. The last column names the condition that puts a requirement in each bucket.

  • Positive and negative tests: 2,405 (52.8%)
  • One polarity plus reason: 483 (10.6%)
  • Declared gap: 724 (15.9%)
  • Partial proof; remaining gap: 14 (0.3%)
  • Not applicable: 662 (14.5%)
  • Met below Ze: 215 (4.7%)
  • Optional feature declined: 53 (1.2%)

The bar is every one of the 4,556 gated MUST-level requirements. 715 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.

BucketCountShare of gatedSource condition
Positive and negative tests 2,405 52.8% positive tag + negative tag
One polarity plus reason 483 10.6% {single-polarity} annotation + required tag
Declared gap 724 15.9% {gap} annotation + public ledger disclosure
Partial proof; remaining gap 14 0.3% partial annotation; tested clause only, zero whole-requirement credit
One polarity, unexcused 0 0.0% tag without annotation
Missing, unexcused 0 0.0% no tag, no annotation
Not applicable 662 14.5% {not-applicable} annotation: the obligation does not bind Ze, so it is scope rather than coverage
Met below Ze 215 4.7% {lower-layer} annotation + named producer
Optional feature declined 53 1.2% {feature-declined} annotation + quoted RFC sentence: the obligation does not bind Ze, so it is scope rather than coverage
Linux cannot do this 0 0.0% verified kernel limitation; the obligation still binds and remains unmet
Gated MUST-level requirements4,556100.0%every gated MUST falls in exactly one bucket above, the 715 that do not bind Ze included. This total is the denominator of every share above it

Gap disclosure

A gap is a requirement Ze does not meet yet and says so in public. This section shows the public status of the RFCs that declare gaps, and names any RFC published as Supported that still declares one.

Public status for RFCs with gapsRFCs
Partial 66
Experimental 14
Supported 2

Supported rows that still disclose a gap

  • 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. One feature is absent by decision, and it is not a conformance gap: ze starts no locally initiated route refresh (soft clear only asks the peer for its refresh), so the BoRR obligation conditional on one, RFC7313-4-13, is annotated {feature-declined}.

Exclusion disclosure

Not every sentence of an RFC becomes a requirement. This section counts the sentences a review left out, by the reason given, so you can check what was left out and why.

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, 4,858 sentences were mapped to a requirement and 2,241 were declined. 3 of those declines are not scope at all: they are obligations Ze OWES, relocated to a named spec, and they are stated apart below.

227 of 240 summaries carry an extraction sign-off, 195 of them among the 195 enrolled. The other 13 have no exclusion ledger at all, so what follows counts the walks that HAVE been done and is not the whole picture.

Excluded kindMeansSitesSummariesWhat it means
duplicate-of never bound Ze 583 90 the same obligation is already captured under another requirement id
not-a-requirement never bound Ze 578 123 the sentence states a fact or describes another document, and directs no implementation
binds-another-role never bound Ze 551 47 the obligation is addressed to a role Ze never acts as
feature-out-of-scope never bound Ze 402 21 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 98 41 the obligation belongs to another document that this one only cites
advisory-in-context never bound Ze 26 13 the sentence advises on applying a rule stated elsewhere and adds no obligation of its own
relocated-to-spec Ze owes it 3 2 the obligation is real and unbuilt, and a named spec owes it
Sentences declined-2,241-2,238 say the obligation never bound Ze and 3 say Ze owes it, of 7,099 normative sentences the walks found

duplicate-of (583): DRAFT-IETF-BESS-MUP-SAFI, RFC 1035, RFC 1195, RFC 1661, RFC 2131, RFC 2181, RFC 2205, RFC 2516, RFC 2661, RFC 2759, RFC 2865, RFC 2866, RFC 2869, RFC 2890, RFC 2966, RFC 3031, RFC 3032, RFC 3101, RFC 3209, RFC 3579, RFC 3623, RFC 3748, RFC 3768, RFC 3786, RFC 3948, RFC 3954, RFC 4035, RFC 4090, RFC 4213, RFC 4271, RFC 4301, RFC 4302, RFC 4303, RFC 4364, RFC 4456, RFC 4555, RFC 4577, RFC 4684, RFC 4760, RFC 4787, RFC 4862, RFC 5036, RFC 5072, RFC 5216, RFC 5250, RFC 5280, RFC 5303, RFC 5340, RFC 5382, RFC 5549, RFC 5561, RFC 5798, RFC 5880, RFC 5998, RFC 6549, RFC 6793, RFC 6810, RFC 7011, RFC 7166, RFC 7296, RFC 7311, RFC 7432, RFC 7474, RFC 7854, RFC 7871, RFC 8210, RFC 8221, RFC 8247, RFC 8277, RFC 8414, RFC 8522, RFC 8665, RFC 8669, RFC 8671, RFC 8907, RFC 8950, RFC 8955, RFC 9003, RFC 9012, RFC 9069, RFC 9136, RFC 9190, RFC 9234, RFC 9252, RFC 9494, RFC 9552, RFC 9568, RFC 9728, RFC 9915, SFLOW-V5

not-a-requirement (578): DRAFT-ABRAITIS-BGP-VERSION-CAPABILITY, DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY, DRAFT-WALTON-BGP-HOSTNAME-CAPABILITY, RFC 1035, RFC 1071, RFC 1195, RFC 1332, RFC 1334, RFC 1350, RFC 1661, RFC 1994, RFC 2131, RFC 2132, RFC 2181, RFC 2205, RFC 2328, RFC 2347, RFC 2348, RFC 2349, RFC 2385, RFC 2473, RFC 2516, RFC 2545, RFC 2661, RFC 2759, RFC 2782, RFC 2784, RFC 2865, RFC 2869, RFC 2918, RFC 2966, RFC 3022, RFC 3031, RFC 3032, RFC 3101, RFC 3209, RFC 3579, RFC 3623, RFC 3748, RFC 3765, RFC 3768, RFC 3882, RFC 3948, RFC 4033, RFC 4035, RFC 4271, RFC 4301, RFC 4303, RFC 4360, RFC 4364, RFC 4456, RFC 4552, RFC 4577, RFC 4684, RFC 4724, RFC 4761, RFC 4787, RFC 4861, RFC 4862, RFC 5036, RFC 5176, RFC 5250, RFC 5280, RFC 5282, RFC 5301, RFC 5303, RFC 5310, RFC 5382, RFC 5392, RFC 5443, RFC 5492, RFC 5575, RFC 5701, RFC 5709, RFC 5798, RFC 5881, RFC 5883, RFC 6071, RFC 6286, RFC 6396, RFC 6482, RFC 7296, RFC 7427, RFC 7454, RFC 7474, RFC 7534, RFC 7535, RFC 7606, RFC 7705, RFC 7854, RFC 7858, RFC 7871, RFC 7911, RFC 792, RFC 7948, RFC 7999, RFC 8050, RFC 8097, RFC 8221, RFC 8247, RFC 8522, RFC 8571, RFC 8654, RFC 8669, RFC 8955, RFC 8956, RFC 905, RFC 9072, RFC 9085, RFC 9086, RFC 9117, RFC 9190, RFC 9252, RFC 9370, RFC 9384, RFC 9494, RFC 9514, RFC 9552, RFC 9568, RFC 9582, RFC 9687, RFC 9830, SFLOW-V5

binds-another-role (551): DRAFT-IETF-BESS-MUP-SAFI, DRAFT-IETF-SIDROPS-ASPA-VERIFICATION, RFC 1035, RFC 1195, RFC 1350, RFC 1661, RFC 1997, RFC 2132, RFC 2545, RFC 2759, RFC 2865, RFC 2866, RFC 2869, RFC 3032, RFC 3579, RFC 3748, RFC 4106, RFC 4301, RFC 4302, RFC 4303, RFC 4360, RFC 4364, RFC 4456, RFC 4577, RFC 4761, RFC 4861, RFC 5176, RFC 5280, RFC 5561, RFC 5575, RFC 5685, RFC 5998, RFC 6396, RFC 7011, RFC 7012, RFC 7296, RFC 7535, RFC 7854, RFC 7871, RFC 8522, RFC 8654, RFC 8907, RFC 8955, RFC 9552, RFC 9728, RFC 9915, SFLOW-V5
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.

feature-out-of-scope (402): RFC 1195, RFC 1332, RFC 2131, RFC 3748, RFC 4090, RFC 4271, RFC 4301, RFC 5082, RFC 5176, RFC 5216, RFC 5280, RFC 5305, RFC 7084, RFC 7634, RFC 7950, RFC 8221, RFC 8247, RFC 8671, RFC 905, RFC 9069, RFC 9774

cross-document (98): DRAFT-ABRAITIS-BGP-VERSION-CAPABILITY, DRAFT-IETF-SIDROPS-ASPA-VERIFICATION, RFC 1195, RFC 1334, RFC 2205, RFC 2545, RFC 2782, RFC 2869, RFC 2966, RFC 3032, RFC 3101, RFC 3579, RFC 3748, RFC 3948, RFC 4033, RFC 4303, RFC 4364, RFC 4577, RFC 4724, RFC 4761, RFC 4818, RFC 5082, RFC 5176, RFC 5250, RFC 5280, RFC 5282, RFC 5308, RFC 5492, RFC 5575, RFC 6071, RFC 7474, RFC 7535, RFC 7854, RFC 7950, RFC 8571, RFC 8654, RFC 8955, RFC 8956, RFC 9069, RFC 9085, RFC 9252

advisory-in-context (26): RFC 1035, RFC 2866, RFC 3032, RFC 3748, RFC 3948, RFC 4552, RFC 4761, RFC 5176, RFC 7084, RFC 7474, RFC 8221, RFC 8247, RFC 8955

Obligations relocated to a spec

These 3 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.

RFCReserved idThe obligationThe spec that owes it
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 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

The RFCs that declare the most gaps. If one of them matters to your deployment, its own page names each gap.

RFCDeclared gapsPublic status
RFC 5036 59 Experimental
RFC 7950 46 Partial
RFC 2205 43 Experimental
RFC 9012 42 Partial
RFC 4301 34 Partial
RFC 3209 32 Experimental
DRAFT-IETF-BESS-MUP-SAFI 30 Partial
RFC 5280 23 Partial
RFC 7084 20 Partial
RFC 9915 19 Partial
RFC 5561 16 Partial
RFC 1661 15 Partial

How this is checked

Where the figures come from: the files that hold the requirements and the tests, and the command that reproduces the verdict. You do not need this section to read the results.

This gate runs before a commit is verified: ./le rfc check is 1 stage of the 57 that ./le verify current runs.

InputProducerWhat it answered here
Reproduce it ./le rfc check 1 of 57 full-mode verify stages run it
Requirement source rfc/short/*.md 4,715 gated MUST-level requirements
Enrolment rfc/short/*.md, the | Enrolment | Meta row 195 enrolled RFCs
Test tags internal/, pkg/, test/ 9,461 resolved tags
Public ledger rfc/short/*.md, the | Support | Meta row 82 RFCs with gaps, 2 Supported with Remaining
Semantic audits rfc/audit/*/*.json 2,202 fresh, 3 shifted, 68 stale, 2,442 missing
Pre-commit verification internal/le/verify/engine/stages.go ./le rfc check, 1 of 57 full-mode stages
Published artifacts data/rfc-compliance.json, data/rfc-requirements.json the same answers this page renders, machine-readable

Check results

The gate runs several groups of checks. Each line below says what one group verifies and whether it passed, and for a group that failed, what that means for the figures. The raw findings, written for Ze's contributors, are in the collapsed block after the list.

  • Requirement lists: Passed. Each RFC's requirement list is readable and consistent: requirement identifiers are not reused or lost, each requirement quotes the RFC text it cites, and the links it declares between RFCs and profiles agree with the RFC texts.
  • Test evidence: Passed. Every gated MUST-level requirement has its tests, or an annotation that says why not, test evidence already recorded is not lost, and every test that claims a requirement compiles and is named for what it covers.
  • Requirement annotations: Passed. Every annotation that excuses a requirement from Ze's own tests still names code that exists, quotes the RFC sentence it relies on, or names a verified blocking kernel entry in the Linux limitations register with evidence for that exact requirement at the shipped kernel version.
  • Published support status: Passed. The support status each RFC publishes agrees with its requirements and its declared gaps, and a status that promises support is backed by a review of the RFC text.
  • Reviewer verdicts: Failed, 73 problems. Each reviewer verdict recorded on a requirement is well formed and still describes the code and tests it judged. What this means: A reviewer verdict is malformed or out of date, and that requirement must be reviewed again before the verdict counts.
  • Recorded breaks: Failed, 78 problems. Each recorded break still matches the test, the claim and the code it was recorded against, and no recorded proof is lost. What this means: A test's proof is missing or no longer matches what it rests on, so it is not counted as proven by a recorded break.
  • Reviews of RFC text: Passed. Each sign-off of a sentence-by-sentence review of an RFC's text is valid and current.
For contributors: the raw findings and the commands that fix them
RFCRequirementLevelWhat is wrongThe requirement
- - - rfc/short/rfc1195.md:430: RFC1195-4.4-1 has a STALE audit verdict -- what it judged changed: internal/plugins/fib/kernel/rfc1195_onlink_integration_linux_test.go::TestFIBOnLinkAdjacencyAndUnsupportedPrefix (func-scoped), internal/plugins/fib/kernel/rfc1195_onlink_integration_linux_test.go::TestFIBOnLinkAdjacencyAndUnsupportedPrefix#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc1195 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc1195.md:431: RFC1195-4.4-2 has a STALE audit verdict -- what it judged changed: internal/plugins/isis/transport/rfc1195_ish_integration_linux_test.go::TestRFC1195ISHVethTransport (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc1195 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc1195.md:433: RFC1195-4.5-1 has a STALE audit verdict -- what it judged changed: internal/plugins/fib/kernel/rfc1195_onlink_integration_linux_test.go::TestFIBOnLinkAdjacencyAndUnsupportedPrefix (func-scoped), internal/plugins/fib/kernel/rfc1195_onlink_integration_linux_test.go::TestFIBOnLinkAdjacencyAndUnsupportedPrefix#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc1195 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc2131.md:485: RFC2131-2-3 has a STALE audit verdict -- what it judged changed: internal/plugins/iface/dhcp/rfc2131_dhcp_flags_integration_linux_test.go::TestRFC2131ClientRenewalSetsReservedFlagsBitsToZero (func-scoped), internal/plugins/iface/dhcp/rfc2131_dhcp_flags_integration_linux_test.go::TestRFC2131ClientSetsReservedFlagsBitsToZero (func-scoped), internal/plugins/iface/dhcp/rfc2131_dhcp_flags_integration_linux_test.go::TestRFC2131ClientSetsReservedFlagsBitsToZero#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc2131 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc2205.md:189: RFC2205-x-1 has a STALE audit verdict -- what it judged changed: internal/plugins/rsvpte/rfc2205_transport_integration_linux_test.go::TestIntegrationRSVPPathCarriage (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc2205 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc2205.md:252: RFC2205-3-37 has a STALE audit verdict -- what it judged changed: internal/plugins/rsvpte/rfc2205_transport_integration_linux_test.go::TestIntegrationRSVPPathAvoidsDataFEC (func-scoped), internal/plugins/rsvpte/rfc2205_transport_integration_linux_test.go::TestIntegrationRSVPPathCarriage (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc2205 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc2205.md:255: RFC2205-3-40 has a STALE audit verdict -- what it judged changed: internal/plugins/rsvpte/rfc2205_transport_integration_linux_test.go::TestIntegrationRSVPPathCarriage (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc2205 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc2205.md:256: RFC2205-3-41 has a STALE audit verdict -- what it judged changed: internal/plugins/rsvpte/rfc2205_transport_integration_linux_test.go::TestIntegrationRSVPPathCarriage (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc2205 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc2328.md:876: RFC2328-4.4-1 has a STALE audit verdict -- what it judged changed: internal/plugins/ospf/transport/rfc2328_transport_integration_linux_test.go::TestOSPFTransportAllDRoutersReceive (func-scoped), internal/plugins/ospf/transport/rfc2328_transport_integration_linux_test.go::TestOSPFTransportVethMulticastRoundTrip (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc2328 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc2328.md:879: RFC2328-8.1-1 has a STALE audit verdict -- what it judged changed: internal/plugins/ospf/transport/rfc2328_unnumbered_source_linux_test.go::TestOSPFRefusesDeviceWithoutRouterAddress (func-scoped), internal/plugins/ospf/transport/rfc2328_unnumbered_source_linux_test.go::TestOSPFUnnumberedSourcesFromDonorAddress (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc2328 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:196: RFC3768-6.4.2-2 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPBackupDoesNotForwardVirtualMACFrames (func-scoped), internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPBackupDoesNotForwardVirtualMACFrames#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:203: RFC3768-6.4.3-1 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly (func-scoped), internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:204: RFC3768-6.4.3-2 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPBackupDoesNotForwardVirtualMACFrames (func-scoped), internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPBackupDoesNotForwardVirtualMACFrames#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:215: RFC3768-7.1-4 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/transport/rfc_rx_iface_verdict_linux_test.go::TestRxAdvertScopedToReceivingInterface (func-scoped), internal/plugins/vrrp/transport/rfc_rx_iface_verdict_linux_test.go::TestRxAdvertScopedToReceivingInterface#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:221: RFC3768-7.2-2 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/transport/rfc_tx_verdict_linux_test.go::TestTxAdvertV4OnWire (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:222: RFC3768-7.2-3 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/transport/rfc_tx_verdict_linux_test.go::TestTxAdvertV4OnWire (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:223: RFC3768-7.2-4 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/transport/rfc_tx_verdict_linux_test.go::TestTxAdvertV4OnWire (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:224: RFC3768-8.1-1 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/redirect_integration_linux_test.go::TestVRRPRedirectSourceFollowsVirtualMAC (func-scoped), internal/plugins/vrrp/redirect_integration_linux_test.go::TestVRRPRedirectSourceFollowsVirtualMAC#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:225: RFC3768-8.2-1 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/owner_answer_integration_linux_test.go::TestVRRPOwnerAnswersWithVirtualMACOnly (func-scoped), internal/plugins/vrrp/owner_answer_integration_linux_test.go::TestVRRPOwnerAnswersWithVirtualMACOnly#2 (func-scoped), internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly (func-scoped), internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc3768.md:226: RFC3768-8.2-4 has a STALE audit verdict -- what it judged changed: internal/plugins/vrrp/owner_answer_integration_linux_test.go::TestVRRPOwnerAnswersWithVirtualMACOnly (func-scoped), internal/plugins/vrrp/owner_answer_integration_linux_test.go::TestVRRPOwnerAnswersWithVirtualMACOnly#2 (func-scoped), internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly (func-scoped), internal/plugins/vrrp/vmac_state_integration_linux_test.go::TestVRRPNonOwnerMasterAnswersARPWithVirtualMACOnly#2 (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc3768 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc4271.md:816: RFC4271-8.2.2-20 has a STALE audit verdict -- what it judged changed: internal/component/bgp/fsm/fsm.go::handleIdle (func-scoped), internal/component/bgp/reactor/peer_run.go::runOnce (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc4271 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc4271.md:821: RFC4271-8.2.2-12 has a STALE audit verdict -- what it judged changed: internal/component/bgp/fsm/rfc4271_connect_retry_test.go::TestRFC4271ConnectRetryCounterOnVersionErrorPerState (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc4271 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc4271.md:822: RFC4271-8.2.2-13 has a STALE audit verdict -- what it judged changed: internal/component/bgp/fsm/fsm.go::handleActive (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc4271 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc4271.md:824: RFC4271-8.2.2-15 has a STALE audit verdict -- what it judged changed: internal/component/bgp/fsm/rfc4271_connect_any_other_event_test.go::TestRFC4271ConnectActiveAnyOtherEventCountsAndDropsToIdle (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc4271 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -
- - - rfc/short/rfc4301.md:542: RFC4301-5.1-7 has a STALE audit verdict -- what it judged changed: internal/component/ike/engine/child.go::installChildSA (func-scoped). This is NOT a line shift and ./le rfc reseal will refuse it. Re-read rfc4301 with the ze-rfc-audit skill (ai/skills/ze-rfc-audit.md) -

126 further findings not shown here. The whole list is in data/rfc-compliance.json, and each one is on its own RFC's page under the requirement it names.

Enrolled RFCs

Every RFC the gate holds Ze to, with its own figures. Open an RFC to see each of its requirements and the tests behind it.

Status
the support status the RFC's summary declares
Mandatory
the share of the RFC's MUST, MUST NOT, REQUIRED, SHALL and SHALL NOT requirements a test proves by a recorded break. "not walked" means the requirement list has not yet been checked against the RFC text, so no figure is counted; "no profile" means the ledger carries no figure for the RFC. The ceiling below each bar is the attainable share under current classifications
Optional
the same proof and ceiling shares for its MAY, NOT RECOMMENDED, OPTIONAL, RECOMMENDED, SHOULD and SHOULD NOT requirements
MUSTs
the mandatory requirements the gate holds Ze to
Gaps
requirements the summary declares Ze does not meet yet
Gaps tested
of those gaps, the ones a test demonstrates
Untested
mandatory requirements with no test at all

Mandatory ceiling: 4033 of 5120 (78.8%); excluded: Optional feature not offered (classification can be revisited): 61 of 5120 (1.2%); Met by a lower layer: 215 of 5120 (4.2%); Not applicable (classification can be revisited): 811 of 5120 (15.8%). Optional ceiling: 2278 of 2302 (99.0%); excluded: Optional feature not offered (classification can be revisited): 2 of 2302 (0.1%); Not applicable (classification can be revisited): 22 of 2302 (1.0%). Lowest mandatory ceiling: rfc2003 0 of 13 (0.0%). Lowest optional ceiling: rfc4577 2 of 20 (10.0%). Ceilings describe current classifications, not an immutable Linux maximum. Not-applicable and feature-declined classifications can be revisited. Every gap remains work Ze owes.

RFCStatusMandatoryOptionalMUSTsGapsGaps testedUntested
DRAFT-ABRAITIS-BGP-VERSION-CAPABILITY Software Version Capability for BGP Partial 11 of 11 (100.0%)Ceiling: 11 of 11 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 11 0 0 0
DRAFT-ABRAITIS-IDR-ADDPATH-PATHS-LIMIT Scalability Considerations for ADD-PATH with PATHS-LIMIT Supported 1 of 4 (25.0%)Ceiling: 4 of 4 (100.0%) 3 of 3 (100.0%)Ceiling: 3 of 3 (100.0%) 4 0 0 0
DRAFT-IETF-BESS-MUP-SAFI BGP Extensions for the Mobile User Plane (MUP) SAFI Partial 17 of 47 (36.2%)Ceiling: 47 of 47 (100.0%) 0 of 20 (0.0%)Ceiling: 20 of 20 (100.0%) 47 30 0 0
DRAFT-IETF-IDR-BGP-BFD-STRICT-MODE BGP BFD Strict-Mode Partial 4 of 4 (100.0%)Ceiling: 4 of 4 (100.0%) no rowsCeiling: no rows 4 0 0 0
DRAFT-IETF-IDR-LINKLOCAL-CAPABILITY Link-Local Next Hop Capability for BGP Partial 13 of 15 (86.7%)Ceiling: 14 of 15 (93.3%); excluded: Not applicable (classification can be revisited): 1 of 15 (6.7%) 0 of 12 (0.0%)Ceiling: 12 of 12 (100.0%) 15 1 0 0
DRAFT-IETF-SIDROPS-ASPA-VERIFICATION BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects Partial 6 of 8 (75.0%)Ceiling: 8 of 8 (100.0%) 0 of 10 (0.0%)Ceiling: 10 of 10 (100.0%) 8 1 0 0
DRAFT-WALTON-BGP-HOSTNAME-CAPABILITY Hostname Capability for BGP Supported no rowsCeiling: no rows 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 0 0 0 0
RFC 1071 Computing the Internet Checksum Partial 5 of 6 (83.3%)Ceiling: 6 of 6 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 6 0 0 0
RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments Experimental 25 of 41 (61.0%)Ceiling: 34 of 41 (82.9%); excluded: Not applicable (classification can be revisited): 7 of 41 (17.1%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 41 0 0 0
RFC 1332 The PPP Internet Protocol Control Protocol (IPCP) Partial 6 of 8 (75.0%)Ceiling: 7 of 8 (87.5%); excluded: Not applicable (classification can be revisited): 1 of 8 (12.5%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 8 1 0 0
RFC 1334 PPP Authentication Protocols Partial 11 of 13 (84.6%)Ceiling: 13 of 13 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 13 0 0 0
RFC 1350 The TFTP Protocol (Revision 2) Supported 6 of 10 (60.0%)Ceiling: 8 of 10 (80.0%); excluded: Not applicable (classification can be revisited): 2 of 10 (20.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 10 0 0 0
RFC 1661 The Point-to-Point Protocol (PPP) Partial 39 of 76 (51.3%)Ceiling: 70 of 76 (92.1%); excluded: Not applicable (classification can be revisited): 6 of 76 (7.9%) 0 of 25 (0.0%)Ceiling: 25 of 25 (100.0%) 76 15 0 0
RFC 1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses Partial no rowsCeiling: no rows no rowsCeiling: no rows 0 0 0 0
RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP) Partial 8 of 16 (50.0%)Ceiling: 16 of 16 (100.0%) 2 of 11 (18.2%)Ceiling: 11 of 11 (100.0%) 16 3 0 0
RFC 1997 BGP Communities Attribute Supported 3 of 5 (60.0%)Ceiling: 5 of 5 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 5 0 0 0
RFC 2131 Dynamic Host Configuration Protocol Partial 18 of 71 (25.4%)Ceiling: 47 of 71 (66.2%); excluded: Not applicable (classification can be revisited): 24 of 71 (33.8%) 2 of 38 (5.3%)Ceiling: 38 of 38 (100.0%) 71 14 0 0
RFC 2132 DHCP Options and BOOTP Vendor Extensions Partial 1 of 34 (2.9%)Ceiling: 9 of 34 (26.5%); excluded: Not applicable (classification can be revisited): 25 of 34 (73.5%) 0 of 34 (0.0%)Ceiling: 34 of 34 (100.0%) 34 1 0 0
RFC 2181 Clarifications to the DNS Specification Partial 12 of 23 (52.2%)Ceiling: 18 of 23 (78.3%); excluded: Optional feature not offered (classification can be revisited): 1 of 23 (4.3%); Not applicable (classification can be revisited): 4 of 23 (17.4%) 1 of 47 (2.1%)Ceiling: 47 of 47 (100.0%) 23 0 0 0
RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification Experimental 26 of 75 (34.7%)Ceiling: 74 of 75 (98.7%); excluded: Met by a lower layer: 1 of 75 (1.3%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 75 43 0 0
RFC 2328 OSPF Version 2 Partial 57 of 67 (85.1%)Ceiling: 67 of 67 (100.0%) 2 of 15 (13.3%)Ceiling: 15 of 15 (100.0%) 67 0 0 0
RFC 2347 TFTP Option Extension Supported 2 of 3 (66.7%)Ceiling: 2 of 3 (66.7%); excluded: Not applicable (classification can be revisited): 1 of 3 (33.3%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 3 0 0 0
RFC 2348 TFTP Blocksize Option No public row declared 3 of 5 (60.0%)Ceiling: 4 of 5 (80.0%); excluded: Not applicable (classification can be revisited): 1 of 5 (20.0%) no rowsCeiling: no rows 5 0 0 0
RFC 2349 TFTP Timeout Interval and Transfer Size Options No public row declared 0 of 4 (0.0%)Ceiling: 1 of 4 (25.0%); excluded: Not applicable (classification can be revisited): 3 of 4 (75.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 4 0 0 0
RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option Supported on Linux; FreeBSD needs a `setkey(8)` SAD entry 8 of 8 (100.0%)Ceiling: 8 of 8 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 8 0 0 0
RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE) Partial 25 of 37 (67.6%)Ceiling: 36 of 37 (97.3%); excluded: Met by a lower layer: 1 of 37 (2.7%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 37 4 0 0
RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing Partial 3 of 5 (60.0%)Ceiling: 5 of 5 (100.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 5 1 0 0
RFC 2661 Layer Two Tunneling Protocol "L2TP" Partial 81 of 94 (86.2%)Ceiling: 93 of 94 (98.9%); excluded: Met by a lower layer: 1 of 94 (1.1%) 2 of 8 (25.0%)Ceiling: 8 of 8 (100.0%) 94 9 0 0
RFC 2759 Microsoft PPP CHAP Extensions, Version 2 Supported 4 of 7 (57.1%)Ceiling: 7 of 7 (100.0%) 2 of 4 (50.0%)Ceiling: 4 of 4 (100.0%) 7 0 0 0
RFC 2782 A DNS RR for specifying the location of services (DNS SRV) No public row declared 0 of 7 (0.0%)Ceiling: 0 of 7 (0.0%); excluded: Not applicable (classification can be revisited): 7 of 7 (100.0%) 0 of 7 (0.0%)Ceiling: 7 of 7 (100.0%) 7 0 0 0
RFC 2865 Remote Authentication Dial In User Service (RADIUS) Supported for subscriber access 24 of 31 (77.4%)Ceiling: 31 of 31 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 31 0 0 0
RFC 2866 RADIUS Accounting Supported for subscriber access 8 of 15 (53.3%)Ceiling: 15 of 15 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 15 0 0 0
RFC 2869 RADIUS Extensions Supported for subscriber access 4 of 8 (50.0%)Ceiling: 8 of 8 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 8 0 0 0
RFC 2918 Route Refresh Capability for BGP-4 Supported 3 of 6 (50.0%)Ceiling: 6 of 6 (100.0%) 1 of 5 (20.0%)Ceiling: 5 of 5 (100.0%) 6 0 0 0
RFC 2966 Domain-wide Prefix Distribution with Two-Level IS-IS Experimental 3 of 6 (50.0%)Ceiling: 6 of 6 (100.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 6 0 0 0
RFC 3032 MPLS Label Stack Encoding Partial 1 of 18 (5.6%)Ceiling: 1 of 18 (5.6%); excluded: Not applicable (classification can be revisited): 17 of 18 (94.4%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 18 0 0 0
RFC 3101 The OSPF Not-So-Stubby Area (NSSA) Option Experimental 15 of 28 (53.6%)Ceiling: 27 of 28 (96.4%); excluded: Optional feature not offered (classification can be revisited): 1 of 28 (3.6%) 2 of 7 (28.6%)Ceiling: 7 of 7 (100.0%) 28 0 0 0
RFC 3162 RADIUS and IPv6 Partial 3 of 6 (50.0%)Ceiling: 6 of 6 (100.0%) 0 of 7 (0.0%)Ceiling: 7 of 7 (100.0%) 6 3 0 0
RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels Experimental 23 of 59 (39.0%)Ceiling: 57 of 59 (96.6%); excluded: Met by a lower layer: 2 of 59 (3.4%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 59 32 0 0
RFC 3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) Partial 17 of 31 (54.8%)Ceiling: 31 of 31 (100.0%) 2 of 19 (10.5%)Ceiling: 19 of 19 (100.0%) 31 14 0 0
RFC 3623 Graceful OSPF Restart Experimental 8 of 13 (61.5%)Ceiling: 11 of 13 (84.6%); excluded: Not applicable (classification can be revisited): 2 of 13 (15.4%) 0 of 13 (0.0%)Ceiling: 13 of 13 (100.0%) 13 2 0 0
RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2 Experimental 0 of 5 (0.0%)Ceiling: 1 of 5 (20.0%); excluded: Not applicable (classification can be revisited): 4 of 5 (80.0%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 5 0 0 0
RFC 3748 Extensible Authentication Protocol (EAP) Partial in IPsec 42 of 59 (71.2%)Ceiling: 53 of 59 (89.8%); excluded: Not applicable (classification can be revisited): 6 of 59 (10.2%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 59 0 0 0
RFC 3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control Supported no rowsCeiling: no rows 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 0 0 0 0
RFC 3768 Virtual Router Redundancy Protocol (VRRP) Experimental 26 of 41 (63.4%)Ceiling: 38 of 41 (92.7%); excluded: Not applicable (classification can be revisited): 3 of 41 (7.3%) 0 of 11 (0.0%)Ceiling: 11 of 11 (100.0%) 41 0 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 1 of 9 (11.1%)Ceiling: 2 of 9 (22.2%); excluded: Not applicable (classification can be revisited): 7 of 9 (77.8%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 9 0 0 0
RFC 3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) Partial 4 of 5 (80.0%)Ceiling: 5 of 5 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 5 1 0 0
RFC 3948 UDP Encapsulation of IPsec ESP Packets Partial 5 of 11 (45.5%)Ceiling: 10 of 11 (90.9%); excluded: Not applicable (classification can be revisited): 1 of 11 (9.1%) 2 of 5 (40.0%)Ceiling: 5 of 5 (100.0%) 11 0 0 0
RFC 3954 Cisco Systems NetFlow Services Export Version 9 Experimental 4 of 14 (28.6%)Ceiling: 5 of 14 (35.7%); excluded: Not applicable (classification can be revisited): 9 of 14 (64.3%) 0 of 12 (0.0%)Ceiling: 12 of 12 (100.0%) 14 1 0 0
RFC 4035 Protocol Modifications for the DNS Security Extensions Partial 4 of 108 (3.7%)Ceiling: 17 of 108 (15.7%); excluded: Not applicable (classification can be revisited): 91 of 108 (84.3%) 0 of 50 (0.0%)Ceiling: 50 of 50 (100.0%) 108 3 0 0
RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels Experimental 29 of 33 (87.9%)Ceiling: 33 of 33 (100.0%) 6 of 8 (75.0%)Ceiling: 8 of 8 (100.0%) 33 2 0 0
RFC 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) Partial 5 of 8 (62.5%)Ceiling: 5 of 8 (62.5%); excluded: Met by a lower layer: 3 of 8 (37.5%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 8 0 0 0
RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers No public row declared 1 of 23 (4.3%)Ceiling: 1 of 23 (4.3%); excluded: Not applicable (classification can be revisited): 22 of 23 (95.7%) 0 of 24 (0.0%)Ceiling: 24 of 24 (100.0%) 23 0 0 0
RFC 4271 A Border Gateway Protocol 4 (BGP-4) Partial 80 of 133 (60.2%)Ceiling: 126 of 133 (94.7%); excluded: Not applicable (classification can be revisited): 7 of 133 (5.3%) 3 of 34 (8.8%)Ceiling: 34 of 34 (100.0%) 133 12 0 0
RFC 4301 Security Architecture for the Internet Protocol Partial 50 of 100 (50.0%)Ceiling: 92 of 100 (92.0%); excluded: Optional feature not offered (classification can be revisited): 1 of 100 (1.0%); Met by a lower layer: 4 of 100 (4.0%); Not applicable (classification can be revisited): 3 of 100 (3.0%) 1 of 3 (33.3%)Ceiling: 3 of 3 (100.0%) 100 34 0 0
RFC 4302 IP Authentication Header Partial 8 of 32 (25.0%)Ceiling: 11 of 32 (34.4%); excluded: Optional feature not offered (classification can be revisited): 1 of 32 (3.1%); Met by a lower layer: 20 of 32 (62.5%) 0 of 10 (0.0%)Ceiling: 10 of 10 (100.0%) 32 2 0 0
RFC 4303 IP Encapsulating Security Payload (ESP) Partial 7 of 23 (30.4%)Ceiling: 9 of 23 (39.1%); excluded: Not applicable (classification can be revisited): 14 of 23 (60.9%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 23 1 0 0
RFC 4360 BGP Extended Communities Attribute Supported 2 of 5 (40.0%)Ceiling: 2 of 5 (40.0%); excluded: Not applicable (classification can be revisited): 3 of 5 (60.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 5 0 0 0
RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs) Partial 0 of 8 (0.0%)Ceiling: 0 of 8 (0.0%); excluded: Not applicable (classification can be revisited): 8 of 8 (100.0%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 8 0 0 0
RFC 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) Supported 1 of 4 (25.0%)Ceiling: 4 of 4 (100.0%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 4 0 0 0
RFC 4486 Subcodes for BGP Cease NOTIFICATION Message Supported 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 0 of 10 (0.0%)Ceiling: 10 of 10 (100.0%) 1 0 0 0
RFC 4552 Authentication/Confidentiality for OSPFv3 Partial 6 of 27 (22.2%)Ceiling: 20 of 27 (74.1%); excluded: Met by a lower layer: 6 of 27 (22.2%); Not applicable (classification can be revisited): 1 of 27 (3.7%) 0 of 11 (0.0%)Ceiling: 11 of 11 (100.0%) 27 5 0 0
RFC 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE) Partial 3 of 14 (21.4%)Ceiling: 14 of 14 (100.0%) 2 of 12 (16.7%)Ceiling: 12 of 12 (100.0%) 14 0 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 0 of 4 (0.0%)Ceiling: 0 of 4 (0.0%); excluded: Not applicable (classification can be revisited): 4 of 4 (100.0%) no rowsCeiling: no rows 4 0 0 0
RFC 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) Not supported 0 of 45 (0.0%)Ceiling: 1 of 45 (2.2%); excluded: Not applicable (classification can be revisited): 44 of 45 (97.8%) 1 of 20 (5.0%)Ceiling: 2 of 20 (10.0%); excluded: Not applicable (classification can be revisited): 18 of 20 (90.0%) 45 0 0 0
RFC 4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) Supported 1 of 5 (20.0%)Ceiling: 1 of 5 (20.0%); excluded: Not applicable (classification can be revisited): 4 of 5 (80.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 5 0 0 0
RFC 4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) Partial 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 6 6 0 0
RFC 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN Partial 4 of 18 (22.2%)Ceiling: 9 of 18 (50.0%); excluded: Not applicable (classification can be revisited): 9 of 18 (50.0%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 18 4 0 0
RFC 4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) Partial 2 of 6 (33.3%)Ceiling: 6 of 6 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 6 4 0 0
RFC 4724 Graceful Restart Mechanism for BGP Partial 14 of 26 (53.8%)Ceiling: 25 of 26 (96.2%); excluded: Not applicable (classification can be revisited): 1 of 26 (3.8%) 1 of 5 (20.0%)Ceiling: 5 of 5 (100.0%) 26 8 0 0
RFC 4760 Multiprotocol Extensions for BGP-4 Supported 5 of 6 (83.3%)Ceiling: 6 of 6 (100.0%) 1 of 11 (9.1%)Ceiling: 11 of 11 (100.0%) 6 0 0 0
RFC 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling Partial 0 of 18 (0.0%)Ceiling: 0 of 18 (0.0%); excluded: Not applicable (classification can be revisited): 18 of 18 (100.0%) 0 of 9 (0.0%)Ceiling: 9 of 9 (100.0%) 18 0 0 0
RFC 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP Partial 0 of 13 (0.0%)Ceiling: 6 of 13 (46.2%); excluded: Met by a lower layer: 7 of 13 (53.8%) 0 of 16 (0.0%)Ceiling: 16 of 16 (100.0%) 13 6 0 0
RFC 4861 Neighbor Discovery for IP version 6 (IPv6) Partial 30 of 138 (21.7%)Ceiling: 43 of 138 (31.2%); excluded: Met by a lower layer: 95 of 138 (68.8%) 0 of 79 (0.0%)Ceiling: 79 of 79 (100.0%) 138 13 0 0
RFC 5036 LDP Specification Experimental 29 of 91 (31.9%)Ceiling: 91 of 91 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 91 60 0 0
RFC 5072 IP Version 6 over PPP Partial 9 of 16 (56.2%)Ceiling: 15 of 16 (93.8%); excluded: Not applicable (classification can be revisited): 1 of 16 (6.2%) 0 of 12 (0.0%)Ceiling: 12 of 12 (100.0%) 16 3 0 0
RFC 5082 The Generalized TTL Security Mechanism (GTSM) Supported on Linux 4 of 4 (100.0%)Ceiling: 4 of 4 (100.0%) 1 of 6 (16.7%)Ceiling: 6 of 6 (100.0%) 4 0 0 0
RFC 5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Supported for subscriber access 26 of 30 (86.7%)Ceiling: 30 of 30 (100.0%) 1 of 1 (100.0%)Ceiling: 1 of 1 (100.0%) 30 0 0 0
RFC 5187 OSPFv3 Graceful Restart Experimental 4 of 4 (100.0%)Ceiling: 4 of 4 (100.0%) no rowsCeiling: no rows 4 0 0 0
RFC 5216 The EAP-TLS Authentication Protocol Partial 30 of 47 (63.8%)Ceiling: 45 of 47 (95.7%); excluded: Met by a lower layer: 2 of 47 (4.3%) 2 of 7 (28.6%)Ceiling: 7 of 7 (100.0%) 47 9 0 0
RFC 5250 The OSPF Opaque LSA Option Experimental 10 of 15 (66.7%)Ceiling: 15 of 15 (100.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 15 0 0 0
RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Partial 26 of 102 (25.5%)Ceiling: 49 of 102 (48.0%); excluded: Met by a lower layer: 53 of 102 (52.0%) 0 of 108 (0.0%)Ceiling: 108 of 108 (100.0%) 102 23 0 0
RFC 5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol Supported 19 of 19 (100.0%)Ceiling: 19 of 19 (100.0%) 0 of 11 (0.0%)Ceiling: 11 of 11 (100.0%) 19 0 0 0
RFC 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates Experimental 2 of 6 (33.3%)Ceiling: 5 of 6 (83.3%); excluded: Not applicable (classification can be revisited): 1 of 6 (16.7%) 0 of 24 (0.0%)Ceiling: 24 of 24 (100.0%) 6 2 0 0
RFC 5301 Dynamic Hostname Exchange Mechanism for IS-IS Supported 0 of 7 (0.0%)Ceiling: 7 of 7 (100.0%) 0 of 8 (0.0%)Ceiling: 8 of 8 (100.0%) 7 0 0 0
RFC 5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies Experimental 7 of 17 (41.2%)Ceiling: 15 of 17 (88.2%); excluded: Not applicable (classification can be revisited): 2 of 17 (11.8%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 17 5 0 0
RFC 5304 IS-IS Cryptographic Authentication Experimental 0 of 9 (0.0%)Ceiling: 8 of 9 (88.9%); excluded: Not applicable (classification can be revisited): 1 of 9 (11.1%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 9 0 0 0
RFC 5305 IS-IS Extensions for Traffic Engineering Experimental 8 of 14 (57.1%)Ceiling: 9 of 14 (64.3%); excluded: Not applicable (classification can be revisited): 5 of 14 (35.7%) 0 of 8 (0.0%)Ceiling: 8 of 8 (100.0%) 14 0 0 0
RFC 5308 Routing IPv6 with IS-IS Experimental 6 of 8 (75.0%)Ceiling: 8 of 8 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 8 0 0 0
RFC 5310 IS-IS Generic Cryptographic Authentication Experimental 6 of 9 (66.7%)Ceiling: 8 of 9 (88.9%); excluded: Not applicable (classification can be revisited): 1 of 9 (11.1%) 1 of 3 (33.3%)Ceiling: 3 of 3 (100.0%) 9 0 0 0
RFC 5340 OSPF for IPv6 Partial 6 of 23 (26.1%)Ceiling: 22 of 23 (95.7%); excluded: Not applicable (classification can be revisited): 1 of 23 (4.3%) 0 of 23 (0.0%)Ceiling: 23 of 23 (100.0%) 23 5 0 0
RFC 5382 NAT Behavioral Requirements for TCP Partial 0 of 11 (0.0%)Ceiling: 6 of 11 (54.5%); excluded: Met by a lower layer: 5 of 11 (45.5%) 0 of 11 (0.0%)Ceiling: 11 of 11 (100.0%) 11 6 0 0
RFC 5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering Experimental 5 of 14 (35.7%)Ceiling: 14 of 14 (100.0%) 0 of 18 (0.0%)Ceiling: 18 of 18 (100.0%) 14 5 0 0
RFC 5443 LDP IGP Synchronization Experimental 5 of 8 (62.5%)Ceiling: 6 of 8 (75.0%); excluded: Not applicable (classification can be revisited): 2 of 8 (25.0%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 8 1 0 0
RFC 5492 Capabilities Advertisement with BGP-4 Partial 2 of 9 (22.2%)Ceiling: 8 of 9 (88.9%); excluded: Not applicable (classification can be revisited): 1 of 9 (11.1%) 0 of 7 (0.0%)Ceiling: 7 of 7 (100.0%) 9 0 0 0
RFC 5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop Supported 3 of 6 (50.0%)Ceiling: 6 of 6 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 6 0 0 0
RFC 5561 LDP Capabilities Partial 1 of 17 (5.9%)Ceiling: 17 of 17 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 17 16 0 0
RFC 5575 Dissemination of Flow Specification Rules Partial 4 of 9 (44.4%)Ceiling: 9 of 9 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 9 1 0 0
RFC 5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) Partial no rowsCeiling: no rows 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 0 0 0 0
RFC 5701 IPv6 Address Specific BGP Extended Community Attribute Partial 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 4 1 0 0
RFC 5709 OSPFv2 HMAC-SHA Cryptographic Authentication Experimental 5 of 15 (33.3%)Ceiling: 15 of 15 (100.0%) 2 of 7 (28.6%)Ceiling: 7 of 7 (100.0%) 15 0 0 0
RFC 5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 Partial 43 of 59 (72.9%)Ceiling: 54 of 59 (91.5%); excluded: Optional feature not offered (classification can be revisited): 2 of 59 (3.4%); Met by a lower layer: 3 of 59 (5.1%) 0 of 26 (0.0%)Ceiling: 25 of 26 (96.2%); excluded: Optional feature not offered (classification can be revisited): 1 of 26 (3.8%) 59 4 0 0
RFC 5838 Support of Address Families in OSPFv3 Experimental 4 of 16 (25.0%)Ceiling: 14 of 16 (87.5%); excluded: Not applicable (classification can be revisited): 2 of 16 (12.5%) 0 of 11 (0.0%)Ceiling: 11 of 11 (100.0%) 16 8 0 0
RFC 5880 Bidirectional Forwarding Detection (BFD) Partial 72 of 111 (64.9%)Ceiling: 110 of 111 (99.1%); excluded: Not applicable (classification can be revisited): 1 of 111 (0.9%) 6 of 26 (23.1%)Ceiling: 26 of 26 (100.0%) 111 11 0 0
RFC 5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) Partial 13 of 23 (56.5%)Ceiling: 21 of 23 (91.3%); excluded: Not applicable (classification can be revisited): 2 of 23 (8.7%) 0 of 10 (0.0%)Ceiling: 10 of 10 (100.0%) 23 6 0 0
RFC 5882 Generic Application of Bidirectional Forwarding Detection (BFD) Partial 0 of 3 (0.0%)Ceiling: 1 of 3 (33.3%); excluded: Not applicable (classification can be revisited): 2 of 3 (66.7%) 5 of 29 (17.2%)Ceiling: 29 of 29 (100.0%) 3 0 0 0
RFC 5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths Partial 3 of 6 (50.0%)Ceiling: 6 of 6 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 6 0 0 0
RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification Partial 0 of 8 (0.0%)Ceiling: 8 of 8 (100.0%) no rowsCeiling: no rows 8 8 0 0
RFC 5998 An Extension for EAP-Only Authentication in IKEv2 Unsupported 1 of 6 (16.7%)Ceiling: 6 of 6 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 6 5 0 0
RFC 6138 LDP IGP Synchronization for Broadcast Networks No public row declared 2 of 2 (100.0%)Ceiling: 2 of 2 (100.0%) no rowsCeiling: no rows 2 0 0 0
RFC 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4 Supported 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 1 of 1 (100.0%)Ceiling: 1 of 1 (100.0%) 4 0 0 0
RFC 6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format Supported 6 of 13 (46.2%)Ceiling: 8 of 13 (61.5%); excluded: Not applicable (classification can be revisited): 5 of 13 (38.5%) 0 of 12 (0.0%)Ceiling: 12 of 12 (100.0%) 13 1 0 0
RFC 6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions No public row declared 0 of 4 (0.0%)Ceiling: 0 of 4 (0.0%); excluded: Not applicable (classification can be revisited): 4 of 4 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 4 0 0 0
RFC 6549 OSPFv2 Multi-Instance Extensions No public row declared 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 1 0 0 0
RFC 6608 Subcodes for BGP Finite State Machine Error Partial 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) no rowsCeiling: no rows 3 3 0 0
RFC 6793 BGP Support for Four-Octet Autonomous System (AS) Number Space Partial 20 of 30 (66.7%)Ceiling: 30 of 30 (100.0%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 30 1 0 0
RFC 6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol Partial 5 of 40 (12.5%)Ceiling: 12 of 40 (30.0%); excluded: Not applicable (classification can be revisited): 28 of 40 (70.0%) 0 of 28 (0.0%)Ceiling: 28 of 28 (100.0%) 40 4 0 0
RFC 6811 BGP Prefix Origin Validation Supported 1 of 5 (20.0%)Ceiling: 5 of 5 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 5 0 0 0
RFC 6996 Autonomous System (AS) Reservation for Private Use No public row declared 1 of 1 (100.0%)Ceiling: 1 of 1 (100.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 1 0 0 0
RFC 7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information Experimental 12 of 50 (24.0%)Ceiling: 27 of 50 (54.0%); excluded: Optional feature not offered (classification can be revisited): 10 of 50 (20.0%); Not applicable (classification can be revisited): 13 of 50 (26.0%) 0 of 7 (0.0%)Ceiling: 7 of 7 (100.0%) 50 9 0 0
RFC 7012 Information Model for IP Flow Information Export (IPFIX) No public row declared 1 of 6 (16.7%)Ceiling: 1 of 6 (16.7%); excluded: Not applicable (classification can be revisited): 5 of 6 (83.3%) no rowsCeiling: no rows 6 0 0 0
RFC 7084 Basic Requirements for IPv6 Customer Edge Routers Partial 14 of 41 (34.1%)Ceiling: 34 of 41 (82.9%); excluded: Met by a lower layer: 7 of 41 (17.1%) 0 of 25 (0.0%)Ceiling: 25 of 25 (100.0%) 41 20 0 0
RFC 7166 Supporting Authentication Trailer for OSPFv3 Unsupported 0 of 17 (0.0%)Ceiling: 17 of 17 (100.0%) 0 of 17 (0.0%)Ceiling: 17 of 17 (100.0%) 17 19 0 0
RFC 7296 Internet Key Exchange Protocol Version 2 (IKEv2) Partial 82 of 234 (35.0%)Ceiling: 234 of 234 (100.0%) 4 of 9 (44.4%)Ceiling: 9 of 9 (100.0%) 234 0 0 0
RFC 7311 The Accumulated IGP Metric Attribute for BGP Partial 13 of 22 (59.1%)Ceiling: 22 of 22 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 22 0 0 0
RFC 7313 Enhanced Route Refresh Capability for BGP-4 Supported 5 of 11 (45.5%)Ceiling: 10 of 11 (90.9%); excluded: Optional feature not offered (classification can be revisited): 1 of 11 (9.1%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 11 4 0 0
RFC 7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) No public row declared 2 of 4 (50.0%)Ceiling: 3 of 4 (75.0%); excluded: Not applicable (classification can be revisited): 1 of 4 (25.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 4 0 0 0
RFC 7432 BGP MPLS-Based Ethernet VPN Partial 11 of 103 (10.7%)Ceiling: 26 of 103 (25.2%); excluded: Optional feature not offered (classification can be revisited): 2 of 103 (1.9%); Not applicable (classification can be revisited): 75 of 103 (72.8%) 0 of 17 (0.0%)Ceiling: 17 of 17 (100.0%) 103 13 0 0
RFC 7440 TFTP Windowsize Option No public row declared 1 of 9 (11.1%)Ceiling: 1 of 9 (11.1%); excluded: Not applicable (classification can be revisited): 8 of 9 (88.9%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 9 0 0 0
RFC 7474 Security Extensions for OSPFv2 when Using Manual Key Management Experimental 7 of 12 (58.3%)Ceiling: 12 of 12 (100.0%) 1 of 4 (25.0%)Ceiling: 4 of 4 (100.0%) 12 1 0 0
RFC 7534 AS112 Nameserver Operations Supported 2 of 3 (66.7%)Ceiling: 3 of 3 (100.0%) 0 of 13 (0.0%)Ceiling: 13 of 13 (100.0%) 3 0 0 0
RFC 7535 AS112 Redirection Using DNAME Partial 0 of 1 (0.0%)Ceiling: 0 of 1 (0.0%); excluded: Not applicable (classification can be revisited): 1 of 1 (100.0%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 1 0 0 0
RFC 7606 Revised Error Handling for BGP UPDATE Messages Partial 28 of 53 (52.8%)Ceiling: 52 of 53 (98.1%); excluded: Not applicable (classification can be revisited): 1 of 53 (1.9%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 53 0 0 0
RFC 7607 Codification of AS 0 Processing Supported 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) no rowsCeiling: no rows 5 0 0 0
RFC 7611 BGP ACCEPT_OWN Community Attribute No public row declared 2 of 5 (40.0%)Ceiling: 3 of 5 (60.0%); excluded: Optional feature not offered (classification can be revisited): 1 of 5 (20.0%); Not applicable (classification can be revisited): 1 of 5 (20.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 5 0 0 0
RFC 7634 ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec Partial 1 of 2 (50.0%)Ceiling: 1 of 2 (50.0%); excluded: Met by a lower layer: 1 of 2 (50.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 2 0 0 0
RFC 7684 OSPFv2 Prefix/Link Attribute Advertisement Experimental 4 of 9 (44.4%)Ceiling: 6 of 9 (66.7%); excluded: Not applicable (classification can be revisited): 3 of 9 (33.3%) 0 of 11 (0.0%)Ceiling: 11 of 11 (100.0%) 9 0 0 0
RFC 7705 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute Supported 9 of 9 (100.0%)Ceiling: 9 of 9 (100.0%) 0 of 8 (0.0%)Ceiling: 8 of 8 (100.0%) 9 0 0 0
RFC 7752 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP Partial 8 of 26 (30.8%)Ceiling: 15 of 26 (57.7%); excluded: Not applicable (classification can be revisited): 11 of 26 (42.3%) 0 of 26 (0.0%)Ceiling: 26 of 26 (100.0%) 26 5 0 0
RFC 7770 Extensions to OSPF for Advertising Optional Router Capabilities Experimental 1 of 11 (9.1%)Ceiling: 4 of 11 (36.4%); excluded: Not applicable (classification can be revisited): 7 of 11 (63.6%) 1 of 14 (7.1%)Ceiling: 14 of 14 (100.0%) 11 0 0 0
RFC 7854 BGP Monitoring Protocol (BMP) Partial 25 of 39 (64.1%)Ceiling: 39 of 39 (100.0%) 3 of 9 (33.3%)Ceiling: 9 of 9 (100.0%) 39 0 0 0
RFC 7858 Specification for DNS over Transport Layer Security (TLS) Partial 3 of 19 (15.8%)Ceiling: 8 of 19 (42.1%); excluded: Not applicable (classification can be revisited): 11 of 19 (57.9%) 0 of 19 (0.0%)Ceiling: 19 of 19 (100.0%) 19 1 0 0
RFC 7871 Client Subnet in DNS Queries Partial 0 of 36 (0.0%)Ceiling: 7 of 36 (19.4%); excluded: Not applicable (classification can be revisited): 29 of 36 (80.6%) 0 of 52 (0.0%)Ceiling: 52 of 52 (100.0%) 36 5 0 0
RFC 7911 Advertisement of Multiple Paths in BGP Supported 9 of 9 (100.0%)Ceiling: 9 of 9 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 9 0 0 0
RFC 792 Internet Control Message Protocol No public row declared 3 of 10 (30.0%)Ceiling: 10 of 10 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 10 0 0 0
RFC 7947 Internet Exchange BGP Route Server Partial 1 of 2 (50.0%)Ceiling: 2 of 2 (100.0%) 2 of 5 (40.0%)Ceiling: 5 of 5 (100.0%) 2 0 0 0
RFC 7950 The YANG 1.1 Data Modeling Language Partial 37 of 91 (40.7%)Ceiling: 86 of 91 (94.5%); excluded: Not applicable (classification can be revisited): 5 of 91 (5.5%) no rowsCeiling: no rows 91 46 0 0
RFC 7999 BLACKHOLE Community Partial 3 of 4 (75.0%)Ceiling: 4 of 4 (100.0%) 3 of 12 (25.0%)Ceiling: 12 of 12 (100.0%) 4 0 0 0
RFC 8050 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions Partial 5 of 6 (83.3%)Ceiling: 6 of 6 (100.0%) no rowsCeiling: no rows 6 0 0 0
RFC 8092 BGP Large Communities Attribute Partial 6 of 7 (85.7%)Ceiling: 7 of 7 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 7 0 0 0
RFC 8097 BGP Prefix Origin Validation State Extended Community No public row declared 0 of 5 (0.0%)Ceiling: 0 of 5 (0.0%); excluded: Not applicable (classification can be revisited): 5 of 5 (100.0%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 5 0 0 0
RFC 8106 IPv6 Router Advertisement Options for DNS Configuration Partial 0 of 11 (0.0%)Ceiling: 11 of 11 (100.0%) 0 of 13 (0.0%)Ceiling: 13 of 13 (100.0%) 11 11 0 0
RFC 8203 BGP Administrative Shutdown Communication Supported 3 of 5 (60.0%)Ceiling: 5 of 5 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 5 0 0 0
RFC 8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 Partial 12 of 59 (20.3%)Ceiling: 34 of 59 (57.6%); excluded: Not applicable (classification can be revisited): 25 of 59 (42.4%) 6 of 27 (22.2%)Ceiling: 25 of 27 (92.6%); excluded: Not applicable (classification can be revisited): 2 of 27 (7.4%) 59 5 0 0
RFC 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies Unsupported 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 2 2 0 0
RFC 8221 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Partial 16 of 16 (100.0%)Ceiling: 16 of 16 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 16 0 0 0
RFC 8247 Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) Partial 16 of 20 (80.0%)Ceiling: 20 of 20 (100.0%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 20 4 0 0
RFC 8277 Using BGP to Bind MPLS Labels to Address Prefixes Partial 11 of 35 (31.4%)Ceiling: 20 of 35 (57.1%); excluded: Not applicable (classification can be revisited): 15 of 35 (42.9%) 1 of 7 (14.3%)Ceiling: 7 of 7 (100.0%) 35 9 0 0
RFC 8414 OAuth 2.0 Authorization Server Metadata Partial 9 of 31 (29.0%)Ceiling: 16 of 31 (51.6%); excluded: Optional feature not offered (classification can be revisited): 3 of 31 (9.7%); Not applicable (classification can be revisited): 12 of 31 (38.7%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 31 0 0 0
RFC 8484 DNS Queries over HTTPS (DoH) Partial 1 of 16 (6.2%)Ceiling: 10 of 16 (62.5%); excluded: Not applicable (classification can be revisited): 6 of 16 (37.5%) 0 of 11 (0.0%)Ceiling: 11 of 11 (100.0%) 16 1 0 0
RFC 8522 Looking Glass Command Set Unsupported 0 of 18 (0.0%)Ceiling: 18 of 18 (100.0%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 18 18 0 0
RFC 8571 BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions No public row declared no rowsCeiling: no rows no rowsCeiling: no rows 0 0 0 0
RFC 8654 Extended Message Support for BGP Partial 9 of 12 (75.0%)Ceiling: 10 of 12 (83.3%); excluded: Not applicable (classification can be revisited): 2 of 12 (16.7%) 1 of 4 (25.0%)Ceiling: 4 of 4 (100.0%) 12 0 0 0
RFC 8665 OSPF Extensions for Segment Routing Partial 13 of 51 (25.5%)Ceiling: 51 of 51 (100.0%) 1 of 35 (2.9%)Ceiling: 35 of 35 (100.0%) 51 14 0 0
RFC 8666 OSPFv3 Extensions for Segment Routing Partial 6 of 32 (18.8%)Ceiling: 28 of 32 (87.5%); excluded: Not applicable (classification can be revisited): 4 of 32 (12.5%) 0 of 26 (0.0%)Ceiling: 26 of 26 (100.0%) 32 2 0 0
RFC 8669 Segment Routing Prefix Segment Identifier Extensions for BGP Partial 13 of 24 (54.2%)Ceiling: 24 of 24 (100.0%) 3 of 21 (14.3%)Ceiling: 21 of 21 (100.0%) 24 7 0 0
RFC 8671 Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) Supported within BMP sender scope 2 of 10 (20.0%)Ceiling: 9 of 10 (90.0%); excluded: Optional feature not offered (classification can be revisited): 1 of 10 (10.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 10 0 0 0
RFC 8707 Resource Indicators for OAuth 2.0 No public row declared 0 of 2 (0.0%)Ceiling: 0 of 2 (0.0%); excluded: Optional feature not offered (classification can be revisited): 2 of 2 (100.0%) 0 of 5 (0.0%)Ceiling: 2 of 5 (40.0%); excluded: Optional feature not offered (classification can be revisited): 1 of 5 (20.0%); Not applicable (classification can be revisited): 2 of 5 (40.0%) 2 0 0 0
RFC 8893 Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export Unsupported 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 4 4 0 0
RFC 8907 The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol Partial 38 of 56 (67.9%)Ceiling: 48 of 56 (85.7%); excluded: Optional feature not offered (classification can be revisited): 6 of 56 (10.7%); Not applicable (classification can be revisited): 2 of 56 (3.6%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 56 0 0 0
RFC 8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop Supported 3 of 6 (50.0%)Ceiling: 6 of 6 (100.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) 6 0 0 0
RFC 8955 Dissemination of Flow Specification Rules Partial 13 of 29 (44.8%)Ceiling: 27 of 29 (93.1%); excluded: Not applicable (classification can be revisited): 2 of 29 (6.9%) 6 of 20 (30.0%)Ceiling: 20 of 20 (100.0%) 29 0 0 0
RFC 8956 Dissemination of Flow Specification Rules for IPv6 Partial 7 of 9 (77.8%)Ceiling: 9 of 9 (100.0%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 9 0 0 0
RFC 9003 Extended BGP Administrative Shutdown Communication Supported 1 of 4 (25.0%)Ceiling: 4 of 4 (100.0%) 0 of 7 (0.0%)Ceiling: 7 of 7 (100.0%) 4 0 0 0
RFC 9012 The BGP Tunnel Encapsulation Attribute Partial 25 of 76 (32.9%)Ceiling: 67 of 76 (88.2%); excluded: Not applicable (classification can be revisited): 9 of 76 (11.8%) 0 of 22 (0.0%)Ceiling: 22 of 22 (100.0%) 76 42 0 0
RFC 905 ISO Transport Protocol Specification (ISO DP 8073) No public row declared 8 of 11 (72.7%)Ceiling: 8 of 11 (72.7%); excluded: Not applicable (classification can be revisited): 3 of 11 (27.3%) no rowsCeiling: no rows 11 0 0 0
RFC 9069 Support for Local RIB in the BGP Monitoring Protocol (BMP) Supported 9 of 16 (56.2%)Ceiling: 16 of 16 (100.0%) no rowsCeiling: no rows 16 0 0 0
RFC 9072 Extended Optional Parameters Length for BGP OPEN Message Partial 5 of 9 (55.6%)Ceiling: 9 of 9 (100.0%) 1 of 3 (33.3%)Ceiling: 3 of 3 (100.0%) 9 4 0 0
RFC 9085 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing Partial 9 of 9 (100.0%)Ceiling: 9 of 9 (100.0%) 3 of 5 (60.0%)Ceiling: 5 of 5 (100.0%) 9 0 0 0
RFC 9086 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering Partial 7 of 11 (63.6%)Ceiling: 11 of 11 (100.0%) 0 of 9 (0.0%)Ceiling: 9 of 9 (100.0%) 11 3 0 0
RFC 9117 Revised Validation Procedure for BGP Flow Specifications Partial 2 of 2 (100.0%)Ceiling: 2 of 2 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 2 0 0 0
RFC 9136 IP Prefix Advertisement in Ethernet VPN (EVPN) Partial 3 of 14 (21.4%)Ceiling: 9 of 14 (64.3%); excluded: Not applicable (classification can be revisited): 5 of 14 (35.7%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 14 3 0 0
RFC 9234 Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages Supported 8 of 19 (42.1%)Ceiling: 16 of 19 (84.2%); excluded: Not applicable (classification can be revisited): 3 of 19 (15.8%) 1 of 5 (20.0%)Ceiling: 5 of 5 (100.0%) 19 0 0 0
RFC 9252 BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) Partial 14 of 25 (56.0%)Ceiling: 25 of 25 (100.0%) 0 of 5 (0.0%)Ceiling: 5 of 5 (100.0%) 25 3 0 0
RFC 9256 Segment Routing Policy Architecture Partial 0 of 22 (0.0%)Ceiling: 9 of 22 (40.9%); excluded: Not applicable (classification can be revisited): 13 of 22 (59.1%) 0 of 47 (0.0%)Ceiling: 47 of 47 (100.0%) 22 7 0 0
RFC 9494 Long-Lived Graceful Restart for BGP Partial 8 of 25 (32.0%)Ceiling: 23 of 25 (92.0%); excluded: Not applicable (classification can be revisited): 2 of 25 (8.0%) 1 of 11 (9.1%)Ceiling: 11 of 11 (100.0%) 25 5 0 0
RFC 9514 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) Partial 15 of 20 (75.0%)Ceiling: 20 of 20 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 20 3 0 0
RFC 9552 Distribution of Link-State and Traffic Engineering Information Using BGP Partial 43 of 59 (72.9%)Ceiling: 54 of 59 (91.5%); excluded: Not applicable (classification can be revisited): 5 of 59 (8.5%) 1 of 30 (3.3%)Ceiling: 30 of 30 (100.0%) 59 3 0 0
RFC 9568 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 Partial 27 of 66 (40.9%)Ceiling: 60 of 66 (90.9%); excluded: Not applicable (classification can be revisited): 6 of 66 (9.1%) 1 of 28 (3.6%)Ceiling: 28 of 28 (100.0%) 66 4 0 0
RFC 9687 Border Gateway Protocol 4 (BGP-4) Send Hold Timer Supported 3 of 13 (23.1%)Ceiling: 13 of 13 (100.0%) 0 of 7 (0.0%)Ceiling: 7 of 7 (100.0%) 13 0 0 0
RFC 9728 OAuth 2.0 Protected Resource Metadata Partial 9 of 26 (34.6%)Ceiling: 13 of 26 (50.0%); excluded: Optional feature not offered (classification can be revisited): 6 of 26 (23.1%); Not applicable (classification can be revisited): 7 of 26 (26.9%) 2 of 6 (33.3%)Ceiling: 6 of 6 (100.0%) 26 0 0 0
RFC 9774 Deprecation of AS_SET and AS_CONFED_SET in BGP Supported 2 of 2 (100.0%)Ceiling: 2 of 2 (100.0%) no rowsCeiling: no rows 2 0 0 0
RFC 9830 BGP Extensions for the Advertisement of Segment Routing (SR) Policies Partial 37 of 97 (38.1%)Ceiling: 85 of 97 (87.6%); excluded: Not applicable (classification can be revisited): 12 of 97 (12.4%) 0 of 41 (0.0%)Ceiling: 41 of 41 (100.0%) 97 12 0 0
RFC 9915 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Partial 83 of 126 (65.9%)Ceiling: 102 of 126 (81.0%); excluded: Optional feature not offered (classification can be revisited): 17 of 126 (13.5%); Met by a lower layer: 3 of 126 (2.4%); Not applicable (classification can be revisited): 4 of 126 (3.2%) no rowsCeiling: no rows 126 19 0 0
SFLOW-V5 sFlow: A Method for Monitoring Traffic in Switched and Routed Networks Experimental 22 of 32 (68.8%)Ceiling: 29 of 32 (90.6%); excluded: Optional feature not offered (classification can be revisited): 1 of 32 (3.1%); Met by a lower layer: 1 of 32 (3.1%); Not applicable (classification can be revisited): 1 of 32 (3.1%) 3 of 11 (27.3%)Ceiling: 11 of 11 (100.0%) 32 7 0 0

Summaries that are not enrolled

RFCs Ze keeps a summary for that the gate does not hold Ze to, each with the kind of reason and the reason itself.

  • backlog: the requirements have not been extracted from the document yet; this is work owed rather than a decision
  • blocked: something outside the summary stops the extraction, and it is named in the reason
  • foundation: the document defines, registers or describes, and obliges no implementer, so there is no implementation anywhere for a gate to hold
  • non-normative: the document imposes no MUST-level obligation on an implementation, so there is nothing to gate
  • out-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
  • third-party: a layer under or beside Ze performs the document and Ze holds no Go code for it, so the reason beside this kind names the component that does
RFCMandatoryOptionalDispositionReason
DRAFT-IETF-SIDROPS-8210BIS The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 not walked not walked backlog Existing RTR v2 ledger awaiting requirement reattribution from the historical RFC 9582 identifiers. The cached authority is revision 27; proof relocation and enrolment must preserve the source requirements and their tests.
RFC 1035 Domain Names - Implementation and Specification 12 of 27 (44.4%)Ceiling: 27 of 27 (100.0%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) 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 1570 PPP LCP Extensions 0 of 22 (0.0%)Ceiling: 22 of 22 (100.0%) 0 of 16 (0.0%)Ceiling: 16 of 16 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the lns profile. The extraction is COMPLETE: the source text is at rfc/full/rfc1570.txt, every capitalised MUST-level sentence is a row of this summary or an exclusion in rfc/extraction/rfc1570.json (walked 2026-10-26), and none is gated. Ze's PPP implements none of the LCP codes or options this document adds (internal/component/l2tp/ppp/lcp_options.go carries options 1, 2, 3, 5, 7 and 8 only), so an Identification or Time-Remaining packet is answered as an unknown code under RFC 1661.
RFC 2003 IP Encapsulation within IP 0 of 13 (0.0%)Ceiling: 0 of 13 (0.0%); excluded: Not applicable (classification can be revisited): 13 of 13 (100.0%) 0 of 24 (0.0%)Ceiling: 24 of 24 (100.0%) third-party The Linux ipip module builds and parses every outer header. Ze only builds the netlink link descriptor, internal/plugins/iface/netlink/tunnel_linux.go::buildIptun.
RFC 2473 Generic Packet Tunneling in IPv6 Specification 1 of 11 (9.1%)Ceiling: 1 of 11 (9.1%); excluded: Not applicable (classification can be revisited): 10 of 11 (90.9%) 0 of 10 (0.0%)Ceiling: 10 of 10 (100.0%) third-party The Linux ip6_tunnel module builds the outer IPv6 header and handles the Encapsulation Limit option. Ze only builds the netlink link descriptor, internal/plugins/iface/netlink/tunnel_linux.go::buildIp6tnl.
RFC 2784 Generic Routing Encapsulation (GRE) 0 of 11 (0.0%)Ceiling: 0 of 11 (0.0%); excluded: Not applicable (classification can be revisited): 11 of 11 (100.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) third-party The Linux ip_gre module builds and parses every GRE header. Ze only builds the netlink link descriptor, internal/plugins/iface/netlink/tunnel_linux.go::buildGretun.
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) 0 of 16 (0.0%)Ceiling: 16 of 16 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the lns profile. The extraction is COMPLETE: the source text is at rfc/full/rfc2867.txt, every capitalised MUST-level sentence is a row of this summary or an exclusion in rfc/extraction/rfc2867.json (walked 2026-10-26), and none is gated. Ze's accounting records carry no tunnel attributes and no tunnel Acct-Status-Type values (internal/component/l2tp/plugins/authradius/acct.go buildAcctPacket).
RFC 2868 RADIUS Attributes for Tunnel Protocol Support 0 of 18 (0.0%)Ceiling: 18 of 18 (100.0%) 0 of 43 (0.0%)Ceiling: 43 of 43 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the lns profile. The extraction is COMPLETE: the source text is at rfc/full/rfc2868.txt, every capitalised MUST-level sentence is a row of this summary or an exclusion in rfc/extraction/rfc2868.json (walked 2026-10-26), and none is gated. Ze's radius dictionary holds none of the tunnel attributes (types 64 to 67, 69, 81, 82, 83, 90, 91; internal/component/radius/dict.go), and the LNS reads none from an Access-Accept.
RFC 2890 Key and Sequence Number Extensions to GRE 0 of 3 (0.0%)Ceiling: 0 of 3 (0.0%); excluded: Not applicable (classification can be revisited): 3 of 3 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) third-party The Linux ip_gre module encodes and checks the Key and Sequence fields. Ze only sets IKey and OKey on the netlink descriptor, internal/plugins/iface/netlink/tunnel_linux.go::buildGretun.
RFC 3022 Traditional IP Network Address Translator (Traditional NAT) no rowsCeiling: no rows no rowsCeiling: no rows non-normative Traditional IP Network Address Translator, published with IETF category Informational. The text carries no RFC 2119 key-words section and a capitalised MUST / MUST NOT / SHALL / SHALL NOT / REQUIRED / SHOULD / MAY scan over rfc/full/rfc3022.txt finds zero keywords. Its lowercase "must" sentences describe how the Basic NAT and NAPT operations it defines rewrite a packet; the normative NAT behavioral requirements are stated by RFC 4787 (UDP) and RFC 5382 (TCP), which carry their own summaries.
RFC 3031 Multiprotocol Label Switching Architecture 2 of 10 (20.0%)Ceiling: 6 of 10 (60.0%); excluded: Not applicable (classification can be revisited): 4 of 10 (40.0%) 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) third-party The Linux AF_MPLS forwarding path performs label lookup, swap and TTL handling. Ze only installs the swap route, internal/plugins/fib/kernel/mplsentry_linux.go::addMPLSSwap.
RFC 3145 L2TP Disconnect Cause Information 0 of 8 (0.0%)Ceiling: 8 of 8 (100.0%) 0 of 10 (0.0%)Ceiling: 10 of 10 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the lns profile. The extraction is COMPLETE: the source text is at rfc/full/rfc3145.txt, every capitalised MUST-level sentence is a row of this summary or an exclusion in rfc/extraction/rfc3145.json (walked 2026-10-26), and none is gated. Ze's L2TP stack defines no AVP 46 (internal/component/l2tp/avp.go) and sends none in a Call-Disconnect-Notify.
RFC 3882 Configuring BGP to Block Denial-of-Service Attacks no rowsCeiling: no rows no rowsCeiling: no rows non-normative Configuring BGP to Block Denial-of-Service Attacks, IETF category Informational. A capitalised MUST / MUST NOT / SHALL / SHALL NOT / REQUIRED / SHOULD / MAY scan over rfc/full/rfc3882.txt hits zero keywords, and the document invokes neither RFC 2119 nor BCP 14 anywhere, so it declares no key-words machinery for a reader to read its prose by. It describes an operator configuration recipe: per-border-router BGP communities that rewrite the next hop of an attacked prefix to a null or sinkhole tunnel interface. The four lower-case modal sentences the prose inventory finds are steps of that recipe ("R1 and R2 must be configured with the following", "The advertisement must contain the community value"), a description ("It might also be required"), and copyright boilerplate. The summary captures no requirement. The walk is recorded in rfc/extraction/rfc3882.json at register prose, all 4 sites excluded as not-a-requirement.
RFC 4033 DNS Security Introduction and Requirements no rowsCeiling: no rows no rowsCeiling: no rows non-normative DNS Security Introduction and Requirements, the introduction to the DNSSEC document set. The text carries no RFC 2119 key-words section, and a capitalised MUST / MUST NOT / SHALL / SHALL NOT / REQUIRED / SHOULD / MAY scan over rfc/full/rfc4033.txt finds zero keywords. Its lowercase "must" sentences introduce obligations that RFC 4034 (the resource records) and RFC 4035 (the protocol modifications) state with RFC 2119 keywords; both carry their own summaries. Every such sentence is classified in rfc/extraction/rfc4033.json.
RFC 4034 Resource Records for the DNS Security Extensions 0 of 59 (0.0%)Ceiling: 59 of 59 (100.0%) no rowsCeiling: no rows out-of-scope Decision taken 2026-10-26: the owner ruled that DNSSEC is not urgent and lists RFC 4033 and RFC 4034 as optional only, never required, for the fttx-edge use case (spec-rfc-profile-declared-membership), and moved DNSSEC validation to post-release the same day (commit 5ff4834b67). The extraction is done: every MUST-level sentence of the text is a row below and is mapped in rfc/extraction/rfc4034.json. The declined feature is DNSSEC record handling itself: ze signs no zone, holds and serves no DNSKEY, RRSIG, NSEC or DS record of its own, and validates no signature. Its resolver is a security-aware non-validating stub whose obligations are gated in rfc/short/rfc4035.md.
RFC 4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol 0 of 2 (0.0%)Ceiling: 2 of 2 (100.0%) no rowsCeiling: no rows out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the vpn-concentrator profile. The extraction is COMPLETE: the source text is at rfc/full/rfc4739.txt and the extraction sign-off is rfc/extraction/rfc4739.json. Ze implements none of it, and each MUST-level row keeps its `{gap}` note naming the absent producer: both MUST-level requirements (the Protocol ID and SPI Size of the two notifications) are classified `{gap}`, because Ze's IKE engine implements neither MULTIPLE_AUTH_SUPPORTED (16404) nor ANOTHER_AUTH_FOLLOWS (16405). `internal/component/ike/wire/payload_notify.go` declares no such Notify Message Type and no engine path sends or reads one.
RFC 4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) no rowsCeiling: no rows out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the vpn-endpoint and vpn-concentrator profiles. The extraction is COMPLETE: the source text is at rfc/full/rfc4754.txt and the extraction sign-off is rfc/extraction/rfc4754.json. Ze implements none of it, and each MUST-level row keeps its `{gap}` note naming the absent producer: the single MUST-level requirement (the Section 7 r-and-s signature encoding) is classified `{gap}`, because Ze's IKE engine does not implement IKEv2 authentication methods 9, 10 or 11. `internal/component/ike/engine/auth.go::verifyRemoteAuth` accepts methods 1, 2 and 14 only and refuses every other method.
RFC 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling not walked not walked 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 4818 RADIUS Delegated-IPv6-Prefix Attribute 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the lns profile. The extraction is COMPLETE: the source text is at rfc/full/rfc4818.txt, every capitalised MUST-level sentence is a row of this summary or an exclusion in rfc/extraction/rfc4818.json (walked 2026-10-26), and none is gated. Ze reads no Delegated-IPv6-Prefix from an Access-Accept and writes none (internal/component/l2tp/plugins/authradius/extract.go extractAuthMetadata, handler.go buildAccessRequestAttrs, acct.go buildAcctPacket).
RFC 4862 IPv6 Stateless Address Autoconfiguration 0 of 16 (0.0%)Ceiling: 0 of 16 (0.0%); excluded: Not applicable (classification can be revisited): 16 of 16 (100.0%) 0 of 14 (0.0%)Ceiling: 14 of 14 (100.0%) third-party Linux addrconf performs stateless address autoconfiguration. Ze sets the sysctls at internal/component/iface/config_sysctl.go and reads the resulting addresses over netlink.
RFC 5065 Autonomous System Confederations for BGP not walked not walked 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) not walked not walked 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 5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) 0 of 26 (0.0%)Ceiling: 26 of 26 (100.0%) 0 of 9 (0.0%)Ceiling: 9 of 9 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the vpn-concentrator profile. The extraction is COMPLETE: the source text is at rfc/full/rfc5685.txt and the extraction sign-off is rfc/extraction/rfc5685.json. Ze implements none of it, and each MUST-level row keeps its `{gap}` note naming the absent producer: all 26 MUST-level requirements are classified, and all 26 are `{gap}`, because Ze's IKE engine implements neither the gateway nor the client side of redirect. `internal/component/ike/wire/payload_notify.go` declares none of REDIRECT_SUPPORTED (16406), REDIRECT (16407) or REDIRECTED_FROM (16408). Three sites are excluded in the extraction sign-off: two bind a Mobile IPv6 mobile node, which Ze does not implement, and one binds the author of a future specification.
RFC 5925 The TCP Authentication Option not walked not walked 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 6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap 0 of 8 (0.0%)Ceiling: 0 of 8 (0.0%); excluded: Not applicable (classification can be revisited): 8 of 8 (100.0%) 0 of 12 (0.0%)Ceiling: 12 of 12 (100.0%) foundation An informational roadmap over the IPsec and IKE document set. It defines no behaviour of its own.
RFC 6482 A Profile for Route Origin Authorizations (ROAs) 0 of 9 (0.0%)Ceiling: 0 of 9 (0.0%); excluded: Not applicable (classification can be revisited): 9 of 9 (100.0%) 0 of 1 (0.0%)Ceiling: 1 of 1 (100.0%) third-party The RPKI cache validates the CMS-signed ROA object. Ze consumes an already-validated payload over the RTR protocol, internal/component/bgp/plugins/rpki/rtr_pdu.go.
RFC 6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs not walked not walked 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 6911 RADIUS Attributes for IPv6 Access Networks 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) 0 of 9 (0.0%)Ceiling: 9 of 9 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the lns profile. The extraction is COMPLETE: the source text is at rfc/full/rfc6911.txt, every capitalised MUST-level sentence is a row of this summary or an exclusion in rfc/extraction/rfc6911.json (walked 2026-10-26), and none is gated. Ze reads none of the five attributes (types 168 to 172) from an Access-Accept and writes none (internal/component/l2tp/plugins/authradius/extract.go extractAuthMetadata).
RFC 6987 OSPF Stub Router Advertisement not walked not walked 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 7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation 0 of 25 (0.0%)Ceiling: 25 of 25 (100.0%) 0 of 15 (0.0%)Ceiling: 15 of 15 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the vpn-endpoint and vpn-concentrator profiles. The extraction is COMPLETE: the source text is at rfc/full/rfc7383.txt and this summary declares all 25 MUST-level requirements its sites state. Ze implements none of it: internal/component/ike/wire/payload_notify.go names IKEV2_FRAGMENTATION_SUPPORTED (16430) for display only, ze never sends it, and no Encrypted Fragment payload (53) is built or reassembled.
RFC 7454 BGP Operations and Security no rowsCeiling: no rows 0 of 64 (0.0%)Ceiling: 64 of 64 (100.0%) 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 not walked not walked 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.deriveKeys -- 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: exportEAPTLSKeys 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 7948 Internet Exchange BGP Route Server Operations no rowsCeiling: no rows 0 of 11 (0.0%)Ceiling: 11 of 11 (100.0%) non-normative Internet Exchange BGP Route Server Operations, IETF category Informational. A capitalised MUST / MUST NOT / SHALL / SHALL NOT / REQUIRED scan over rfc/full/rfc7948.txt hits zero keywords outside the Section 1.1 key-words paragraph. The capitalised keywords it does use are RECOMMENDED (five times, Sections 4.3, 4.4 and 4.5) and SHOULD (six times, Sections 4.6.1, 4.6.3, 4.8, 4.9 and 5), so the text states operational guidance at advisory level only. The lower-case "must" sentences the prose inventory finds describe consequences (the Decision Process "must be applied" to every Loc-RIB, routes "must be transmitted individually") or the operator's dependence on client data, and none binds an implementation. The summary captures 11 advisory requirements and gates none. The walk is recorded in rfc/extraction/rfc7948.json at register prose, all 8 sites excluded as not-a-requirement.
RFC 8031 Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement 0 of 3 (0.0%)Ceiling: 3 of 3 (100.0%) no rowsCeiling: no rows out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the vpn-endpoint and vpn-concentrator profiles. The extraction is COMPLETE: the source text is at rfc/full/rfc8031.txt and the extraction sign-off is rfc/extraction/rfc8031.json. Ze implements none of it, and each MUST-level row keeps its `{gap}` note naming the absent producer: all 3 MUST-level requirements are classified, and all 3 are `{gap}`, because Ze's IKE engine implements neither Diffie-Hellman group 31 nor group 32. `internal/component/ike/crypto/dh.go::NewDHExchange` builds MODP group 14 and ECP groups 19 and 20 only, and answers `ErrUnsupportedGroup` for every other group number.
RFC 8195 Use of BGP Large Communities not walked not walked 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 not walked not walked blocked Graceful BGP Session Shutdown. The text is at rfc/full/rfc8326.txt (fetched 2026-09-26); enrolment waits on its extraction walk.
RFC 8362 OSPFv3 Link State Advertisement (LSA) Extensibility not walked not walked 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. RFC8362-2-1 was the most serious until a9d0b54387 (2026-09-20) set the U-bit on the Extended LS type constants (internal/plugins/ospf/v3/types/lsa.go, 0xA021 E-Router-LSA), as Section 2 requires; TestRFC8362ExtendedLSAsSetUBitOnTheWire reads it on the wire for all three Extended LSA types Ze originates (E-Router, E-Intra-Area-Prefix and, from 2026-10-21, E-Inter-Area-Prefix).
RFC 8538 Notification Message Support for BGP Graceful Restart not walked not walked 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 not walked not walked blocked YANG Data Model for the OSPF Protocol. The text is at rfc/full/rfc9129.txt (fetched 2026-09-26); enrolment waits on its extraction walk.
RFC 9190 EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 42 of 53 (79.2%)Ceiling: 48 of 53 (90.6%); excluded: Optional feature not offered (classification can be revisited): 5 of 53 (9.4%) 2 of 43 (4.7%)Ceiling: 43 of 43 (100.0%) 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: exportEAPTLSKeys (internal/core/eap/eap_tls.go) selects the exporter label EXPORTER_EAP_TLS_Key_Material and the EAP Type octet as context whenever the negotiated version is TLS 1.3, asks for the 128-octet length on every version, and cuts the result into MSK = Key_Material(0, 63) and EMSK = Key_Material(64, 127), 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 9319 The Use of maxLength in the Resource Public Key Infrastructure (RPKI) 0 of 4 (0.0%)Ceiling: 0 of 4 (0.0%); excluded: Not applicable (classification can be revisited): 4 of 4 (100.0%) 0 of 7 (0.0%)Ceiling: 7 of 7 (100.0%) foundation A Best Current Practice addressed to operators and ROA issuers rather than to a router.
RFC 9329 TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets 0 of 30 (0.0%)Ceiling: 30 of 30 (100.0%) 0 of 44 (0.0%)Ceiling: 44 of 44 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the vpn-concentrator profile. The extraction is COMPLETE: the source text is at rfc/full/rfc9329.txt and the extraction sign-off is rfc/extraction/rfc9329.json. Ze implements none of it, and each MUST-level row keeps its `{gap}` note naming the absent producer: all 30 MUST-level requirements are classified, and all 30 are `{gap}`, because Ze carries IKE and ESP over UDP ports 500 and 4500 and directly over IP only. `internal/component/ike/transport/udp.go::newTransport` opens a UDP socket, and nothing under `internal/component/ike/` listens on or dials TCP, frames a Length-prefixed stream or sends the IKETCP stream prefix.
RFC 9370 Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) 0 of 23 (0.0%)Ceiling: 23 of 23 (100.0%) 0 of 4 (0.0%)Ceiling: 4 of 4 (100.0%) out-of-scope OUT OF SCOPE as a document by owner decision, 2026-10-26: the owner rule committed in 1e7a9dbc34 (ai/META-DECISIONS.md, Goal and scope) counts an RFC a profile lists as optional only once Thomas brings it into scope, and this summary's `Optional use cases` row lists this RFC in the optional tier of the vpn-endpoint and vpn-concentrator profiles. The extraction is COMPLETE: the source text is at rfc/full/rfc9370.txt and the extraction sign-off is rfc/extraction/rfc9370.json. Ze implements none of it, and each MUST-level row keeps its `{gap}` note naming the absent producer: all 23 MUST-level requirements are classified, and all 23 are `{gap}`, because Ze's IKE engine implements neither the IKE_INTERMEDIATE exchange (RFC 9242) nor IKE_FOLLOWUP_KE, nor the ADDKE Transform Types 6 to 12. `internal/component/ike/wire/header.go` declares exchange types 34 to 37 only, and `internal/component/ike/wire/payload_notify.go` declares neither ADDITIONAL_KEY_EXCHANGE (16441) nor STATE_NOT_FOUND (47). One Appendix C site states the rationale for a discarded alternative design and is excluded in the extraction sign-off.
RFC 9384 A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD) no rowsCeiling: no rows 1 of 3 (33.3%)Ceiling: 3 of 3 (100.0%) 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.
RFC 9582 A Profile for Route Origin Authorizations (ROAs) 0 of 16 (0.0%)Ceiling: 16 of 16 (100.0%) 0 of 6 (0.0%)Ceiling: 6 of 6 (100.0%) third-party The configured relying-party cache, such as Routinator or rpki-client, validates the CMS and X.509 ROA profile. Ze's RTR client consumes the resulting validated prefix payload through `internal/component/bgp/plugins/rpki/rtr_pdu.go::parsePrefixPDU`.