Summary

  • draft-fedyk-netmod-yang-normal-form-00 proposes keeping a string's original lexical representation while deriving a deterministic form for equality, list keys and configuration leaf-lists.
  • In its MAC example, colon or hyphen separators and upper- or lower-case hexadecimal digits all reduce to the same 12-digit comparison value. A pattern still decides whether an input is syntactically allowed; it does not make two allowed strings equal.
  • This is an active individual Internet-Draft with no intended RFC status in Datatracker and the IESG state I-D Exists, even though the document header says Intended status: Standards Track. It is not a NETMOD adoption or an IETF endorsement.

The visible string would stop carrying two jobs

Two management systems can mean the same 48-bit address and still send different text. The IETF common YANG type in RFC 6991 and its current RFC 9911 revision uses six colon-separated octets and describes lower case as canonical. The IEEE type shown in IETF discussion material uses hyphens and describes upper case. Today, a string key can preserve those distinctions even when an engineer reads the values as the same address.

The new revision-00 draft proposes splitting presentation from comparison. The received lexical value remains available for encoding and retrieval. An opt-in normalized-form extension points to a deterministic algorithm used by equality, list-key uniqueness and configuration leaf-list uniqueness.

For the draft's mac-48 identity, the steps are narrow: validate the input against its own type, remove separators, convert hexadecimal digits to upper case and use the remaining twelve digits. Thus aa:bb:cc:dd:ee:ff, AA:BB:CC:DD:EE:FF, aa-bb-cc-dd-ee-ff and AA-BB-CC-DD-EE-FF all derive AABBCCDDEEFF. The document displays that identity with a 0x prefix, but the comparison payload is the twelve hexadecimal digits.

That separation matters because widening a regular expression is not enough. RFC 7950 defines pattern as a restriction on which strings are valid. It also says the built-in string's canonical form is its lexical representation and performs no Unicode normalization. A pattern can admit both upper- and lower-case text; it does not instruct the comparison engine to fold case. It can admit two separators; it does not declare them equivalent.

One schema, two possible duplicate decisions

The draft is deliberately optional. An implementation that supports the extension must use the normalized form. An implementation that does not support it continues with the lexical type. This follows YANG's existing extension rule: an unsupported extension may be ignored, while a supported one is processed under its specification.

The consequence is operationally sharper than a display difference. Suppose one configuration already contains aa:bb:cc:dd:ee:ff and a second input presents AA-BB-CC-DD-EE-FF. A supporting implementation can reject the second value as the same normalized key. A non-supporting implementation may see two distinct strings—assuming each is valid for the type at its own schema location. The same split applies to = and !=, to keyed lists and to the uniqueness requirement for configuration leaf-lists.

A rejection receipt therefore needs more than the two strings. It needs the exact module revision, the schema node and base type, the declared normalized identity, the implementation and release, evidence that the extension was supported, and the normalized value used. Without those fields, “duplicate” does not say which rule produced the verdict.

The status line requires three facts, not one

The live Datatracker record calls the document an active individual Internet-Draft, lists no RFC stream and no intended RFC status, and shows the IESG state I-D Exists. It also carries the standard warning that anyone may submit an Internet-Draft and that this one has no IETF endorsement or formal standing. The immutable body, meanwhile, prints Intended status: Standards Track and expires on 2 January 2027.

Those statements are not interchangeable. The body header records what the authors put in revision 00. Datatracker records where the document actually sits in the process. Even though the embedded module's organization text names the IETF NETMOD Working Group, no evidence in the current record shows WG adoption.

The authors are Don Fedyk of LabN Consulting and Scott Mansfield of Ericsson. Their Datatracker profiles show substantial standards work: Fedyk's profile lists 24 RFCs, while Mansfield's profile lists five RFCs and IETF-to-ITU-T liaison roles. Experience makes the proposal worth close reading; it does not supply institutional approval.

The issue also predates this text. Mansfield's IETF 124 NETMOD slides compared the IETF and IEEE spellings and set out alternatives: migrate to one hard-to-read representation, broaden patterns without fixing equality, add a comparison mechanism, change storage, or do nothing. Revision 00 selects the comparison-mechanism route while preserving existing lexical forms.

Equality is a bounded receipt

An equal normalized form proves that two accepted inputs met the same declared transformation. An XPath equality result proves how that implementation evaluated the expression in that schema context. A duplicate rejection proves that a local configuration constraint fired.

None proves that the records refer to the same real device. None proves collision freedom for other future normalization identities, identical implementation on both sides, bilateral support, the same schema or XPath view, or migration of stored data. It does not establish operator intent, authorization, forwarding-table deduplication, packet behavior or customer outcome.

That boundary distinguishes this proposal from ordinary canonicalization. XDR, for example, defines one external byte representation. This draft instead preserves multiple lexical representations and proposes a separate identity for selected comparisons. It also differs from module-version selection and schema diff: loading the right file remains a prerequisite, but it is not evidence that this algorithm ran.

The proposal's useful question is therefore specific: when two strings enter a YANG-controlled decision, which evidence shows that the implementation compared their declared value rather than their typography?