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]
