Mohamed Boucadair has entered the following ballot position for draft-ietf-lsr-ospf-ls-link-infinity-19: 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-ls-link-infinity/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Liyan, Weiqiang, Changwang, Acee, and Ran, Thank you for the effort put into this specification. Special thanks for the detailed Operational Considerations section. The approach in this draft is consistent with draft-iab-nemops-workshop-report, especially this part: * Consider having YANG as part of the protocol specification/change where possible, or have the YANG document progress in parallel. Thanks also to Dhruv Dhody for the great OPSDIR review and to authors for positively engaging and making relevant changes. I have already reviewed a previous version of this specification. Thanks to the authors for having addressed that review: https://mailarchive.ietf.org/arch/msg/ops-dir/uS3e3-HJVS1_PmDyySa9Im5-y3E/. Please find below some comments based on the latest version. Let me know if any help is needed. # IETF Last Call comments Unless I’m mistaken, there was no follow up to this review: https://mailarchive.ietf.org/arch/msg/last-call/kKh1DX7mc3l40GX_6lDB8Ab6ty0/ Was that missed or that the points raised there are not issues? # Flex-Algorithm SPF CURRENT: This applies to both the Flex-Algorithm SPF and the base SPF as long as LSLinkInfinity is specified for the OSPF metric. and This applies to both the Flex-Algorithm SPF and the base SPF as long as LSLinkInfinity is specified for the OSPF metric. We don’t have any normative reference for Flex-Algorithm SPF in the doc. Can we please add one? Thanks. # IANA-maintained module Thanks for adopting this design. However, we need to make sure the module is not kept in the final RFC per the following in RFC8704bis: 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. I suggest we make this change: OLD: This document defines the initial version of the IANA-maintained YANG module for OSPF Router Functional Capabilities that mirrors the IANA "OSPF Router Functional Capability Bits" registry [IANA-OSPF-FC-Bits]. NEW: This document defines the initial version of the IANA-maintained YANG module for OSPF Router Functional Capabilities that mirrors the IANA "OSPF Router Functional Capability Bits" registry [IANA-OSPF-FC-Bits]. The latest version of this YANG module is available at IANA_URL. Note to the RFC Editor: Please remove this module in the version to be published as RFC. # IANA Module for OSPF Functional Capability Bits ## Mismatch between the registry name and the identifier I suggest you fix this as follows: OLD: registry, a new "identity" statement needs to be added to the "iana- ospf-functional-cap-bits" YANG module. The name of the "identity" MUST be the name as provided in the registry. NEW: registry, a new "identity" statement needs to be added to the "iana- ospf-functional-cap-bits" YANG module. The name of the "identity" is the lower-case name provided in the registry with all spaces replaced with “-“. ## Description CURRENT: "description": Replicates the description from the registry. There is no such field in the registry. I think this should be capability name. ## Default I suggest to delete this text as these actions correspond to the normal IANA operations CURRENT: When the "iana-ospf-functional-cap-bits" 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 udpates 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. # Normative references CURRENT: Updates: 5443, 6987, 8770 (if approved) China Mobile However, these are listed as informative. Please move RFC5443, RFC6987, and RFC8770 to be listed as normative. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # No need to motivate YANG I would delete this text in Section 4.2: YANG [RFC7950] is a data definition language used to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF [RFC6241] or RESTCONF [RFC8040]. Also, this is restrictive as other non-IETF protocols are available out there. # Two modules I’m really neutral on this but I’m curious whether there is any reason modules in 4.2.4. and 4.2.5. are not covered in the same module? If you decide to keep them separate, consider adding a note to motivate the design. # References Please move RFC6241 and RFC8040 from Normative to Informative. Cheers, Med _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
