Supported

RFC 5492 - Capabilities Advertisement with BGP-4

Every requirement this repository extracted from RFC 5492, the tests bound to it, and what a reader has verified about them. This summary is enrolled and gated by ./le rfc check.

Overview

Positive

what Ze has

Tested both ways87.5%7 of 8 binding obligations

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

One polarity plus reason12.5%1 of 8 binding obligations

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 8 binding obligations

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

No test at all0.0%0 of 8 binding obligations

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

Proven by a recorded break0.0%0 of 17 tagged units

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

Gated MUSTs9of 16 this summary declares

MUST-level requirements the gate HOLDS. A population, not a result: the shares beside it are what says how Ze stands

Out of scope1of 9 gated MUSTs

a {not-applicable} annotation says the obligation does not bind Ze. Scope, not coverage: it is in no share below

The 4 shares marked as a part above are the whole of the 8 obligations that bind Ze: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

How to read the colors

A color names what the measure MEANS, not how well Ze scores on it. Green is a good outcome at any value, red is a bad one, and neither a population nor a scope count is an outcome, so both take no color. The number under the label is what says how far Ze has got.

Card	Tone here	Why that color
Gated MUSTs	neutral	no color: a population is a scale, and a larger one is neither good news nor bad. It is the accounting total
Out of scope	neutral	no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim
Tested both ways	ok	green at every value: a test pair is the outcome this gate exists to produce, and the share under the label is what says how far Ze has got
One polarity plus reason	ok	green at every value: where no counter-case exists, one polarity IS the complete answer, and a recorded reason is what the gate demands beside it
One polarity, unexcused	ok	green at zero, RED above it: half a proof with no reason for the other half
No test at all	ok	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
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
Audit verdicts	warn	RED on the first weak, wrong or unimplemented verdict, amber while a verdict is no longer current or a gated MUST is unjudged, green when every one is judged sound and current

At a glance

Field	Value
Public status	Supported
Enrolment	Enrolled
Requirements	16
Gated MUST-level	9
Obligations that bind Ze	8
Not applicable, so out of scope	1
Declared gaps	0
Gated with no test	0
Nightly-only evidence	0
Test tags	17
Tagged units	17
Recorded audit verdicts	0
Discrimination records	0
Summary	`rfc/short/rfc5492.md`
Requirement shard	`rfc/requirements/rfc5492.md`
RFC text	`rfc/full/rfc5492.txt`

Enrolment

Enrolled: BGP Capabilities Advertisement: nine MUST-level requirements. Eight are met with test tags: 3-1 (Unsupported-Capability NOTIFICATION carries the offending capabilities), 5-1 (each capability encoded code+length+value as in OPEN), 4-2 (every Type-2 Optional Parameter processed), 3-2 (unknown capability preserved without error), and the MUST NOTs 3-3/3-4/5-2 (a not-understood capability is not rejected and triggers no NOTIFICATION) carry positive+negative tags in internal/core/bgp/capability and internal/component/bgp/reactor. 4-1 (accept multiple identical capability instances) is {single-polarity: positive} bound to a new parser test (capability.go:177 appends every TLV with no reject path). 4-3 is {not-applicable}: it obliges the author of a capability-defining specification to describe its error handling, not a runtime behavior ze implements.

What the public ledger says

Status: Supported

What the ledger says is covered:

Capability TLV parser, encoder, unknown-capability ignore behavior, negotiated session view.

What the ledger says remains:

No tracked gap in current source anchors.

Coverage

Bucket	Count	What it counts
Positive and negative tests	7	one part of the gated population
Annotated instead of tested	2	one part of the gated population
One polarity only	0	one part of the gated population
No test and no annotation	0	one part of the gated population
Evidence that runs nightly only	0	an overlay: each of these is also counted by the part it falls in
Gated MUST-level requirements	9	every gated MUST falls in exactly one bucket above

Positive and negative tests (7): RFC5492-3-1, RFC5492-5-1, RFC5492-4-2, RFC5492-3-2, RFC5492-3-3, RFC5492-3-4, RFC5492-5-2

Annotated instead of tested (2): RFC5492-4-1, RFC5492-4-3

Requirements

Requirement	Level	Section	Tests
`RFC5492-3-1`	When sending Unsupported Capability NOTIFICATION, the message MUST contain the capability or capabilities that cause the speaker to send the message (§3)
	MUST	3 - Overview of Operations	positive`unit/verifyTestBuildUnsupportedCapabilityData` positive`unit/verifyTestOpenRejectsMalformedKnownCapability` negative`unit/verifyTestSessionAcceptsRequiredCapability`
`RFC5492-5-1`	The Data field in the NOTIFICATION message MUST list the set of capabilities that causes the speaker to send the message, each encoded as in an OPEN message (§5)
	MUST	5 - Extensions to Error Handling	positive`unit/verifyTestBuildUnsupportedCapabilityDataCodes` positive`unit/verifyTestBuildUnsupportedCapabilityDataCodes_MultipleCodes` negative`unit/verifyTestBuildUnsupportedCapabilityDataCodes_Empty`
