Med, Can you please check the latest and hopefully clear your DISCUSS?
Thanks, Acee > On Jun 23, 2026, at 10:35 AM, Mohamed Boucadair via Datatracker > <[email protected]> wrote: > > Mohamed Boucadair has entered the following ballot position for > draft-ietf-lsr-ospf-flex-algo-yang-08: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-flex-algo-yang/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hi Yingzhen and Acee, > > Thank you for the effort put into this document. > > The same DISCUSS/COMMENT points I raised for the IS-IS spec at > https://mailarchive.ietf.org/arch/msg/lsr/ydQQNGc5m4cFrDpH7CYOWP3tEKU/ apply > here as I well. I’m not repeating those and I trust the outcome of that thread > will be factorized for this document. > > Please find below comments that are specific to this spec. > > # Mirror the registries > > All IANA-maintained modules do not mirror exactly the same content as the > registry. There are deviations in the descriptions and references. > > For example, > > identity algo-spf { > base algo-type; > description > "Shortest Path First (SPF) algorithm based on link metric."; > reference > "RFC 8665: OSPF Extensions for Segment Routing"; > } > > while the registry includes > > “Shortest Path First (SPF) algorithm based on link metric. This is the > standard shortest path algorithm as computed by the IGP protocol. Consistent > with the deployed practice for link-state protocols, Algorithm 0 permits any > node to overwrite the SPF path with a different path based on its local > policy.” > > Or > > identity te-default-metric { > base metric-type; > description > "Traffic Engineering Default Metric as defined in RFC 5305 > Section 3.7 and Traffic Engineering Metric as defined in > RFC3630, Section 2.5.5."; > reference > "RFC 3630: OSPF Traffic Engineering > RFC 5305: IS-IS Traffic Engineering > RFC 9350: IGP Flexible Algorithm"; > } > > while the registry includes only “[RFC9350, Section 5.1]” > > # Removal of IANA-maintained modules > > RFC9907 says: > > The authors MUST include a note to the RFC > Editor requesting that the appendix with the initial version of the > module be removed before publication as RFC and that RFC IIII is > replaced with the RFC number that is assigned to the document. > Initial versions of IANA-maintained YANG modules that are published > in RFCs may be misused despite the appropriate language to refer to > the IANA registry to retrieve the up-to-date module. This is > problematic for interoperability, e.g., when values are deprecated or > are associated with a new meaning. > > Can we please add the missing notes? > > # Instructions to generate the identifiers: IGP Algorithm Types > > CURRENT: > When a value is added to the "IGP Algorithm Types" registry, a new > "identity" statement needs to be added to the "iana-igp-algo-types" > YANG module. The name of the "identity" MUST be the name as provided > in the registry. The "identity" statement should have the following > sub-statements defined: > > ## There is no name in the registry. > > ## Even if we extract some name from the description, copying it as it is > would > lead to illegal identifiers. An instruction about replacing spaces with “-“ > would be needed at minimum. > > ## What about simply asking for the name to be the outcome of prefixing > “type-” > with the decimal registered value? > > ## Please avoid the use the normative language in the IANA considerations > > # Idem for the other IANA modules > > # Link Attribute Application IDs > > CURRENT: > When a value is added to the "Link Attribute Application IDs" > registry, a new "identity" statement needs to be added to the "iana- > igp-link-attr-apps" YANG module. The name of the "identity" MUST be > the name as provided in the registry. The "identity" statement > should have the following sub-statements defined: > > There is a name column but the name is, example, “RSVP-TE (R-bit)”. Following > the instruction above would lead to illegal identifier. > > Please update so that the instruction is clear and lead to legal identifiers. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Type > > As you know, RFC 9907 says the following: > An IANA-maintained YANG module may use the "identityref" data type > approach (e.g., [RFC8675]) or an "enumeration" data type approach > (e.g., [RFC9108]). See Section 4.11.1 for a guidance on which data > type to use. The decision about which type to use should be made > based upon specifics related to the intended use of the IANA- > maintained YANG module. For example, identities are useful if the > registry entries are organized hierarchically, possibly including > multiple inheritances. The reasoning for the design choice MUST be > documented in the companion specification that registers an IANA- > maintained YANG module. > > Is there any specific reason why identity is used for the various modules, > instead of enumerations? Can we please include that in the doc? > > As a side note, the use of enum would allow an easy mapping as the decimal > value can be mirrored in the “value” statement. > > # No need to include the following as this is what IANA-maintained module is > about. > > CURRENT: > This module is maintained by IANA and will be updated if and when > there is any change to the registry. > > # For all IANA-maintained modules, please add a reference that points to the > IANA registry > > For example, the first module would need to have the following right before > the > revision > > NEW: > Reference > “Interior Gateway Protocol (IGP) Parameters, IGP Algorithm Types > > (https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types)"; > > # No need to supply default actions; only needed when you need customization > from IANA > > CURRENT: > When the "iana-igp-algo-types" YANG module is updated, a new > "revision" statement with a unique revision date must be added in > front of the existing revision statements. The "revision" statement > MUST contain both "description" and "reference" substatements as > follows. > > The "description" substatement captures what changed in the revised > version. Typically, the description enumerates the changes such as > updpates to existing entries (e.g., update a description or a > reference) or notes which identities were added or had their status > changed (e.g., deprecated, discouraged, or obsoleted). > > The "reference" substatement points specifically to the published > module (i.e., IANA_FOO_URL_With_REV). It may also point to an > authoritative event triggering the update to the YANG module. In all > cases, this event is cited from the underlying IANA registry. If the > update is triggered by an RFC, that RFC must also be included in the > "reference" substatement. > > RFC9907 says: > > -- Optional: > > -- Include only text that needs to be customized for the module. > -- Text that does not require customization should be > -- omitted. > > -- Notes tagged with "--" include instructions for authors. These > -- notes must not be copied. > > Unassigned and Reserved Values: > > -- To be completed only if unassigned and/or reserved values > -- (which may include experimental values) should be included > -- in the module. These values are typically not included. > > Description Substatements: > > -- To be completed only if the default actions described in > -- Section 5.3.2 of RFC 9907 are to be overridden. > -- Specify whether instructions apply to "revision" statements, > -- "identity" statements, or both. > > Reference Substatements: > > -- To be completed only if the default actions described in > -- Section 5.3.2 of RFC 9907 are to be overridden. > -- Specify whether instructions apply to "revision" statements, > -- "identity" statements, or both. > > Naming Considerations: > > -- If a name in the IANA registry does not comply with the > -- YANG naming conventions, add details how IANA can generate > -- legal identifiers. For example, if the name begins with > -- a number, indicate a preference to spell out the number when > -- used as an identifier. > > Cheers, > Med > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
