Clause 30 review

Package: ieee8023_clause30-0.0.3+dirty.build20261106t034951316960z-py3-none-any.whl · SHA-256: 0b2bc818465edba4f99e5145a9cc8a7178693e5b5d769f92104c15881cd53c1f

Guidance and findings are review candidates, not conformance results. Reviewers should consult the authoritative standard.

Source and module provenance
Attributes without explicit section references (527)

Grouped by subclause; scope is the selected modules. This is not a coverage or conformance result.

30.3.1.1

30.3.2.1

30.3.3

30.3.4

30.3.5.1

30.3.6.1

30.3.7.1

30.4.1.1

30.4.2.1

30.4.3.1

30.5.1.1

30.6.1.1

30.6.1.2

30.7.1.1

30.7.2.1

30.7.3.1

30.7.4.1

30.8.1.1

30.9.1.1

30.10.1.1

30.10.2.1

30.11.1.1

30.11.2.1

30.12.1.1

30.12.2.1

30.12.3.1

30.13.1

30.14.1

30.15.1.1

30.16.1.1

Attributes with unqualified references (0)

These references need a source before they can be counted as IEEE 802.3 matches.

Findings (9)
Module / nodeLine / clauseStatus / ruleReview details
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/auto-negotiation/negotiation-status		221
30.6.1.1.4
disabled-negotiation-status		Disabled negotiation cannot report no-negotiation — The when condition hides this leaf when enable is false, although its no-negotiation enum describes a disabled function. — aAutoNegAutoConfig
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/auto-negotiation/negotiation-status		221
30.6.1.1.4
parallel-detect-mapping		Parallel detect failure has no explicit mapping — The referenced attribute distinguishes parallel detect failure; the leaf does not name that condition in an enum. Review the mapping to failed. — aAutoNegAutoConfig
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/pmd-type		271
30.5.1.1.2
pmd-mau-mapping		PMD to MAU mapping needs review — The referenced MAU enumeration includes state and complete MAU distinctions. Confirm how these map to the imported PMD identities. RFC 9907 review context: rfc9907-4.11.1-1 https://www.rfc-editor.org/rfc/rfc9907.html#section-4.11.1 RFC 9907 review context: rfc9907-4.11.1-3 https://www.rfc-editor.org/rfc/rfc9907.html#section-4.11.1 — aMAUType RFC 9907 4.11.1
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/duplex		282
30.3.1.1.32
duplex-config-state		Operational duplex is modeled as configuration — The description calls this operational state, but the leaf is writable by default. Clause 30 specifies both GET and SET behavior; clarify the configuration and state mapping. RFC 9907 review context: rfc9907-4.23.1-1 https://www.rfc-editor.org/rfc/rfc9907.html#section-4.23.1 — aDuplexStatus RFC 9907 4.23.1
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/flow-control/pause/statistics/in-frames-pause		333
30.3.4.3
receive-direction		Receive counter describes transmission — The node and referenced attribute identify received events, while the node description says transmitted. — aPAUSEMACCtrlFramesReceived
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/max-frame-length		429
30.3.1.1.37
unknown-frame-length		Frame length has no explicit unknown value — The numeric leaf has no documented representation for the unknown value in the referenced enumeration. — aMaxFrameLength
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/mac-control-extension-control		439
30.3.8.3
extension-read-only		Extension status exposes only read access — The referenced attribute supports reading and setting; this leaf is config false. Confirm whether the restricted mapping is intentional. — aEXTENSIONMACCtrlStatus
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/statistics/in-frames-pause		534
30.3.4.3
receive-direction		Receive counter describes transmission — The node and referenced attribute identify received events, while the node description says transmitted. — aPAUSEMACCtrlFramesReceived
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/in-error-symbol		793
30.3.2.1.5
symbol-event-count		Symbol-error summary suggests counting individual errors — The referenced attribute counts qualifying carrier events with one or more errors, at most once per valid event and subject to collision conditions. — aSymbolErrorDuringCarrier
References (33)
Module / nodeLine / clauseStatus / ruleReview details
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
duplex-type		142
30.3.1.1.32		found
typedef — IEEE Std 802.3 — aDuplexStatus
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
negotiation-status		256
30.6.1.1.4		found
leaf — IEEE 802.3 — aAutoNegAutoConfig
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
phy-type		268
30.3.2.1.2		found
leaf — IEEE Std 802.3 — aPhyType
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
pmd-type		279
30.5.1.1.2		found
leaf — IEEE Std 802.3 — aMAUType
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
duplex		286
30.3.1.1.32		found
leaf — IEEE Std 802.3 — aDuplexStatus
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-frames-pause		339
30.3.4.3		found
leaf — IEEE Std 802.3 — aPAUSEMACCtrlFramesReceived
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
out-frames-pause		349
30.3.4.2		found
leaf — IEEE Std 802.3 — aPAUSEMACCtrlFramesTransmitted
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
max-frame-length		436
30.3.1.1.37		found
leaf — IEEE Std 802.3 — aMaxFrameLength
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
mac-control-extension-control		446
30.3.8.3		found
leaf — IEEE Std 802.3 — aEXTENSIONMACCtrlStatus
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
frame-limit-slow-protocol		460
30.3.1.1.38		found
leaf — IEEE Std 802.3 — aSlowProtocolFrameLimit
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet-pause		485
30.3.4		found
container — IEEE Std 802.3 — PAUSE entity managed object class
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
pfc-enable-status		526
30.3.3.6		found
leaf — IEEE Std 802.3 — aPFCEnableStatus
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-frames-pause		540
30.3.4.3		found
leaf — IEEE Std 802.3 — aPAUSEMACCtrlFramesReceived
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
out-frames-pause		550
30.3.4.2		found
leaf — IEEE Std 802.3 — aPAUSEMACCtrlFramesTransmitted
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-frames		627
30.3.1.1.5		found
leaf — IEEE Std 802.3 — aFramesReceivedOK
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-multicast-frames		643
30.3.1.1.21		found
leaf — IEEE Std 802.3 — aMulticastFramesReceivedOK
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-broadcast-frames		660
30.3.1.1.22		found
leaf — IEEE Std 802.3 — aBroadcastFramesReceivedOK
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-error-fcs-frames		677
30.3.1.1.6		found
leaf — IEEE Std 802.3 — aFrameCheckSequenceErrors
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-error-fcs-frames		677
30.3.1.1.7		found
leaf — IEEE Std 802.3 — aAlignmentErrors
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-error-oversize-frames		708
30.3.1.1.25		found
leaf — IEEE Std 802.3 — aFrameTooLongErrors
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-error-mac-internal-frames		731
30.3.1.1.15		found
leaf — IEEE Std 802.3 — aFramesLostDueToIntMACRcvError
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
out-frames		742
30.3.1.1.2		found
leaf — IEEE Std 802.3 — aFramesTransmittedOK
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
out-multicast-frames		754
30.3.1.1.18		found
leaf — IEEE Std 802.3 — aMulticastFramesXmittedOK
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
out-broadcast-frames		767
30.3.1.1.19		found
leaf — IEEE Std 802.3 — aBroadcastFramesXmittedOK
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
out-error-mac-internal-frames		785
30.3.1.1.12		found
leaf — IEEE Std 802.3 — aFramesLostDueToIntMACXmitError
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-error-symbol		804
30.3.2.1.5		found
leaf — IEEE Std 802.3 — aSymbolErrorDuringCarrier
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-lpi-transitions		823
30.3.2.1.11		found
leaf — IEEE Std 802.3 — aReceiveLPITransitions
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-lpi-time		835
30.3.2.1.9		found
leaf — IEEE Std 802.3 — aReceiveLPIMicroseconds
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
out-lpi-transitions		850
30.3.2.1.10		found
leaf — IEEE Std 802.3 — aTransmitLPITransitions
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
out-lpi-time		862
30.3.2.1.8		found
leaf — IEEE Std 802.3 — aTransmitLPIMicroseconds
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-frames-mac-control-unknown		884
30.3.3.5		found
leaf — IEEE Std 802.3 — aUnsupportedOpcodesReceived
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
in-frames-mac-control-extension		894
30.3.8.2		found
leaf — IEEE Std 802.3 — aEXTENSIONMACCtrlFramesReceived
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
out-frames-mac-control-extension		904
30.3.8.1		found
leaf — IEEE Std 802.3 — aEXTENSIONMACCtrlFramesTransmitted
Mapping guidance (132)
Module / nodeLine / clauseStatus / ruleReview details
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
duplex-type		123
30.3.1.1.32		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — enumeration — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
duplex-type		123
30.3.1.1.32		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — enumeration
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
duplex-type		123
30.3.1.1.32		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — enumeration — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
duplex-type		123
30.3.1.1.32		guidance
enumeration-syntax		enumeration or identityref Enumeration is a candidate, not an automatic choice; verify extensibility, identifiers, values, and descriptions. — enumeration — enumeration, identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/auto-negotiation/negotiation-status		221
30.6.1.1.4		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — enumeration — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/auto-negotiation/negotiation-status		221
30.6.1.1.4		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — enumeration
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/auto-negotiation/negotiation-status		221
30.6.1.1.4		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — enumeration — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/auto-negotiation/negotiation-status		221
30.6.1.1.4		guidance
enumeration-syntax		enumeration or identityref Enumeration is a candidate, not an automatic choice; verify extensibility, identifiers, values, and descriptions. — enumeration — enumeration, identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/phy-type		260
30.3.2.1.2		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — identityref — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/phy-type		260
30.3.2.1.2		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/phy-type		260
30.3.2.1.2		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — identityref — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/phy-type		260
30.3.2.1.2		guidance
access-semantics		assume read-only - state, Read/write - configuration based on definition Read/write wording is a review signal. YANG config models configuration versus state, while datastore semantics and access control are separate; read-only wording alone does not prove config false. — identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/pmd-type		271
30.5.1.1.2		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — identityref — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/pmd-type		271
30.5.1.1.2		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/pmd-type		271
30.5.1.1.2		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — identityref — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/pmd-type		271
30.5.1.1.2		guidance
enumeration-syntax		enumeration or identityref Enumeration is a candidate, not an automatic choice; verify extensibility, identifiers, values, and descriptions. — identityref — enumeration, identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/pmd-type		271
30.5.1.1.2		guidance
access-semantics		assume read-only - state, Read/write - configuration based on definition Read/write wording is a review signal. YANG config models configuration versus state, while datastore semantics and access control are separate; read-only wording alone does not prove config false. — identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/duplex		282
30.3.1.1.32		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — duplex-type — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/duplex		282
30.3.1.1.32		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — duplex-type
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/duplex		282
30.3.1.1.32		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — duplex-type — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/duplex		282
30.3.1.1.32		type_unresolved
enumeration-syntax		enumeration or identityref Enumeration is a candidate, not an automatic choice; verify extensibility, identifiers, values, and descriptions. — duplex-type — enumeration, identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/flow-control/pause/statistics/in-frames-pause		333
30.3.4.3		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/flow-control/pause/statistics/in-frames-pause		333
30.3.4.3		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/flow-control/pause/statistics/in-frames-pause		333
30.3.4.3		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/flow-control/pause/statistics/in-frames-pause		333
30.3.4.3		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/flow-control/pause/statistics/out-frames-pause		343
30.3.4.2		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/flow-control/pause/statistics/out-frames-pause		343
30.3.4.2		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/flow-control/pause/statistics/out-frames-pause		343
30.3.4.2		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/flow-control/pause/statistics/out-frames-pause		343
30.3.4.2		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/max-frame-length		429
30.3.1.1.37		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — uint16 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/max-frame-length		429
30.3.1.1.37		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — uint16
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/max-frame-length		429
30.3.1.1.37		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — uint16 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/max-frame-length		429
30.3.1.1.37		review_mapping
enumeration-syntax		enumeration or identityref Enumeration is a candidate, not an automatic choice; verify extensibility, identifiers, values, and descriptions. — uint16 — enumeration, identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/mac-control-extension-control		439
30.3.8.3		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — boolean — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/mac-control-extension-control		439
30.3.8.3		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — boolean
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/mac-control-extension-control		439
30.3.8.3		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — boolean — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/mac-control-extension-control		439
30.3.8.3		review_mapping
enumeration-syntax		enumeration or identityref Enumeration is a candidate, not an automatic choice; verify extensibility, identifiers, values, and descriptions. — boolean — enumeration, identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/mac-control-extension-control		439
30.3.8.3		guidance
access-semantics		assume read-only - state, Read/write - configuration based on definition Read/write wording is a review signal. YANG config models configuration versus state, while datastore semantics and access control are separate; read-only wording alone does not prove config false. — boolean
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/frame-limit-slow-protocol		450
30.3.1.1.38		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — uint64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/frame-limit-slow-protocol		450
30.3.1.1.38		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — uint64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/frame-limit-slow-protocol		450
30.3.1.1.38		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — uint64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/frame-limit-slow-protocol		450
30.3.1.1.38		guidance
integer-syntax		Choose signedness, width, range, and any derived type from the actual definition; INTEGER alone does not choose them. — uint64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause		474
30.3.4		guidance
managed-object-class		A class may be represented by a container or a list; instance multiplicity, keys, and placement must be established from the model.
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/control-and-status/pfc-enable-status		519
30.3.3.6		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — boolean — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/control-and-status/pfc-enable-status		519
30.3.3.6		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — boolean
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/control-and-status/pfc-enable-status		519
30.3.3.6		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — boolean — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/control-and-status/pfc-enable-status		519
30.3.3.6		review_mapping
enumeration-syntax		enumeration or identityref Enumeration is a candidate, not an automatic choice; verify extensibility, identifiers, values, and descriptions. — boolean — enumeration, identityref
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/control-and-status/pfc-enable-status		519
30.3.3.6		guidance
access-semantics		assume read-only - state, Read/write - configuration based on definition Read/write wording is a review signal. YANG config models configuration versus state, while datastore semantics and access control are separate; read-only wording alone does not prove config false. — boolean
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/statistics/in-frames-pause		534
30.3.4.3		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/statistics/in-frames-pause		534
30.3.4.3		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/statistics/in-frames-pause		534
30.3.4.3		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/statistics/in-frames-pause		534
30.3.4.3		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/statistics/out-frames-pause		544
30.3.4.2		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/statistics/out-frames-pause		544
30.3.4.2		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/statistics/out-frames-pause		544
30.3.4.2		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/ethernet-pause/statistics/out-frames-pause		544
30.3.4.2		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-frames		616
30.3.1.1.5		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-frames		616
30.3.1.1.5		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-frames		616
30.3.1.1.5		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-frames		616
30.3.1.1.5		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-multicast-frames		630
30.3.1.1.21		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-multicast-frames		630
30.3.1.1.21		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-multicast-frames		630
30.3.1.1.21		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-multicast-frames		630
30.3.1.1.21		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-broadcast-frames		647
30.3.1.1.22		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-broadcast-frames		647
30.3.1.1.22		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-broadcast-frames		647
30.3.1.1.22		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-broadcast-frames		647
30.3.1.1.22		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-fcs-frames		664
30.3.1.1.6		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-fcs-frames		664
30.3.1.1.6		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-fcs-frames		664
30.3.1.1.6		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-fcs-frames		664
30.3.1.1.6		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-fcs-frames		664
30.3.1.1.7		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-fcs-frames		664
30.3.1.1.7		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-fcs-frames		664
30.3.1.1.7		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-fcs-frames		664
30.3.1.1.7		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-oversize-frames		697
30.3.1.1.25		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-oversize-frames		697
30.3.1.1.25		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-oversize-frames		697
30.3.1.1.25		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-oversize-frames		697
30.3.1.1.25		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-mac-internal-frames		712
30.3.1.1.15		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-mac-internal-frames		712
30.3.1.1.15		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-mac-internal-frames		712
30.3.1.1.15		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/in-error-mac-internal-frames		712
30.3.1.1.15		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-frames		735
30.3.1.1.2		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-frames		735
30.3.1.1.2		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-frames		735
30.3.1.1.2		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-frames		735
30.3.1.1.2		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-multicast-frames		745
30.3.1.1.18		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-multicast-frames		745
30.3.1.1.18		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-multicast-frames		745
30.3.1.1.18		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-multicast-frames		745
30.3.1.1.18		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-broadcast-frames		758
30.3.1.1.19		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-broadcast-frames		758
30.3.1.1.19		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-broadcast-frames		758
30.3.1.1.19		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-broadcast-frames		758
30.3.1.1.19		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-error-mac-internal-frames		771
30.3.1.1.12		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-error-mac-internal-frames		771
30.3.1.1.12		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-error-mac-internal-frames		771
30.3.1.1.12		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/frame/out-error-mac-internal-frames		771
30.3.1.1.12		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/in-error-symbol		793
30.3.2.1.5		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/in-error-symbol		793
30.3.2.1.5		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/in-error-symbol		793
30.3.2.1.5		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/in-error-symbol		793
30.3.2.1.5		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/in-lpi-transitions		812
30.3.2.1.11		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/in-lpi-transitions		812
30.3.2.1.11		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/in-lpi-transitions		812
30.3.2.1.11		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/in-lpi-transitions		812
30.3.2.1.11		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/in-lpi-time		827
30.3.2.1.9		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — decimal64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/in-lpi-time		827
30.3.2.1.9		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — decimal64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/in-lpi-time		827
30.3.2.1.9		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — decimal64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/in-lpi-time		827
30.3.2.1.9		review_mapping
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — decimal64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/out-lpi-transitions		839
30.3.2.1.10		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/out-lpi-transitions		839
30.3.2.1.10		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/out-lpi-transitions		839
30.3.2.1.10		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/out-lpi-transitions		839
30.3.2.1.10		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/out-lpi-time		854
30.3.2.1.8		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — decimal64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/out-lpi-time		854
30.3.2.1.8		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — decimal64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/out-lpi-time		854
30.3.2.1.8		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — decimal64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/phy/lpi/out-lpi-time		854
30.3.2.1.8		review_mapping
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — decimal64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/in-frames-mac-control-unknown		874
30.3.3.5		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/in-frames-mac-control-unknown		874
30.3.3.5		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/in-frames-mac-control-unknown		874
30.3.3.5		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/in-frames-mac-control-unknown		874
30.3.3.5		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/in-frames-mac-control-extension		888
30.3.8.2		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/in-frames-mac-control-extension		888
30.3.8.2		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/in-frames-mac-control-extension		888
30.3.8.2		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/in-frames-mac-control-extension		888
30.3.8.2		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/out-frames-mac-control-extension		898
30.3.8.1		guidance
attribute		leaf, leaf-list, list, container Scalar attributes are candidates for leaf; collections and structured values may require leaf-list, list, or container. Source access semantics do not by themselves select config true or false. — yang:counter64 — leaf, leaf-list, list, container
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/out-frames-mac-control-extension		898
30.3.8.1		guidance
syntax-field		map APPROPRIATE SYNTAX to YANG leaf or leaf-list for attribiutes, for an action, use it to identify parameters and types — yang:counter64
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/out-frames-mac-control-extension		898
30.3.8.1		guidance
behavior-field		Use description for human-readable semantics and reference for the IEEE source — yang:counter64 — description, reference
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
ethernet/statistics/mac-control/out-frames-mac-control-extension		898
30.3.8.1		guidance
counter-syntax		prefer to yang:counter64 A counter is a state-data candidate, not an automatic type selection. Preserve increment, reset, width, discontinuity, and applicability semantics; these RFCs do not define a Clause 30 counter mapping. — yang:counter64 — yang:counter64
Prose warnings (3)
Module / nodeLine / clauseStatus / ruleReview details
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
PAUSE entity managed object class		485
30.3.4		clause30_extract
description: spelling: 'behaviours'
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
aPFCEnableStatus		526
30.3.3.6		clause30_extract
description: spelling: 'enablement'
/home/petejone/yang/git_802_3/yang_main/Modules/Approved/ieee802-ethernet-interface.yang
aMulticastFramesReceivedOK		643
30.3.1.1.21		clause30_extract
description: spelling: 'nonbroadcast'
RFC 9907 reviewer reference