`RFC5492-4-1`	A BGP speaker MUST be prepared to accept multiple instances of a capability with the same Code, Length, and Value (§4)
	MUST	4 - Capabilities Optional Parameter (Parameter Type 2)	positive`unit/verifyTestParseAcceptsMultipleIdenticalCapabilityInstances` negative`no test`no negative test {single-polarity}: ze's capability parser appends every capability TLV without dedup or reject (internal/core/bgp/capability/capability.go:177), so multiple identical instances are all accepted; there is no reject path, so no negative case exists
`RFC5492-4-2`	A BGP speaker MUST be prepared to receive an OPEN message that contains multiple Capabilities Optional Parameters (§4)
	MUST	4 - Capabilities Optional Parameter (Parameter Type 2)	positive`unit/verifyTestParseFromOptionalParamsMultipleCapabilitiesParameters` negative`unit/verifyTestOptionalParamRejectsTruncatedCapabilityTLV`
`RFC5492-3-2`	A BGP speaker MUST ignore unrecognized capability codes (§3)
	MUST	3 - Overview of Operations	positive`unit/verifyTestParseUnknownCapability` negative`unit/verifyTestParseRejectsMalformedKnownCapabilityLength`
`RFC5492-4-3`	Processing of multiple instances of the same Capability Code with different values MUST be described in the document introducing the new capability (§4)
	MUST	4 - Capabilities Optional Parameter (Parameter Type 2)	positive`no test`no positive test negative`no test`no negative test {not-applicable}: this obligation binds the author of a specification that introduces a new capability to describe its multiple-instance error handling; it is not a runtime behavior ze implements
`RFC5492-3-3`	The BGP session MUST NOT be terminated in response to reception of a capability that is not supported by the local speaker (§3)
	MUST NOT	3 - Overview of Operations	positive`unit/verifyTestOptionalParamPreservesUnknownCapability` negative`unit/verifyTestOpenRejectsMalformedKnownCapability`
`RFC5492-3-4`	The Unsupported Capability NOTIFICATION message MUST NOT be generated in response to an unrecognized capability (§3, §5)
	MUST NOT	3 - Overview of Operations	positive`unit/verifyTestOptionalParamPreservesUnknownCapability` negative`unit/verifyTestOpenRejectsMalformedKnownCapability`
`RFC5492-5-2`	Unsupported Capability NOTIFICATION MUST NOT be used when a BGP speaker receives a capability it does not understand; such capabilities MUST be ignored (§5)
	MUST NOT	5 - Extensions to Error Handling	positive`unit/verifyTestOptionalParamPreservesUnknownCapability` negative`unit/verifyTestOpenRejectsMalformedKnownCapability`
`RFC5492-3-5`	On receiving Unsupported Optional Parameter NOTIFICATION, speaker SHOULD attempt to re-establish without Capabilities Optional Parameter (§3)
	SHOULD	3 - Overview of Operations	positive`no test`no positive test negative`no test`no negative test
`RFC5492-4-4`	A BGP speaker SHOULD NOT include more than one instance of a capability with the same Code, Length, and Value (§4)
	SHOULD NOT	4 - Capabilities Optional Parameter (Parameter Type 2)	positive`no test`no positive test negative`no test`no negative test
`RFC5492-4-5`	The Capabilities Optional Parameter SHOULD only be included in the OPEN message once (§4)
	SHOULD	4 - Capabilities Optional Parameter (Parameter Type 2)	positive`no test`no positive test negative`no test`no negative test
`RFC5492-4-6`	All capabilities SHOULD be listed as TLVs within a single Capabilities Optional Parameter (§4)
	SHOULD	4 - Capabilities Optional Parameter (Parameter Type 2)	positive`no test`no positive test negative`no test`no negative test
`RFC5492-3-6`	Peering terminated due to Unsupported Capability SHOULD NOT be re-established automatically (§3)
	SHOULD NOT	3 - Overview of Operations	positive`no test`no positive test negative`no test`no negative test
`RFC5492-3-7`	A BGP speaker MAY send a NOTIFICATION and terminate peering when peer doesn't support a required capability (§3)
	MAY	3 - Overview of Operations	positive`no test`no positive test negative`no test`no negative test
`RFC5492-4-7`	A BGP speaker MAY include more than one instance of a capability with non-zero Length but different Value (§4)
	MAY	4 - Capabilities Optional Parameter (Parameter Type 2)	positive`no test`no positive test negative`no test`no negative test

Gaps and untested MUSTs

Requirement	State	Reason
`RFC5492-4-3` Processing of multiple instances of the same Capability Code with different values MUST be described in the document introducing the new capability (§4)	no test	no test carries this requirement id; annotated {not-applicable}: this obligation binds the author of a specification that introduces a new capability to describe its multiple-instance error handling; it is not a runtime behavior ze implements

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

`RFC5492-3-1`

When sending Unsupported Capability NOTIFICATION, the message MUST contain the capability or capabilities that cause the speaker to send the message (§3)