Hi Med, > On Feb 24, 2026, at 6:32 AM, Mohamed Boucadair via Datatracker > <[email protected]> wrote: > > 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?
Someone did forward these comments to me, and I did fix the nits and attempt to clarify some text. However, they weren't sent to the LSR list where LSR drafts must be discussed. I'm not going to encourage people commenting on LSR drafts and not copying the LSR list. Also, the comments were very detailed but out of context relative to OSPF and Flex Algorithm and it seems they may have come from an AI review. > > # 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. I moved the existing reference to normative. > > # 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. I replaced this - was IANA_URL supposed to contain an actual URL? I put what I thought it would be. > > # 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 “-“. Okay - I hope this is the last time the wording for IANA-maintained YANG modules have to change. > > ## Description > > CURRENT: > "description": Replicates the description from the registry. > > There is no such field in the registry. I think this should be capability > name. I fixed this. > > ## 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. I removed. The less boilerplate shit, the better. > > # 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. Moved. > > > ---------------------------------------------------------------------- > 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. I've removed and won't include the boilerplate text in future YANG documents. > > # 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. I didn't make the initial decision to separate them but since they are totally independent with module names that clearly define their purpose. I see no advantage to combine them at this point or justify why they are separate. > > # References > > Please move RFC6241 and RFC8040 from Normative to Informative. Moved. Thanks, Acee > > Cheers, > Med > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