Labels and uppercase terms are heuristic review aids; applicability and examples require human review.

SectionParagraphCandidate labels and termsText
4.1 Module Naming Conventionsrfc9907-4.1-1rule, MUSTNormative modules contained in Standards Track documents MUST be named according to the guidelines in the IANA Considerations section of [RFC6020].
4.1 Module Naming Conventionsrfc9907-4.1-2advice, SHOULDA distinctive word or abbreviation (e.g., protocol name or working group abbreviation) SHOULD be used in the module name. If new definitions are being defined to extend one or more existing modules, then the same word or abbreviation should be reused, instead of creating a new one.
4.1 Module Naming Conventionsrfc9907-4.1-3rule, MUSTAll published module names MUST be unique. For a YANG module published in an RFC, this uniqueness is guaranteed by IANA (Section 14 of [RFC6020]). For unpublished modules, the authors need to check that no other work in progress is using the same module name.
4.1 Module Naming Conventionsrfc9907-4.1-4advice, SHOULDExample modules are non-normative and SHOULD be named with the prefix "example-".
4.1 Module Naming Conventionsrfc9907-4.1-5rule, advice, MUSTIt is suggested that a stable module name prefix be selected that represents the entire organization. All normative YANG modules published by the IETF MUST begin with the prefix "ietf-". All IANA- maintained YANG modules MUST begin with the prefix "iana-". Another standards organization, such as the IEEE, might use the prefix "ieee-" for all YANG modules.
4.1 Module Naming Conventionsrfc9907-4.1-6rule, MUST NOTOnce a module name is published, it MUST NOT be reused, even if the RFC containing the module is reclassified to "Historic" status. A module name cannot be changed in YANG, and this would be treated as a new module, not a name change.
4.2 Prefixesrfc9907-4.2-1All YANG definitions are scoped by the module containing the definition being referenced. This allows the same name to be used in multiple modules, even if the names are not unique. In the example below, the identifier "foo" is used in all three modules:
4.2 Prefixesrfc9907-4.2-2module example-foo { namespace "tag:example.com,2017:example-foo"; prefix f;
4.2 Prefixesrfc9907-4.2-3container foo; }
4.2 Prefixesrfc9907-4.2-4module example-bar { namespace "tag:example.com,2017:example-bar"; prefix b;
4.2 Prefixesrfc9907-4.2-5typedef foo { type uint32; } }
4.2 Prefixesrfc9907-4.2-6module example-one { namespace "tag:example.com,2017:example-one"; prefix one; import example-foo { prefix f; } import example-bar { prefix b; }
4.2 Prefixesrfc9907-4.2-7augment "/f:foo" { leaf foo { type b:foo; } } }
4.2 Prefixesrfc9907-4.2-8YANG defines the following rules for prefix usage:
4.2 Prefixesrfc9907-4.2-9* Prefixes are never used for built-in data types and YANG keywords.
4.2 Prefixesrfc9907-4.2-10rule, MUST* A prefix MUST be used for any external statement (i.e., a statement defined with the YANG "extension" statement).
4.2 Prefixesrfc9907-4.2-11rule, MUST* The proper module prefix MUST be used for all identifiers imported from other modules.
4.2 Prefixesrfc9907-4.2-12rule, MUST* The proper module prefix MUST be used for all identifiers included from a submodule.
4.2 Prefixesrfc9907-4.2-13The following guidelines apply to prefix usage of the current (local) module:
4.2 Prefixesrfc9907-4.2-14advice, SHOULD* The local module prefix SHOULD be used instead of no prefix in all path expressions.
4.2 Prefixesrfc9907-4.2-15rule, MUST* The local module prefix MUST be used instead of no prefix in all "default" statements for an "identityref" or "instance-identifier" data type.
4.2 Prefixesrfc9907-4.2-16permission, MAY* The local module prefix MAY be used for references to typedefs, groupings, extensions, features, and identities defined in the module.
4.2 Prefixesrfc9907-4.2-17definition, advice, SHOULDConsistent with Section 7.1.4 of [RFC7950], the prefix defined by a module SHOULD be used when the module is imported, unless there is a conflict.
4.2 Prefixesrfc9907-4.2-18advice, SHOULD, SHOULD NOTPrefix values SHOULD be short but meaningful to the intended user. Prefix values SHOULD NOT conflict with known modules that have been previously published.
4.2 Prefixesrfc9907-4.2-19advice, SHOULDFor convenience, prefix values of example modules SHOULD be prefixed with "ex" or similar patterns. In doing so, readers of example modules or tree diagrams that mix both example and standard modules can easily identify example parts.
4.3 Identifiersrfc9907-4.3-1rule, MUSTAll YANG identifiers in published modules MUST be between 1 and 64 characters in length. These include any construct specified as an "identifier-arg-str" token in the ABNF in Section 14 of [RFC7950].
4.3.1 Identifier Naming Conventionsrfc9907-4.3.1-1advice, permission, MAY, SHOULDIdentifiers SHOULD follow a consistent naming pattern throughout the module. Only lowercase letters, numbers, and dashes SHOULD be used in identifier names. Uppercase characters, the period character, and the underscore character MAY be used if the identifier represents a well-known value that uses these characters. YANG does not permit any other characters in YANG identifiers.
4.3.1 Identifier Naming Conventionsrfc9907-4.3.1-2advice, SHOULD, SHOULD NOTIdentifiers SHOULD include complete words and/or well-known acronyms or abbreviations. Child nodes within a container or list SHOULD NOT replicate the parent identifier. YANG identifiers are hierarchical and are only meant to be unique within the set of sibling nodes defined in the same module namespace.
4.3.1 Identifier Naming Conventionsrfc9907-4.3.1-3advice, SHOULDList identifiers SHOULD be singular with the surrounding container name plural. Similarly, "leaf-list" identifiers SHOULD be singular.
4.3.1 Identifier Naming Conventionsrfc9907-4.3.1-4It is permissible to use common identifiers such as "name" or "id" in data definition statements, especially if these data nodes share a common data type.
4.3.1 Identifier Naming Conventionsrfc9907-4.3.1-5advice, SHOULD NOTIdentifiers SHOULD NOT carry any special semantics that identify data modeling properties. Only YANG statements and YANG extension statements are designed to convey machine-readable data modeling properties. For example, naming an object "config" or "state" does not change whether it is configuration data or state data. Only defined YANG statements or YANG "extension" statements can be used to assign semantics in a machine-readable format in YANG.
4.4 Defaultsrfc9907-4.4-1advice, SHOULD NOTIn general, it is suggested that substatements containing very common default values SHOULD NOT be present. The substatements listed in Table 1 are commonly used with the default value, which would make the module difficult to read if used everywhere they are allowed.
4.4 Defaultsrfc9907-4.4-2+==============+===============+ | Statement | Default Value | +==============+===============+ | config | true | +--------------+---------------+ | mandatory | false | +--------------+---------------+ | max-elements | unbounded | +--------------+---------------+ | min-elements | 0 | +--------------+---------------+ | ordered-by | system | +--------------+---------------+ | status | current | +--------------+---------------+ | yin-element | false | +--------------+---------------+
4.4 Defaultsrfc9907-4.4-3Table 1: Statement Defaults
4.5 Conditional Statementsrfc9907-4.5-1A module may be conceptually partitioned in several ways using the "if-feature" and/or "when" statements.
4.5 Conditional Statementsrfc9907-4.5-2Data model designers need to carefully consider all modularity aspects, including the use of YANG conditional statements.
4.5 Conditional Statementsrfc9907-4.5-3advice, SHOULDIf a data definition is optional, depending on server support for a NETCONF or RESTCONF protocol capability, then a YANG "feature" statement SHOULD be defined. The defined "feature" statement SHOULD then be used in the conditional "if-feature" statement referencing the optional data definition.
4.5 Conditional Statementsrfc9907-4.5-4rule, MUSTIf any notification data, or any data definition, for a non- configuration data node is not mandatory, then the server may or may not be required to return an instance of this data node. If any conditional requirements exist for returning the data node in a notification payload or retrieval request, they MUST be documented somewhere. For example, a "when" or "if-feature" statement could apply to the data node or the conditional requirements could be explained in a "description" statement within the data node or one of its ancestors (if any).
4.5 Conditional Statementsrfc9907-4.5-5rule, MUST, MUST NOTIf any "if-feature" statements apply to a list node, then the same "if-feature" statements MUST apply to any key leaf nodes for the list. There MUST NOT be any "if-feature" statements applied to any key leafs that do not also apply to the parent list node.
4.5 Conditional Statementsrfc9907-4.5-6advice, SHOULD, SHOULD NOTThere SHOULD NOT be any "when" statements applied to a key leaf node. It is possible that a "when" statement for an ancestor node of a key leaf will have the exact node-set result as the key leaf. In such a case, the "when" statement for the key leaf is redundant and SHOULD be avoided.
4.5 Conditional Statementsrfc9907-4.5-7advice, SHOULD NOTSome modules use a "case + when" construct but provide duplicated information (e.g., the "when" statements are constraining a single case in the choice as shown in the example below). Such constructs with duplicated information SHOULD NOT be used.
4.5 Conditional Statementsrfc9907-4.5-8leaf type { type enumeration { enum a; enum b; enum c; } mandatory true; } choice type-choice { case b { container type-b { when "../type = 'b'"; leaf foo { type string; } } } case c { container type-c { when "../type = 'c'"; leaf bar { mandatory true; type string; } } } }
4.5 Conditional Statementsrfc9907-4.5-9The following example removes the duplicated information:
4.5 Conditional Statementsrfc9907-4.5-10leaf type { type enumeration { enum a; enum b; enum c; } mandatory true; } container type-b { when "../type = 'b'"; leaf foo { type string; } } container type-c { when "../type = 'c'"; leaf bar { mandatory true; type string; } }
4.5 Conditional Statementsrfc9907-4.5-11adviceNote that the use of "case + when" is still useful in cases where complementary modeling constraints should be expressed. See the example provided below:
4.5 Conditional Statementsrfc9907-4.5-12leaf type { type enumeration { enum a; enum b; enum c; } } choice second-type { mandatory true; case foo { container foo { presence "When present, indicates type foo"; leaf foo-attribute { type string; } } } case b { container bar { when "../type = 'a' or ../type = 'b'"; presence "When present, indicates type bar"; leaf bar-attribute { type string; } } } case c { container baz { when "../type = 'c'"; leaf baz-attribute { mandatory true; type string; } } } }
4.5 Conditional Statementsrfc9907-4.5-13rule, advice, RECOMMENDEDSection 8.1 of [RFC7950] includes provisions for defining constraints on state data and specifies that a constraint must be true in a valid state data tree. However, Section 5.3 of [RFC8342] softens that behavior by allowing semantic constraints to be violated under some circumstances to help to detect anomalies. Relaxing validation constraints on state data is meant to reveal deviations of the observed behavior versus intended behavior of a managed entity and hopefully trigger corrective actions by a management system. From that perspective, it is RECOMMENDED to avoid defining constraints on state data that would hinder the detection by a management system of abnormal behaviors of a managed entity.
4.6 XPath Usagerfc9907-4.6-1This section describes guidelines for using the XML Path Language (XPath) [W3C.REC-xpath] within YANG modules.
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-1YANG defines five separate contexts for evaluation of "XPath" statements:
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-2definition1. The "running" datastore: collection of all YANG configuration data nodes. The document root is the conceptual container (e.g., "config" in the "edit-config" operation), which is the parent of all top-level data definition statements with a "config" statement value of "true".
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-3definition2. State data + the "running" datastore: collection of all YANG data nodes. The document root is the conceptual container, parent of all top-level data definition statements.
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-4definition3. Notification: an event notification document. The document root is the notification element.
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-5definition4. RPC Input: The document root is the conceptual "input" node, which is the parent of all RPC input parameter definitions.
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-6definition5. RPC Output: The document root is the conceptual "output" node, which is the parent of all RPC output parameter definitions.
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-7Note that these XPath contexts cannot be mixed. For example, a "when" statement in a notification context cannot reference configuration data.
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-8notification foo { leaf mtu { // NOT okay because when-stmt context is this notification when "/if:interfaces/if:interface[name='eth0']"; type leafref { // Okay because path-stmt has a different context path "/if:interfaces/if:interface/if:mtu"; } } }
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-9It is especially important to consider the XPath evaluation context for XPath expressions defined in groupings. An XPath expression defined in a grouping may not be portable, meaning it cannot be used in multiple contexts and produce proper results.
4.6.1 XPath Evaluation Contextsrfc9907-4.6.1-10advice, SHOULDIf the XPath expressions defined in a grouping are intended for a particular context, then this context SHOULD be identified in the "description" statement for the grouping.
4.6.2 Function Libraryrfc9907-4.6.2-1definition, rule, advice, permission, MAY, SHOULD NOTThe "position" and "last" functions SHOULD NOT be used. This applies to implicit use of the "position" function as well (e.g., '//chapter[42]'). A server is only required to maintain the relative XML document order of all instances of a particular user-ordered list or leaf-list. The "position" and "last" functions MAY be used if they are evaluated in a context where the context node is a user- ordered "list" or "leaf-list".
4.6.2 Function Libraryrfc9907-4.6.2-2advice, SHOULD, SHOULD NOTThe "id" function SHOULD NOT be used. The "ID" attribute is not present in YANG documents, so this function has no meaning. The XPath execution environment SHOULD return an empty string for this function.
4.6.2 Function Libraryrfc9907-4.6.2-3advice, SHOULD NOTThe "namespace-uri" and "name" functions SHOULD NOT be used. Expanded names in XPath are different than YANG. A specific canonical representation of a YANG-expanded name does not exist.
4.6.2 Function Libraryrfc9907-4.6.2-4advice, SHOULD, SHOULD NOTThe "lang" function SHOULD NOT be used. This function does not apply to YANG because there is no "lang" attribute set with the document. The XPath execution environment SHOULD return "false" for this function.
4.6.2 Function Libraryrfc9907-4.6.2-5definition, advice, SHOULD NOTThe "local-name", "namespace-uri", "name", "string", and "number" functions SHOULD NOT be used if the argument is a node-set. If so, the function result will be determined by the document order of the node-set. Since this order can be different on each server, the function results can also be different. Any function call that implicitly converts a node-set to a string will also have this issue.
4.6.2 Function Libraryrfc9907-4.6.2-6rule, advice, SHOULD NOTThe "local-name" function SHOULD NOT be used to reference local names outside of the YANG module that defines the "must" or "when" statement containing the "local-name" function. Example of a "local- name" function that should not be used:
4.6.2 Function Libraryrfc9907-4.6.2-7/*[local-name()='foo']
4.6.2 Function Libraryrfc9907-4.6.2-8advice, SHOULDThe "derived-from-or-self" function SHOULD be used instead of an equality expression for identityref values. This allows the identities to be conceptually augmented.
4.6.2 Function Libraryrfc9907-4.6.2-9Example:
4.6.2 Function Libraryrfc9907-4.6.2-10definition// assume "ex" is the prefix of the module where the identity // name-format-null is defined
4.6.2 Function Libraryrfc9907-4.6.2-11// do not use when "md-name-format = 'name-format-null'";
4.6.2 Function Libraryrfc9907-4.6.2-12// this is preferred when "derived-from-or-self(md-name-format, 'ex:name-format-null')";
4.6.3 Axesrfc9907-4.6.3-1permission, MAYThe "attribute" and "namespace" axes are not supported in YANG and MAY be empty in a NETCONF or RESTCONF server implementation.
4.6.3 Axesrfc9907-4.6.3-2advice, permission, MAY, SHOULD, SHOULD NOTThe "preceding" and "following" axes SHOULD NOT be used. These constructs rely on XML document order within a NETCONF or RESTCONF server configuration database, which may not be supported consistently or produce reliable results across implementations. Predicate expressions based on static node properties (e.g., element name or value, and "ancestor" or "descendant" axes) SHOULD be used instead. The "preceding" and "following" axes MAY be used if document order is not relevant to the outcome of the expression (e.g., check for global uniqueness of a parameter value).
4.6.3 Axesrfc9907-4.6.3-3advice, permission, MAY, SHOULD NOTThe "preceding-sibling" and "following-sibling" axes SHOULD NOT be used; however, they MAY be used if document order is not relevant to the outcome of the expression.
4.6.3 Axesrfc9907-4.6.3-4definition, rule, permission, MAYA server is only required to maintain the relative XML document order of all instances of a particular user-ordered list or leaf-list. The "preceding-sibling" and "following-sibling" axes MAY be used if they are evaluated in a context where the context node is a user-ordered "list" or "leaf-list".
4.6.4 Typesrfc9907-4.6.4-1advice, permission, MAY, SHOULD NOTData nodes that use the "int64" and "uint64" built-in type SHOULD NOT be used within numeric or boolean expressions. There are boundary conditions in which the translation from the YANG 64-bit type to an XPath number can cause incorrect results. Specifically, an XPath "double" precision floating-point number cannot represent very large positive or negative 64-bit numbers because it only provides a total precision of 53 bits. The "int64" and "uint64" data types MAY be used in numeric expressions if the value can be represented with no more than 53 bits of precision.
4.6.4 Typesrfc9907-4.6.4-2advice, SHOULDData modelers need to be careful not to confuse the YANG value space and the XPath value space. The data types are not the same in both, and conversion between YANG and XPath data types SHOULD be considered carefully.
4.6.4 Typesrfc9907-4.6.4-3permission, MAYExplicit XPath data type conversions MAY be used (e.g., "string", "boolean", or "number" functions), instead of implicit XPath data type conversions.
4.6.4 Typesrfc9907-4.6.4-4advice, SHOULDXPath expressions that contain a literal value representing a YANG identity SHOULD always include the declared prefix of the module where the identity is defined.
4.6.4 Typesrfc9907-4.6.4-5advice, permission, MAY, SHOULD NOTXPath expressions for "when" statements SHOULD NOT reference the context node or any descendant nodes of the context node. They MAY reference descendant nodes if the "when" statement is contained within an "augment" statement and the referenced nodes are not defined within the "augment" statement.
4.6.4 Typesrfc9907-4.6.4-6Example:
4.6.4 Typesrfc9907-4.6.4-7augment "/rt:active-route/rt:input/rt:destination-address" { when "derived-from-or-self(rt:address-family, " + "'v4ur:ipv4-unicast')" { description "This augment is valid only for IPv4 unicast."; } // nodes defined here within the augment-stmt // cannot be referenced in the when-stmt }
4.6.5 Wildcardsrfc9907-4.6.5-1It is possible to construct XPath expressions that will evaluate differently when combined with several modules within a server implementation rather than when evaluated within the single module. This is due to augmenting nodes from other modules.
4.6.5 Wildcardsrfc9907-4.6.5-2rule, advice, SHOULDWildcard expansion is done within a server against all the nodes from all namespaces, so it is possible for a "must" or "when" statement that uses the '*' operator to always evaluate to false if processed within a single YANG module. In such cases, the "description" statement SHOULD clarify that augmenting objects are expected to match the wildcard expansion.
4.6.5 Wildcardsrfc9907-4.6.5-3when /foo/services/*/active { description "No services directly defined in this module. Matches objects that have augmented the services container."; }
4.6.6 Boolean Expressionsrfc9907-4.6.6-1ruleThe YANG "must" and "when" statements use an XPath boolean expression to define the test condition for the statement. It is important to specify these expressions in a way that will not cause inadvertent changes in the result if the objects referenced in the expression are updated in future revisions of the module.
4.6.6 Boolean Expressionsrfc9907-4.6.6-2ruleFor example, the leaf "foo2" must exist if the leaf "foo1" is equal to "one" or "three":
4.6.6 Boolean Expressionsrfc9907-4.6.6-3leaf foo1 { type enumeration { enum one; enum two; enum three; } }
4.6.6 Boolean Expressionsrfc9907-4.6.6-4ruleleaf foo2 { // INCORRECT must "/f:foo1 != 'two'"; type string; } leaf foo2 { // CORRECT must "/f:foo1 = 'one' or /f:foo1 = 'three'"; type string; }
4.6.6 Boolean Expressionsrfc9907-4.6.6-5In the next revision of the module, leaf "foo1" is extended with a new enum named "four":
4.6.6 Boolean Expressionsrfc9907-4.6.6-6leaf foo1 { type enumeration { enum one; enum two; enum three; enum four; } }
4.6.6 Boolean Expressionsrfc9907-4.6.6-7Now the first XPath expression will allow the enum "four" to be accepted in addition to the "one" and "three" enum values.
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-1rule, advice, MUST, SHOULD, SHOULD NOTThe YANG status statement MUST be present within a definition if its value is "deprecated" or "obsolete". The status SHOULD NOT be changed from "current" directly to "obsolete". An object SHOULD be available for at least one year after the publication date with a "deprecated" status before it is changed to "obsolete".
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-2rule, MUST NOTThe module or submodule name MUST NOT be changed once the document containing the module or submodule is published.
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-3rule, MUST NOTThe module namespace URI value MUST NOT be changed once the document containing the module is published.
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-4advice, SHOULDThe revision date substatement within the "import" statement SHOULD be present if any groupings are used from the external module.
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-5advice, SHOULDThe revision date substatement within the "include" statement SHOULD be present if any groupings are used from the external submodule.
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-6advice, SHOULDIf an "import" statement is for a module from a stable source (e.g., an RFC for an IETF module), then a reference-stmt SHOULD be present within an "import" statement.
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-7import ietf-yang-types { prefix yang; reference "RFC 9911: Common YANG Data Types"; }
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-8rule, MUSTIf submodules are used, then the document containing the main module MUST be updated so that the main module revision date is equal to or more recent than the revision date of any submodule that is (directly or indirectly) included by the main module.
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-9advice, SHOULD NOTDefinitions for future use SHOULD NOT be specified in a module. Do not specify placeholder objects like the "reserved" example below:
4.7 YANG Definition Lifecycle Managementrfc9907-4.7-10leaf reserved { type string; description "This object has no purpose at this time, but a future revision of this module might define a purpose for this object."; }
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-1rule, MUSTFor published modules, the namespace MUST be a globally unique URI, as defined in [RFC3986]. This value is usually assigned by the IANA.
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-2rule, advice, MUST, SHOULDThe "organization" statement MUST be present. If the module is contained in a document intended for IETF Standards Track status, then the organization SHOULD be the IETF working group (WG) chartered to write the document. Exceptions include (but are not limited to): example modules, IANA-maintained YANG modules, or modules contained in AD-sponsored documents. For other standards organizations, a similar approach is also suggested.
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-3rule, advice, permission, MAY, MUST, SHOULDThe "contact" statement MUST be present. If the module is contained in a document intended for Standards Track status, then the WG web and mailing information SHOULD be present, and the main document author or editor contact information SHOULD be present. If additional authors or editors exist, their contact information MAY be present. There is no need to include the contact information for WG Chairs.
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-4rule, MUSTThe "description" statement MUST be present. For modules published within IETF documents, the appropriate IETF Trust Copyright text MUST be present, as described in Section 3.1, and MUST contain the following statement:
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-5| All revisions of IETF and IANA published modules can be found at | the "YANG Parameters" registry group: | <https://www.iana.org/assignments/yang-parameters>.
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-6rule, MUSTIf the module relies on information contained in other documents, which are not the same documents implied by the "import" statements present in the module, then these documents MUST be identified in the "reference" statement.
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-7definition, rule, permission, MAY, MUSTA "revision" statement MUST be present for each published version of the module. The "revision" statement MUST have a "reference" substatement. It MUST identify the published document that contains the module. Modules are often extracted from their original documents, and it is useful for developers and operators to know how to find the original source document in a consistent manner. The "revision" statement MAY have a "description" substatement. For convenience, the description text of a new published revision may summarize any changes made to a module compared to the previous published revision. Typically, that list is a YANG-specific subset of the summary of changes listing any changes made from the RFC being updated or obsoleted as per [ID-Guidelines].
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-8The following example shows the "revision" statement for a published YANG module:
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-9revision 2010-09-24 { description "Initial revision."; reference "RFC 6021: Common YANG Data Types"; }
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-10The following example shows the "revision" statements for a published YANG module that updates a published module. The new "revision" statement summarizes the changes compared to the previous published revision.
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-11revision 2013-07-15 { description "This revision adds the following new data types: - yang:yang-identifier - yang:hex-string - yang:uuid - yang:dotted-quad"; reference "RFC 6991: Common YANG Data Types"; }
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-12revision 2010-09-24 { description "Initial revision."; reference "RFC 6021: Common YANG Data Types"; }
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-13rule, MUSTFor an unpublished module, a complete history of each unpublished module revision is not required. That is, within a sequence of draft versions, only the most recent revision need be recorded in the module. Do not remove or reuse a "revision" statement for a published module. A new revision date is not required unless the module contents have changed. If the module contents have changed, then the revision date of that new module version MUST be updated to a date later than that of the previous version.
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-14The following example shows the "revision" statements for an unpublished update to a published YANG module. The latest "revision" statement of the unpublished module summarizes the changes compared to the previous revision.
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-15revision 2025-12-22 { description "This revision adds the following new data types: - yang:date - yang:date-no-zone - yang:time - yang:time-no-zone - yang:hours32 - yang:minutes32 - yang:seconds32 - yang:centiseconds32 - yang:milliseconds32 - yang:microseconds32 - yang:microseconds64 - yang:nanoseconds32 - yang:nanoseconds64 - yang:language-tag The yang-identifier definition has been aligned with YANG 1.1 and types representing time support the representation of leap seconds. The representation of time zone offsets has been aligned with RFC 9557. Several description and pattern statements have been improved."; reference "RFC 9911: Common YANG Data Types"; }
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-16revision 2013-07-15 { description "This revision adds the following new data types: - yang:yang-identifier - yang:hex-string - yang:uuid - yang:dotted-quad"; reference "RFC 6991: Common YANG Data Types"; }
4.8 Module Header, Meta, and Revision Statementsrfc9907-4.8-17revision 2010-09-24 { description "Initial revision."; reference "RFC 6021: Common YANG Data Types"; }
4.9 Namespace Assignmentsrfc9907-4.9-1advice, RECOMMENDEDIt is RECOMMENDED that only valid YANG modules be included in documents, whether or not the modules are published yet. This allows:
4.9 Namespace Assignmentsrfc9907-4.9-2* the module to compile correctly instead of generating disruptive fatal errors.
4.9 Namespace Assignmentsrfc9907-4.9-3* early implementors to use the modules without picking a random value for the XML namespace.
4.9 Namespace Assignmentsrfc9907-4.9-4* early interoperability testing since independent implementations will use the same XML namespace value.
4.9 Namespace Assignmentsrfc9907-4.9-5rule, advice, MUST, MUST NOT, SHOULDUntil a URI is assigned by the IANA, a proposed namespace URI MUST be provided for the "namespace" statement in a YANG module. A value SHOULD be selected that is not likely to collide with other YANG namespaces. Standard module names, prefixes, and URI strings already listed in the "YANG Module Names" registry group MUST NOT be used.
4.9 Namespace Assignmentsrfc9907-4.9-6advice, SHOULDA standard "namespace" statement value SHOULD have the following form:
4.9 Namespace Assignmentsrfc9907-4.9-7<URN prefix string>:<module-name>
4.9 Namespace Assignmentsrfc9907-4.9-8advice, SHOULDThe following URN prefix string SHOULD be used for published and unpublished YANG modules:
4.9 Namespace Assignmentsrfc9907-4.9-9urn:ietf:params:xml:ns:yang
4.9 Namespace Assignmentsrfc9907-4.9-10The following example URNs would be valid "namespace" statement values for Standards Track modules:
4.9 Namespace Assignmentsrfc9907-4.9-11urn:ietf:params:xml:ns:yang:ietf-netconf-partial-lock
4.9 Namespace Assignmentsrfc9907-4.9-12urn:ietf:params:xml:ns:yang:ietf-netconf-state
4.9 Namespace Assignmentsrfc9907-4.9-13urn:ietf:params:xml:ns:yang:ietf-netconf
4.9 Namespace Assignmentsrfc9907-4.9-14advice, SHOULDNote that a different URN prefix string SHOULD be used for modules that are not Standards Track. The string SHOULD be selected according to the guidelines in Section 5.3 of [RFC7950].
4.9 Namespace Assignmentsrfc9907-4.9-15advice, SHOULDThe following URIs exemplify what might be used by modules that are not Standards Track. Note that the domain "example.com" SHOULD be used by example modules in I-Ds from the IETF Stream. These URIs are not intended to be dereferenced. They are used for module namespace identification only.
4.9 Namespace Assignmentsrfc9907-4.9-16Example URIs using URLs per [RFC3986]:
4.9 Namespace Assignmentsrfc9907-4.9-17https://example.com/ns/example-interfaces
4.9 Namespace Assignmentsrfc9907-4.9-18https://example.com/ns/example-system
4.9 Namespace Assignmentsrfc9907-4.9-19Example URIs using tags per [RFC4151]:
4.9 Namespace Assignmentsrfc9907-4.9-20tag:example.com,2017:example-interfaces
4.9 Namespace Assignmentsrfc9907-4.9-21tag:example.com,2017:example-system
4.10 Top-Level Data Definitionsrfc9907-4.10-1advice, SHOULDThe top-level data organization SHOULD be considered carefully, in advance. Data model designers need to consider how the functionality for a given protocol or protocol family will grow over time.
4.10 Top-Level Data Definitionsrfc9907-4.10-2advice, SHOULDThe separation of configuration data and operational state SHOULD be considered carefully. It is sometimes useful to define separate top- level containers for configuration and non-configuration data. For some existing top-level data nodes, configuration data was not in scope, so only one container representing operational state was created. Refer to NMDA [RFC8342] for details.
4.10 Top-Level Data Definitionsrfc9907-4.10-3advice, SHOULDThe number of top-level data nodes within a module SHOULD be minimized. It is often useful to retrieve related information within a single subtree. If data is too distributed, it becomes difficult to retrieve all at once.
4.10 Top-Level Data Definitionsrfc9907-4.10-4advice, SHOULD, SHOULD NOTThe names and data organization SHOULD reflect persistent information, such as the name of a protocol. The name of the working group SHOULD NOT be used because this may change over time.
4.10 Top-Level Data Definitionsrfc9907-4.10-5definition, ruleA mandatory database data definition is defined as a node that a client must provide for the database to be valid. The server is not required to provide a value.
4.10 Top-Level Data Definitionsrfc9907-4.10-6rule, MUST NOTTop-level database data definitions MUST NOT be mandatory. If a mandatory node appears at the top level, it will immediately cause the database to be invalid. This can occur when the server boots or when a module is loaded dynamically at runtime.
4.11 Data Typesrfc9907-4.11-1Selection of an appropriate data type (i.e., built-in type, existing derived type, or new derived type) is very subjective; therefore, few requirements can be specified on that subject.
4.11 Data Typesrfc9907-4.11-2advice, SHOULDData model designers SHOULD use the most appropriate built-in data type for the particular application.
4.11 Data Typesrfc9907-4.11-3advice, SHOULD NOTThe signed numeric data types (i.e., "int8", "int16", "int32", and "int64") SHOULD NOT be used unless negative values are allowed for the desired semantics.
4.11.1 Fixed-Value Extensibilityrfc9907-4.11.1-1advice, SHOULDIf the set of values is fixed and the data type contents are controlled by a single naming authority (e.g., IANA), then an "enumeration" data type SHOULD be used.
4.11.1 Fixed-Value Extensibilityrfc9907-4.11.1-2leaf foo { type enumeration { enum one; enum two; } }
4.11.1 Fixed-Value Extensibilityrfc9907-4.11.1-3rule, advice, SHOULDIf distributed extensibility or hierarchical organization of enumerated values is required, then the "identityref" data type SHOULD be used instead of an "enumeration" or other built-in type.
4.11.1 Fixed-Value Extensibilityrfc9907-4.11.1-4identity foo-type { description "Base for the extensible type"; }
4.11.1 Fixed-Value Extensibilityrfc9907-4.11.1-5identity one { base f:foo-type; }
4.11.1 Fixed-Value Extensibilityrfc9907-4.11.1-6identity two { base f:foo-type; }
4.11.1 Fixed-Value Extensibilityrfc9907-4.11.1-7leaf foo { type identityref { base f:foo-type; } }
4.11.1 Fixed-Value Extensibilityrfc9907-4.11.1-8Note that any module can declare an identity with base "foo-type" that is valid for the "foo" leaf. Identityref values are considered to be qualified names.
4.11.2 Patterns and Rangesrfc9907-4.11.2-1advice, SHOULDFor string data types, if a machine-readable pattern can be defined for the desired semantics, then one or more pattern statements SHOULD be present. A single-quoted string SHOULD be used to specify the pattern, since a double-quoted string can modify the content. If the patterns used in a type definition have known limitations such as false negative or false positive matches, then these limitations SHOULD be documented within the typedef or data definition.
4.11.2 Patterns and Rangesrfc9907-4.11.2-2The following typedef from [RFC9911] demonstrates the proper use of the "pattern" statement:
4.11.2 Patterns and Rangesrfc9907-4.11.2-3typedef ipv6-address-no-zone { type inet:ipv6-address { pattern '[0-9a-fA-F:\.]*'; } ... }
4.11.2 Patterns and Rangesrfc9907-4.11.2-4rule, MUSTFor string data types, if the length of the string is required to be bounded in all implementations, then a "length" statement MUST be present.
4.11.2 Patterns and Rangesrfc9907-4.11.2-5The following typedef from [RFC9911] demonstrates the proper use of the "length" statement:
4.11.2 Patterns and Rangesrfc9907-4.11.2-6typedef yang-identifier { type string { length "1..max"; pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; } ... }
4.11.2 Patterns and Rangesrfc9907-4.11.2-7advice, SHOULDFor numeric data types, if the values allowed by the intended semantics are different than those allowed by the unbounded intrinsic data type (e.g., "int32"), then a range statement SHOULD be present.
4.11.2 Patterns and Rangesrfc9907-4.11.2-8The following typedef from [RFC9911] demonstrates the proper use of the "range" statement:
4.11.2 Patterns and Rangesrfc9907-4.11.2-9typedef dscp { type uint8 { range "0..63"; } ... }
4.11.3 Enumerations and Bitsrfc9907-4.11.3-1advice, SHOULDFor "enumeration" or "bits" data types, the semantics for each "enum" or "bit" SHOULD be documented. A separate "description" statement (within each "enum" or "bit" statement) SHOULD be present.
4.11.3 Enumerations and Bitsrfc9907-4.11.3-2leaf foo { // INCORRECT type enumeration { enum one; enum two; } description "The foo enum... one: The first enum two: The second enum"; } leaf foo { // CORRECT type enumeration { enum one { description "The first enum"; } enum two { description "The second enum"; } } description "The foo enum... "; }
4.11.4 Union Typesrfc9907-4.11.4-1definition, advice, SHOULDThe YANG "union" type is evaluated by testing a value against each member type in the union. The first type definition that accepts a value as valid is the member type used. In general, member types SHOULD be ordered from most restrictive to least restrictive types.
4.11.4 Union Typesrfc9907-4.11.4-2In the following example, the "enumeration" type will never be matched because the preceding "string" type will match everything.
4.11.4 Union Typesrfc9907-4.11.4-3Incorrect:
4.11.4 Union Typesrfc9907-4.11.4-4type union { type string; type enumeration { enum up; enum down; } }
4.11.4 Union Typesrfc9907-4.11.4-5Correct:
4.11.4 Union Typesrfc9907-4.11.4-6type union { type enumeration { enum up; enum down; } type string; }
4.11.4 Union Typesrfc9907-4.11.4-7It is possible for different member types to match, depending on the input encoding format. In XML, all values are passed as string nodes; but in JSON, there are different value types for numbers, booleans, and strings.
4.11.4 Union Typesrfc9907-4.11.4-8In the following example, a JSON numeric value will always be matched by the "int32" type, but in XML the string value representing a number will be matched by the "string" type. The second version will match the "int32" member type no matter how the input is encoded.
4.11.4 Union Typesrfc9907-4.11.4-9Incorrect:
4.11.4 Union Typesrfc9907-4.11.4-10type union { type string; type int32; }
4.11.4 Union Typesrfc9907-4.11.4-11Correct:
4.11.4 Union Typesrfc9907-4.11.4-12type union { type int32; type string; }
4.11.5 Empty and Booleanrfc9907-4.11.5-1rule, advice, SHOULD NOTYANG provides an "empty" data type, which has one value (i.e., present). The default is "not present", which is not actually a value. When used within a list key, only one value can (and must) exist for this key leaf. The type "empty" SHOULD NOT be used for a key leaf since it is pointless.
4.11.5 Empty and Booleanrfc9907-4.11.5-2advice, SHOULD NOTThere is really no difference between a leaf of type "empty" and a leaf-list of type "empty". Both are limited to one instance. The type "empty" SHOULD NOT be used for a leaf-list.
4.11.5 Empty and Booleanrfc9907-4.11.5-3The advantage of using type "empty" instead of type "boolean" is that the default (not present) does not take up any bytes in a representation. The disadvantage is that the client may not be sure if an empty leaf is missing because it was filtered somehow or not implemented. The client may not have a complete and accurate schema for the data returned by the server and may not be aware of the missing leaf.
4.11.5 Empty and Booleanrfc9907-4.11.5-4The YANG "boolean" data type provides two values ("true" and "false"). When used within a list key, two entries can exist for this key leaf. Default values are ignored for key leafs, but a default statement is often used for plain boolean leafs. The advantage of the "boolean" type is that the leaf or leaf-list has a clear representation for both values. The default value is usually not returned unless explicitly requested by the client, so no bytes are used in a typical representation.
4.11.5 Empty and Booleanrfc9907-4.11.5-5advice, SHOULDIn general, the "boolean" data type SHOULD be used instead of the "empty" data type, as shown in the example below:
4.11.5 Empty and Booleanrfc9907-4.11.5-6Incorrect:
4.11.5 Empty and Booleanrfc9907-4.11.5-7leaf flag1 { type empty; }
4.11.5 Empty and Booleanrfc9907-4.11.5-8Correct:
4.11.5 Empty and Booleanrfc9907-4.11.5-9leaf flag2 { type boolean; default false; }
4.12 Reusable Type Definitionsrfc9907-4.12-1advice, SHOULDIf an appropriate derived type exists in any standard module, such as [RFC9911], then it SHOULD be used instead of defining a new derived type.
4.12 Reusable Type Definitionsrfc9907-4.12-2advice, SHOULDIf an appropriate units identifier can be associated with the desired semantics, then a units statement SHOULD be present.
4.12 Reusable Type Definitionsrfc9907-4.12-3advice, SHOULDIf an appropriate default value can be associated with the desired semantics, then a default statement SHOULD be present.
4.12 Reusable Type Definitionsrfc9907-4.12-4advice, SHOULDIf a significant number of derived types are defined, and it is anticipated that these data types will be reused by multiple modules, then these derived types SHOULD be contained in a separate module or submodule to allow easier reuse without unnecessary coupling.
4.12 Reusable Type Definitionsrfc9907-4.12-5rule, MUSTThe "description" statement MUST be present.
4.12 Reusable Type Definitionsrfc9907-4.12-6rule, MUSTIf the type definition semantics are defined in an external document (other than another YANG module indicated by an "import" statement), then the "reference" statement MUST be present.
4.13 Reusable Groupingsrfc9907-4.13-1definitionA reusable grouping is a YANG grouping that can be imported by another module and is intended for use by other modules. This is not the same as a grouping that is used within the module in which it is defined, but it happens to be exportable to another module because it is defined at the top level of the YANG module.
4.13 Reusable Groupingsrfc9907-4.13-2The following guidelines apply to reusable groupings, in order to make them as robust as possible:
4.13 Reusable Groupingsrfc9907-4.13-3* Clearly identify the purpose of the grouping in the "description" statement.
4.13 Reusable Groupingsrfc9907-4.13-4* There are five different XPath contexts in YANG (rpc/input, rpc/ output, notification, "config true" data nodes, and all data nodes). Clearly identify which XPath contexts are applicable or excluded for the grouping.
4.13 Reusable Groupingsrfc9907-4.13-5rule* Do not reference data outside the grouping in any "path", "must", or "when" statements.
4.13 Reusable Groupingsrfc9907-4.13-6* Do not include a "default" substatement on a leaf or choice unless the value applies on all possible contexts.
4.13 Reusable Groupingsrfc9907-4.13-7* Do not include a "config" substatement on a data node unless the value applies on all possible contexts.
4.13 Reusable Groupingsrfc9907-4.13-8rule* Clearly identify any external dependencies in the grouping "description" statement, such as nodes referenced by an absolute path from a "path", "must", or "when" statement.
4.14 Data Definitionsrfc9907-4.14-1rule, MUSTThe "description" statement MUST be present in the following YANG statements:
4.14 Data Definitionsrfc9907-4.14-2* anydata
4.14 Data Definitionsrfc9907-4.14-3* anyxml
4.14 Data Definitionsrfc9907-4.14-4* augment
4.14 Data Definitionsrfc9907-4.14-5* choice
4.14 Data Definitionsrfc9907-4.14-6* container
4.14 Data Definitionsrfc9907-4.14-7* extension
4.14 Data Definitionsrfc9907-4.14-8* feature
4.14 Data Definitionsrfc9907-4.14-9* grouping
4.14 Data Definitionsrfc9907-4.14-10* identity
4.14 Data Definitionsrfc9907-4.14-11* leaf
4.14 Data Definitionsrfc9907-4.14-12* leaf-list
4.14 Data Definitionsrfc9907-4.14-13* list
4.14 Data Definitionsrfc9907-4.14-14* notification
4.14 Data Definitionsrfc9907-4.14-15* rpc
4.14 Data Definitionsrfc9907-4.14-16* typedef
4.14 Data Definitionsrfc9907-4.14-17rule, MUSTIf the data definition semantics are defined in an external document, (other than another YANG module indicated by an "import" statement), then a "reference" statement MUST be present.
4.14 Data Definitionsrfc9907-4.14-18advice, permission, MAY, SHOULD NOTThe "anyxml" construct may be useful to represent an HTML banner containing markup elements, such as "<b>" and "</b>", and MAY be used in such cases. However, this construct SHOULD NOT be used if other YANG data node types can be used instead to represent the desired syntax and semantics.
4.14 Data Definitionsrfc9907-4.14-19It has been found that the "anyxml" statement is not implemented consistently across all servers. It is possible that mixed-mode XML will not be supported or that configuration anyxml nodes will not be supported.
4.14 Data Definitionsrfc9907-4.14-20rule, advice, SHOULDIf there are referential integrity constraints associated with the desired semantics that can be represented with XPath, then one or more "must" statements SHOULD be present.
4.14 Data Definitionsrfc9907-4.14-21rule, advice, SHOULDFor list and leaf-list data definitions, if the number of possible instances is required to be bounded for all implementations, then the max-elements statements SHOULD be present.
4.14 Data Definitionsrfc9907-4.14-22rule, advice, SHOULDIf any "must" or "when" statements are used within the data definition, then the data definition "description" statement SHOULD describe the purpose of each one.
4.14 Data Definitionsrfc9907-4.14-23The "choice" statement is allowed to be directly present within a "case" statement in YANG 1.1. This needs to be considered carefully. Consider simply including the nested "choice" as additional "case" statements within the parent "choice" statement. Note that the "mandatory" and "default" statements within a nested "choice" statement only apply if the "case" containing the nested "choice" statement is first selected.
4.14 Data Definitionsrfc9907-4.14-24advice, permission, MAY, SHOULDIf a list defines any key leafs, then these leafs SHOULD be defined in order, as the first child nodes within the list. The key leafs MAY be in a different order in some cases, e.g., they are defined in a grouping, and not inline in the list statement.
4.14.1 Non-Presence Containersrfc9907-4.14.1-1definition, ruleA non-presence container is used to organize data into specific subtrees. It is not intended to have semantics within the data model beyond this purpose, although YANG allows it (e.g., a "must" statement within the non-presence container).
4.14.1 Non-Presence Containersrfc9907-4.14.1-2Example using container wrappers:
4.14.1 Non-Presence Containersrfc9907-4.14.1-3container top { container foos { list foo { ... } } container bars { list bar { ... } } }
4.14.1 Non-Presence Containersrfc9907-4.14.1-4Example without container wrappers:
4.14.1 Non-Presence Containersrfc9907-4.14.1-5container top { list foo { ... } list bar { ... } }
4.14.1 Non-Presence Containersrfc9907-4.14.1-6definition, advice, SHOULDUse of non-presence containers to organize data is a subjective matter similar to use of subdirectories in a file system. Although these containers do not have any semantics, they can impact protocol operations for the descendant data nodes within a non-presence container, so use of these containers SHOULD be considered carefully.
4.14.1 Non-Presence Containersrfc9907-4.14.1-7The NETCONF and RESTCONF protocols do not currently support the ability to delete all list (or leaf-list) entries at once. This deficiency is sometimes avoided by use of a parent container (i.e., deleting the container also removes all child entries).
4.14.2 Top-Level Data Nodesrfc9907-4.14.2-1Use of top-level objects needs to be considered carefully:
4.14.2 Top-Level Data Nodesrfc9907-4.14.2-2* top-level siblings are not ordered
4.14.2 Top-Level Data Nodesrfc9907-4.14.2-3* top-level siblings are not static and depend on the modules that are loaded
4.14.2 Top-Level Data Nodesrfc9907-4.14.2-4* for subtree filtering, retrieval of a top-level leaf-list will be treated as a content-match node for all top-level-siblings
4.14.2 Top-Level Data Nodesrfc9907-4.14.2-5* a top-level list with many instances may impact performance
4.15 Operation Definitionsrfc9907-4.15-1rule, MUSTIf the operation semantics are defined in an external document (other than another YANG module indicated by an "import" statement), then a "reference" statement MUST be present.
4.15 Operation Definitionsrfc9907-4.15-2advice, SHOULDIf the operation impacts system behavior in some way, it SHOULD be mentioned in the "description" statement.
4.15 Operation Definitionsrfc9907-4.15-3rule, MUSTIf the operation is potentially harmful to system behavior in some way, it MUST be mentioned in the Security Considerations section of the document.
4.16 Notification Definitionsrfc9907-4.16-1rule, MUSTThe "description" statement MUST be present.
4.16 Notification Definitionsrfc9907-4.16-2rule, MUSTIf the notification semantics are defined in an external document (other than another YANG module indicated by an "import" statement), then a "reference" statement MUST be present.
4.16 Notification Definitionsrfc9907-4.16-3definition, advice, SHOULDIf the notification refers to a specific resource instance, then this instance SHOULD be identified in the notification data. This is usually done by including "leafref" leaf nodes with the key leaf values for the resource instance. For example:
4.16 Notification Definitionsrfc9907-4.16-4notification interface-up { description "Sent when an interface is activated."; leaf name { type leafref { path "/if:interfaces/if:interface/if:name"; } } }
4.16 Notification Definitionsrfc9907-4.16-5advice, SHOULDNote that there are no formal YANG statements to identify any data node resources associated with a notification. The "description" statement for the notification SHOULD specify if and how the notification identifies any data node resources associated with the specific event.
4.17 Feature Definitionsrfc9907-4.17-1definition, rule, MUSTThe YANG "feature" statement is used to define a label for a set of optional functionality within a module. The "if-feature" statement is used in the YANG statements associated with a feature. The description-stmt within a feature-stmt MUST specify any interactions with other features.
4.17 Feature Definitionsrfc9907-4.17-2definition, adviceThe set of YANG features defined in a module should be considered carefully. Very fine granular features increase interoperability complexity and should be avoided. A likely misuse of the feature mechanism is the tagging of individual leafs (e.g., counters) with separate features.
4.17 Feature Definitionsrfc9907-4.17-3definitionIf there is a large set of objects associated with a YANG feature, then consider moving those objects to a separate module instead of using a YANG feature. Note that the set of features within a module is easily discovered by the reader, but the set of related modules within the entire YANG library is not as easy to identify. Module names with a common prefix can help readers identify the set of related modules, but this assumes the reader will have discovered and installed all the relevant modules.
4.17 Feature Definitionsrfc9907-4.17-4definitionAnother consideration for deciding whether to create a new module or add a YANG feature is the stability of the module in question. It may be desirable to have a stable base module that is not changed frequently. If new functionality is placed in a separate module, then the base module does not need to be republished. If it is designed as a YANG feature, then the module will need to be republished.
4.17 Feature Definitionsrfc9907-4.17-5advice, SHOULDIf one feature requires implementation of another feature, then an "if-feature" statement SHOULD be used in the dependent "feature" statement.
4.17 Feature Definitionsrfc9907-4.17-6For example, feature2 requires implementation of feature1:
4.17 Feature Definitionsrfc9907-4.17-7feature feature1 { description "Some protocol feature"; }
4.17 Feature Definitionsrfc9907-4.17-8feature feature2 { if-feature "feature1"; description "Another protocol feature"; }
4.18.1 Controlling Quantityrfc9907-4.18.1-1rule, advice, SHOULDThe "min-elements" and "max-elements" statements can be used to control how many list or leaf-list instances are required for a particular data node. YANG constraint statements SHOULD be used to identify conditions that apply to all implementations of the data model. If platform-specific limitations (e.g., the "max-elements" supported for a particular list) are relevant to operations, then a data model definition statement (e.g., "max-ports" leaf) SHOULD be used to identify the limit.
4.18.2 "must" versus "when"rfc9907-4.18.2-1definition, rule"must" and "when" YANG statements are used to provide cross-object referential tests. They have very different behavior. The "when" statement causes data node instances to be silently deleted as soon as the condition becomes false. A false "when" statement is not considered to be an error.
4.18.2 "must" versus "when"rfc9907-4.18.2-2advice, SHOULDThe "when" statement SHOULD be used together with "augment" or "uses" statements to achieve conditional model composition. The condition SHOULD be based on static properties of the augmented entry (e.g., list key leafs).
4.18.2 "must" versus "when"rfc9907-4.18.2-3rule, advice, SHOULDThe "must" statement causes a datastore validation error if the condition is false. This statement SHOULD be used for enforcing parameter value restrictions that involve more than one data node (e.g., end-time parameter must be after the start-time parameter).
4.19 "augment" Statementsrfc9907-4.19-1definitionThe YANG "augment" statement is used to define a set of data definition statements that will be added as child nodes of a target data node. The module namespace for these data nodes will be the augmenting module, not the augmented module.
4.19 "augment" Statementsrfc9907-4.19-2advice, SHOULD, SHOULD NOTA top-level "augment" statement SHOULD NOT be used if the target data node is in the same module or submodule as the evaluated "augment" statement. The data definition statements SHOULD be added inline instead.
4.19.1 Conditional Augment Statementsrfc9907-4.19.1-1The "augment" statement is often used together with the "when" statement and/or "if-feature" statement to make the augmentation conditional on some portion of the data model.
4.19.1 Conditional Augment Statementsrfc9907-4.19.1-2The following example from [RFC8343] shows how a conditional container called "ethernet" is added to the "interface" list only for entries of the type "ethernetCsmacd".
4.19.1 Conditional Augment Statementsrfc9907-4.19.1-3augment "/if:interfaces/if:interface" { when "if:type = 'ianaift:ethernetCsmacd'";
4.19.1 Conditional Augment Statementsrfc9907-4.19.1-4container ethernet { leaf duplex { ... } } }
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-1YANG has very specific rules about how configuration data can be updated in new releases of a module. These rules allow an "old client" to continue interoperating with a "new server".
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-2rule, MUST NOTIf data nodes are added to an existing entry, the old client MUST NOT be required to provide any mandatory parameters that were not in the original module definition.
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-3It is possible to add conditional "augment" statements such that the old client would not know about the new condition and would not specify the new condition. The conditional "augment" statement can contain mandatory objects only if the condition is false, unless explicitly requested by the client.
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-4Only a conditional "augment" statement that uses the "when" statement form of a condition can be used in this manner. The YANG features enabled on the server cannot be controlled by the client in any way, so it is not safe to add mandatory augmenting data nodes based on the "if-feature" statement.
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-5rule, MUST NOTThe XPath "when" statement condition MUST NOT reference data outside of the target data node because the client does not have any control over this external data.
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-6In the following sample, it is okay to augment the "interface" entry with "mandatory-leaf" because the augmentation depends on support for "some-new-iftype". The old client does not know about this type, so it would never select this type; therefore, it would not add a mandatory data node.
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-7module example-module {
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-8yang-version 1.1; namespace "tag:example.com,2017:example-module"; prefix mymod;
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-9import iana-if-type { prefix iana; } import ietf-interfaces { prefix if; }
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-10identity some-new-iftype { base iana:iana-interface-type; }
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-11augment "/if:interfaces/if:interface" { when "if:type = 'mymod:some-new-iftype'";
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-12leaf mandatory-leaf { type string; mandatory true; } } }
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-13rule, MUSTNote that this practice is safe only for creating data resources. It is not safe for replacing or modifying resources if the client does not know about the new condition. The YANG data model MUST be packaged in a way that requires the client to be aware of the mandatory data nodes if it is aware of the condition for this data. In the example above, the "some-new-iftype" identity is defined in the same module as the "mandatory-leaf" data definition statement.
4.19.2 Conditionally Mandatory Data Definition Statementsrfc9907-4.19.2-14ruleThis practice is not safe for identities defined in a common module such as "iana-if-type" because the client is not required to know about "my-module" just because it knows about the "iana-if-type" module.
4.20 Deviation Statementsrfc9907-4.20-1Per Section 7.20.3 of [RFC7950], the YANG "deviation" statement is not allowed to appear in IETF YANG modules, but it can be useful for documenting server capabilities. Deviation statements are not reusable and typically not shared across all platforms.
4.20 Deviation Statementsrfc9907-4.20-2There are several reasons that deviations might be needed in an implementation, e.g., an object cannot be supported on all platforms, or feature delivery is done in multiple development phases. Deviation statements can also be used to add annotations to a module, which does not affect the conformance requirements for the module.
4.20 Deviation Statementsrfc9907-4.20-3adviceIt is suggested that deviation statements be defined in separate modules from regular YANG definitions. This allows the deviations to be platform specific and/or temporary.
4.20 Deviation Statementsrfc9907-4.20-4advice, SHOULD NOTThe order that deviation statements are evaluated can affect the result. Therefore, multiple deviation statements in the same module, for the same target object, SHOULD NOT be used.
4.20 Deviation Statementsrfc9907-4.20-5The "max-elements" statement is intended to describe an architectural limit to the number of list entries. It is not intended to describe platform limitations. It is better to use a "deviation" statement for the platforms that have a hard resource limit.
4.20 Deviation Statementsrfc9907-4.20-6Example documenting platform resource limits:
4.20 Deviation Statementsrfc9907-4.20-7Wrong: (max-elements in the list itself)
4.20 Deviation Statementsrfc9907-4.20-8container backups { list backup { ... max-elements 10; ... } }
4.20 Deviation Statementsrfc9907-4.20-9Correct: (max-elements in a deviation)
4.20 Deviation Statementsrfc9907-4.20-10deviation /bk:backups/bk:backup { deviate add { max-elements 10; } }
4.21 Extension Statementsrfc9907-4.21-1definitionThe YANG "extension" statement is used to specify external definitions. This appears in the YANG syntax as an "unknown- statement". Usage of "extension" statements in a published module needs to be considered carefully.
4.21 Extension Statementsrfc9907-4.21-2The following guidelines apply to the usage of YANG extensions:
4.21 Extension Statementsrfc9907-4.21-3rule, MUST NOT* The semantics of the extension MUST NOT contradict any YANG statements. Extensions can add semantics not covered by the normal YANG statements.
4.21 Extension Statementsrfc9907-4.21-4rule, advice, MUST* The module containing the "extension" statement MUST clearly identify the conformance requirements for the extension. It should be clear whether all implementations of the YANG module containing the extension need to also implement the extension. If not, identify what conditions apply that would require implementation of the extension.
4.21 Extension Statementsrfc9907-4.21-5rule, MUST* The extension MUST clearly identify where it can be used within other YANG statements.
4.21 Extension Statementsrfc9907-4.21-6rule, MUST* The extension MUST clearly identify if YANG statements or other extensions are allowed or required within the extension as substatements.
4.22 Data Correlationrfc9907-4.22-1Data can be correlated in various ways, using common data types, common data naming, and common data organization. There are several ways to extend the functionality of a module, based on the degree of coupling between the old and new functionality:
4.22 Data Correlationrfc9907-4.22-2inline: update the module with new protocol-accessible objects. The naming and data organization of the original objects is used. The new objects are in the original module namespace.
4.22 Data Correlationrfc9907-4.22-3augment: create a new module with new protocol-accessible objects that augment the original data structure. The naming and data organization of the original objects is used. The new objects are in the new module namespace.
4.22 Data Correlationrfc9907-4.22-4advice, SHOULDmirror: create new objects in a new module or the original module, except use a new naming scheme and data location. The naming can be coupled in different ways. Tight coupling is achieved with a "leafref" data type, with the "require-instance" substatement set to "true". This method SHOULD be used.
4.22 Data Correlationrfc9907-4.22-5rule, MUSTIf the new data instances are not limited to the values in use in the original data structure, then the "require-instance" substatement MUST be set to "false". Loose coupling is achieved by using key leafs with the same data type as the original data structure. This has the same semantics as setting the "require-instance" substatement to "false".
4.22 Data Correlationrfc9907-4.22-6The relationship between configuration and operational state has been clarified in NMDA [RFC8342].
4.22.1 Use of "leafref" for Key Correlationrfc9907-4.22.1-1Sometimes it is not practical to augment a data structure. For example, the correlated data could have different keys or contain mandatory nodes.
4.22.1 Use of "leafref" for Key Correlationrfc9907-4.22.1-2The following example shows the use of the "leafref" data type for data correlation purposes:
4.22.1 Use of "leafref" for Key Correlationrfc9907-4.22.1-3Not preferred:
4.22.1 Use of "leafref" for Key Correlationrfc9907-4.22.1-4list foo { key name; leaf name { type string; } ... }
4.22.1 Use of "leafref" for Key Correlationrfc9907-4.22.1-5list foo-addon { key name; config false; leaf name { type string; } ... }
4.22.1 Use of "leafref" for Key Correlationrfc9907-4.22.1-6Preferred:
4.22.1 Use of "leafref" for Key Correlationrfc9907-4.22.1-7list foo { key name; leaf name { type string; } ... }
4.22.1 Use of "leafref" for Key Correlationrfc9907-4.22.1-8list foo-addon { key name; config false; leaf name { type leafref { path "/foo/name"; require-instance false; } } leaf addon { type string; mandatory true; } }
4.23 Operational Staterfc9907-4.23-1The modeling of operational state with YANG has been refined over time. At first, only data that has a "config" statement value of "false" was considered to be operational state. This data was not considered to be part of any datastore, which made the YANG XPath definition much more complicated.
4.23 Operational Staterfc9907-4.23-2Operational state is now modeled using YANG according to the NMDA [RFC8342] and conceptually contained in the operational state datastore, which also includes the operational values of configuration data. There is no longer any need to duplicate data structures to provide separate configuration and operational state sections.
4.23 Operational Staterfc9907-4.23-3This section describes some data modeling issues related to operational state and guidelines for transitioning YANG data model design to be NMDA compatible.
4.23.1 Combining Operational State and Configuration Datarfc9907-4.23.1-1advice, SHOULDIf possible, operational state SHOULD be combined with its associated configuration data. This prevents duplication of key leafs and ancestor nodes. It also prevents race conditions for retrieval of dynamic entries and allows configuration and operational state to be retrieved together with minimal message overhead.
4.23.1 Combining Operational State and Configuration Datarfc9907-4.23.1-2container foo { ... // contains "config true" and "config false" nodes that have // no corresponding "config true" object (e.g., counters) }
4.23.2 Representing Operational Values of Configuration Datarfc9907-4.23.2-1advice, SHOULDIf possible, the same data type SHOULD be used to represent the configured value and the operational value, for a given leaf or leaf- list object.
4.23.2 Representing Operational Values of Configuration Datarfc9907-4.23.2-2permission, MAYSometimes the configured value set is different than the operational value set for that object, for example, the "admin-status" and "oper- status" leafs in [RFC8343]. In this case, a separate object MAY be used to represent the configured and operational values.
4.23.2 Representing Operational Values of Configuration Datarfc9907-4.23.2-3permission, MAYSometimes the list keys are not identical for configuration data and the corresponding operational state. In this case, separate lists MAY be used to represent the configured and operational values.
4.23.2 Representing Operational Values of Configuration Datarfc9907-4.23.2-4advice, permission, MAY, SHOULDIf it is not possible to combine configuration and operational state, then the keys used to represent list entries SHOULD be the same type. The "leafref" data type SHOULD be used in operational state for key leafs that have corresponding configuration instances. The "require- instance" statement MAY be set to "false" (in YANG 1.1 modules only) to indicate instances are allowed in the operational state that do not exist in the associated configuration data.
4.23.2 Representing Operational Values of Configuration Datarfc9907-4.23.2-5The need to replicate objects or define different operational state objects depends on the data model. It is not possible to define one approach that will be optimal for all data models.
4.23.2 Representing Operational Values of Configuration Datarfc9907-4.23.2-6advice, SHOULDDesigners SHOULD describe and justify any NMDA exceptions in detail, such as the use of separate subtrees and/or separate leafs. The "description" statements for both the configuration and the operational state SHOULD be used for this purpose.
4.23.3 NMDA Transition Guidelinesrfc9907-4.23.3-1advice, SHOULD, SHOULD NOTYANG modules SHOULD be designed with the assumption that they will be used on servers supporting the operational state datastore. With this in mind, YANG modules SHOULD define "config false" nodes wherever they make sense to the data model. "Config false" nodes SHOULD NOT be defined to provide the operational value for configuration nodes, except when the value space of a configured and operational value may differ, in which case a distinct "config false" node SHOULD be defined to hold the operational value for the configured node.
4.23.3 NMDA Transition Guidelinesrfc9907-4.23.3-2The following guidelines are meant to help modelers develop YANG modules that will maximize the utility of the module with both current and new implementations.
4.23.3 NMDA Transition Guidelinesrfc9907-4.23.3-3advice, permission, MAY, SHOULDNew modules and modules that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA compatible, as described in Section 4.23.1. This transition MAY be deferred if the module does not contain any configuration datastore objects.
4.23.3 NMDA Transition Guidelinesrfc9907-4.23.3-4permission, MAYThe remaining are options that MAY be followed during the time that NMDA mechanisms are being defined.
4.23.3 NMDA Transition Guidelinesrfc9907-4.23.3-5advice, permission, MAY, SHOULD(a) Modules that require immediate support for the NMDA features SHOULD be structured for NMDA. A temporary non-NMDA version of this type of module MAY exist, as either an existing module or a module created by hand or with suitable tools that mirror the current modeling strategies. Both the NMDA and the non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in a non-normative appendix. The use of the non-NMDA module will allow temporary bridging of the time period until NMDA implementations are available.
4.23.3 NMDA Transition Guidelinesrfc9907-4.23.3-6advice(b) For published modules, the module should be republished with an NMDA-compatible structure, deprecating non-NMDA constructs. For example, the "ietf-interfaces" module in [RFC7223] has been restructured as an NMDA-compatible module in [RFC8343] (which obsoletes [RFC7223]). The "/interfaces-state" hierarchy has been marked with "status deprecated". Modules that mark their "/foo-state" hierarchy with "status deprecated" will allow NMDA- capable implementations to avoid the cost of duplicating the state nodes, while enabling non-NMDA-capable implementations to utilize them for access to the operational values.
4.23.3 NMDA Transition Guidelinesrfc9907-4.23.3-7advice, RECOMMENDED, SHOULD(c) For modules that augment modules that have not been structured with the NMDA, the modeler will have to consider the structure of the base module and the guidelines listed above. Where possible, such modules should move to new revisions of the base module that are NMDA compatible. When that is not possible, augmenting "state" containers SHOULD be avoided, with the expectation that the base module will be re-released with the state containers marked as "deprecated". It is RECOMMENDED to augment only the "/foo" hierarchy of the base module. Where this recommendation cannot be followed, any new "state" elements SHOULD be included in their own module.
4.23.3.1 Temporary Non-NMDA Modulesrfc9907-4.23.3.1-1A temporary non-NMDA module allows a non-NMDA-aware client to access operational state from an NMDA-compliant server. It contains the top-level "config false" data nodes that would have been defined in a legacy YANG module (before NMDA).
4.23.3.1 Temporary Non-NMDA Modulesrfc9907-4.23.3.1-2A server that needs to support both NMDA and non-NMDA clients can advertise both the new NMDA module and the temporary non-NMDA module. A non-NMDA client can use separate "foo" and "foo-state" subtrees, except the "foo-state" subtree is located in a different (temporary) module. The NMDA module can be used by a non-NMDA client to access the conventional configuration datastores and the deprecated <get> operation to access nested "config false" data nodes.
4.23.3.1 Temporary Non-NMDA Modulesrfc9907-4.23.3.1-3To create the temporary non-NMDA module from an NMDA module, the following steps can be taken:
4.23.3.1 Temporary Non-NMDA Modulesrfc9907-4.23.3.1-4* Change the module name by appending "-state" to the original module name.
4.23.3.1 Temporary Non-NMDA Modulesrfc9907-4.23.3.1-5* Change the namespace by appending "-state" to the original namespace value.
4.23.3.1 Temporary Non-NMDA Modulesrfc9907-4.23.3.1-6* Change the prefix by appending "-s" to the original prefix value.
4.23.3.1 Temporary Non-NMDA Modulesrfc9907-4.23.3.1-7* Add an import to the original module (e.g., for typedef definitions).
4.23.3.1 Temporary Non-NMDA Modulesrfc9907-4.23.3.1-8* Retain or create only the top-level nodes that have a "config" statement value "false". These subtrees represent "config false" data nodes that were combined into the configuration subtree; therefore, they are not available to non-NMDA-aware clients. Set the "status" statement to "deprecated" for each new node.
4.23.3.1 Temporary Non-NMDA Modulesrfc9907-4.23.3.1-9advice, SHOULD* The module description SHOULD clearly identify the module as a temporary non-NMDA module.
4.23.3.2 Example: Create a New NMDA Modulerfc9907-4.23.3.2-1Create an NMDA-compliant module, using combined configuration and state subtrees, whenever possible.
4.23.3.2 Example: Create a New NMDA Modulerfc9907-4.23.3.2-2module example-foo { namespace "urn:example:params:xml:ns:yang:example-foo"; prefix "foo";
4.23.3.2 Example: Create a New NMDA Modulerfc9907-4.23.3.2-3container foo { // configuration data child nodes // operational value in operational state datastore only // may contain "config false" nodes as needed } }
4.23.3.3 Example: Convert an Old Non-NMDA Modulerfc9907-4.23.3.3-1MAYDo not remove non-compliant objects from existing modules. Instead, change the status to "deprecated". At some point, usually after 1 year, the status MAY be changed to "obsolete".
4.23.3.3 Example: Convert an Old Non-NMDA Modulerfc9907-4.23.3.3-2Old Module:
4.23.3.3 Example: Convert an Old Non-NMDA Modulerfc9907-4.23.3.3-3module example-foo { namespace "urn:example:params:xml:ns:yang:example-foo"; prefix "foo";
4.23.3.3 Example: Convert an Old Non-NMDA Modulerfc9907-4.23.3.3-4container foo { // configuration data child nodes }
4.23.3.3 Example: Convert an Old Non-NMDA Modulerfc9907-4.23.3.3-5container foo-state { config false; // operational state child nodes } }
4.23.3.3 Example: Convert an Old Non-NMDA Modulerfc9907-4.23.3.3-6Converted NMDA Module:
4.23.3.3 Example: Convert an Old Non-NMDA Modulerfc9907-4.23.3.3-7module example-foo { namespace "urn:example:params:xml:ns:yang:example-foo"; prefix "foo";
4.23.3.3 Example: Convert an Old Non-NMDA Modulerfc9907-4.23.3.3-8container foo { // configuration data child nodes // operational value in operational state datastore only // may contain "config false" nodes as needed // will contain any data nodes from old foo-state }
4.23.3.3 Example: Convert an Old Non-NMDA Modulerfc9907-4.23.3.3-9// keep original foo-state but change status to deprecated container foo-state { config false; status deprecated; // operational state child nodes } }
4.23.3.4 Example: Create a Temporary NMDA Modulerfc9907-4.23.3.4-1Create a new module that contains the top-level operational state data nodes that would have been available before they were combined with configuration data nodes (to be NMDA compliant).
4.23.3.4 Example: Create a Temporary NMDA Modulerfc9907-4.23.3.4-2module example-foo-state { namespace "urn:example:params:xml:ns:yang:example-foo-state"; prefix "foo-s";
4.23.3.4 Example: Create a Temporary NMDA Modulerfc9907-4.23.3.4-3// import new or converted module; not used in this example import example-foo { prefix foo; }
4.23.3.4 Example: Create a Temporary NMDA Modulerfc9907-4.23.3.4-4container foo-state { config false; status deprecated; // operational state child nodes } }
4.24 Performance Considerationsrfc9907-4.24-1permission, MAYIt is generally likely that certain YANG statements require more runtime resources than other statements. Although there are no performance requirements for YANG validation, the following information MAY be considered when designing YANG data models:
4.24 Performance Considerationsrfc9907-4.24-2* Lists are generally more expensive than containers
4.24 Performance Considerationsrfc9907-4.24-3* "when" statement evaluation is generally more expensive than "if- feature" or "choice" statements
4.24 Performance Considerationsrfc9907-4.24-4rule* "must" statements are generally more expensive than "min- elements", "max-elements", "mandatory", or "unique" statements
4.24 Performance Considerationsrfc9907-4.24-5* "identityref" leafs are generally more expensive than "enumeration" leafs
4.24 Performance Considerationsrfc9907-4.24-6* "leafref" and "instance-identifier" types with "require-instance" set to "true" are generally more expensive than if "require- instance" is set to "false"
4.25 Open Systems Considerationsrfc9907-4.25-1permission, MAYOnly the modules imported by a particular module can be assumed to be present in an implementation. An open system MAY include any combination of YANG modules.
4.26 Guidelines for Constructs Specific to YANG 1.1rfc9907-4.26-1The set of guidelines for YANG 1.1 will grow as operational experience is gained with the new language features. This section contains an initial set of guidelines for YANG 1.1 language features.
4.26.1 Importing Multiple Revisionsrfc9907-4.26.1-1advice, permission, MAY, SHOULD NOTStandard modules SHOULD NOT import multiple revisions of the same module into a module. This MAY be done if independent definitions (e.g., "enumeration" typedefs) from specific revisions are needed in the importing module.
4.26.2 Using Feature Logicrfc9907-4.26.2-1advice, SHOULDThe YANG 1.1 feature logic is much more expressive than YANG 1.0. A "description" statement SHOULD describe the "if-feature" logic in text, to help readers understand the module.
4.26.2 Using Feature Logicrfc9907-4.26.2-2advice, SHOULDYANG features SHOULD be used instead of the "when" statement, if possible. Features are advertised by the server, and objects conditional by the "if-feature" statement are conceptually grouped together. There is no such commonality supported for "when" statements.
4.26.2 Using Feature Logicrfc9907-4.26.2-3Features generally require less server implementation complexity and runtime resources than objects that use "when" statements. Features are generally static (i.e., set when a module is loaded and not changed at runtime). However, every client edit might cause a "when" statement result to change.
4.26.3 "anyxml" versus "anydata"rfc9907-4.26.3-1rule, MUST, MUST NOTThe "anyxml" statement MUST NOT be used to represent a conceptual subtree of YANG data nodes. The "anydata" statement MUST be used for this purpose.
4.26.4 "action" versus "rpc"rfc9907-4.26.4-1definition, advice, SHOULDThe use of "action" statements or "rpc" statements is a subjective design decision. RPC operations are not associated with any particular data node. Actions are associated with a specific data node definition. An "action" statement SHOULD be used if the protocol operation is specific to a subset of all data nodes instead of all possible data nodes.
4.26.4 "action" versus "rpc"rfc9907-4.26.4-2advice, permission, MAY, SHOULDThe same action name MAY be used in different definitions within different data node. For example, a "reset" action defined with a data node definition for an interface might have different parameters than for a power supply or a VLAN. The same action name SHOULD be used to represent similar semantics.
4.26.4 "action" versus "rpc"rfc9907-4.26.4-3The NETCONF Access Control Model (NACM) [RFC8341] does not support parameter-based access control for RPC operations. The user is given permission (or not) to invoke the RPC operation with any parameters. For example, if each client is only allowed to reset their own interface, then NACM cannot be used.
4.26.4 "action" versus "rpc"rfc9907-4.26.4-4For example, NACM cannot enforce access control based on the value of the "interface" parameter, only the "reset" operation itself:
4.26.4 "action" versus "rpc"rfc9907-4.26.4-5rpc reset { input { leaf interface { type if:interface-ref; mandatory true; description "The interface to reset."; } } }
4.26.4 "action" versus "rpc"rfc9907-4.26.4-6However, NACM can enforce access control for individual interface instances, using a "reset" action. If the user does not have read access to the specific "interface" instance, then it cannot invoke the "reset" action for that interface instance:
4.26.4 "action" versus "rpc"rfc9907-4.26.4-7container interfaces { list interface { ... action reset { } } }
4.27 Updating YANG Modules (Published versus Unpublished)rfc9907-4.27-1rule, permission, MAY, MUSTYANG modules can change over time. Typically, new data model definitions are needed to support new features. YANG update rules defined in Section 11 of [RFC7950] MUST be followed for published modules. They MAY be followed for unpublished modules.
4.27 Updating YANG Modules (Published versus Unpublished)rfc9907-4.27-2The YANG update rules only apply to published module revisions. Each organization will have their own way to identify published work that is considered to be stable and unpublished work that is considered to be unstable. For example, in the IETF, an RFC is used for published work, and an I-D is used for unpublished work.
4.28 Defining Standard Tagsrfc9907-4.28-1[RFC8819] specifies a method for associating tags with YANG modules. Tags may be defined and associated at design time, at implementation time, or via user administrative control. Design-time tags are indicated using the module-tag "extension" statement.
4.28 Defining Standard Tagsrfc9907-4.28-2permission, MAYA module MAY indicate, using module-tag "extension" statements, a set of tags that are to be automatically associated with it (i.e., not added through configuration).
4.28 Defining Standard Tagsrfc9907-4.28-3module example-module { namespace "https://example.com/yang/example"; prefix "ex"; //... import module-tags { prefix tags; }
4.28 Defining Standard Tagsrfc9907-4.28-4tags:module-tag "ietf:some-new-tag"; tags:module-tag "ietf:some-other-tag"; // ... }
4.28 Defining Standard Tagsrfc9907-4.28-5rule, MUSTAuthors can use existing standard tags or use new tags defined in the model definition, as appropriate. For IETF modules, new tags MUST be assigned in the IANA "IETF YANG Module Tags" registry within the "YANG Module Tags" registry group [IANA-TAGS].
4.29 Modeling Abstract Data Structuresrfc9907-4.29-1definition, advice, RECOMMENDEDFor contexts where YANG is used to model abstract data structures (e.g., protocol messages), the use of the "structure" extension statement [RFC8791] is RECOMMENDED compared to the "yang-data" extension statement [RFC8040]. Examples of modules that rely upon the "structure" extension statement from [RFC8791] can be found in [RFC9132] or [RFC9195].
4.29 Modeling Abstract Data Structuresrfc9907-4.29-2Abstract data structures can be augmented using the "augment- structure" statement [RFC8791]. Examples of modules that augment abstract data structures can be found in [RFC9244] and [RFC9362].

Limitations