Hi Acee, Thanks for the follow-up and changes made in 20/21 (*). This looks good to me. I will clear the DISCUSS after the telechat.
I guess the only pending point is the one related to the process that I'm top posting here for convenience: > > # 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. (1) For full transparency, I discussed this offline with Gunter last week as I wanted to first check if you were aware about that review and whether private messages have taken place. (2) Not receiving a LC comment on the WG list is not a reason to refuse to engage in addressing/discussing received comments I agree that it is more convenient if the WG mailing list (or at least the draft alias) is cced, but IETF LC discussion happens on the last call list. It is not unsual that LC comments are sent without ccing the relevant WG. As an AD, I always check that list and forward messages to the authors/WG when these are not cced as I know some of the authors are not on the LC list. This is time consuming for me as well. (3) As a reminder, the LC message says the following: "The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email protected] mailing lists by 2026-02-12. Exceptionally, comments may be sent to [email protected] instead. In either case, please retain the beginning of the Subject line to allow automated sorting." I would be in favor of considering updating that blob for future announcements to encourage keeping WG/authors. This is a point beyond this draft and can be discussed with the IESG members. (4) FYI, we have two drafts in this IESG Telechat with the same situation as the LSR. The other draft is an IPPM draft I'm sponsoring. My advice to the authors was to positively engage as you can see at https://mailarchive.ietf.org/arch/msg/last-call/VxJcBcxNqx0Q9kGW2XYmJssfz6I/. Cheers, Med (*) https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-ospf-ls-link-infinity-19&url2=draft-ietf-lsr-ospf-ls-link-infinity-21&difftype=--html > -----Message d'origine----- > De : Acee Lindem <[email protected]> > Envoyé : mardi 24 février 2026 22:02 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : The IESG <[email protected]>; draft-ietf-lsr-ospf-ls-link- > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-lsr-ospf-ls- > link-infinity-19: (with DISCUSS and COMMENT) > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www. > > ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > positi > > > ons%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C53451c7e21a > c4a5 > > > c244808de73e80e60%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639 > 0756 > > > 37670583525%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLj > > > AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > 7C%7 > > > C&sdata=LwHRw9noBa62aEQVx0dMDXPMTg4csG5f8GoiI%2FhRGZY%3D&reserved= > 0 > > for more information about how to handle DISCUSS and COMMENT > positions. > > > > > > The document, along with other ballot positions, can be found > here: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > data > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-ospf-ls-link- > infinity%2F&data= > > > 05%7C02%7Cmohamed.boucadair%40orange.com%7C53451c7e21ac4a5c244808d > e73e > > > 80e60%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639075637670606 > 475% > > > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMC > IsIl > > > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= > zzXc > > 4PUdeWFpAIAZiIUdJNM7SBRaMCWKC6pmFhynkAY%3D&reserved=0 > > > > > > > > ---------------------------------------------------------------- > ------ > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fmsg%2Fops-dir%2FuS3e3- > HJVS1_PmDyySa9Im5- > y3E%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C53451c7e21a > c4a5c244808de73e80e60%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C639075637670618064%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > D%3D%7C0%7C%7C%7C&sdata=YQQSNHRbrs86ARVuf0ZTRAowFV1Q%2FnIN%2Blk57c > 0N4Kg%3D&reserved=0. > > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mail > > archive.ietf.org%2Farch%2Fmsg%2Flast- > call%2FkKh1DX7mc3l40GX_6lDB8Ab6ty > > > 0%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C53451c7e21ac4 > a5c2 > > > 44808de73e80e60%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63907 > 5637 > > > 670628761%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw > LjAu > > > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C > %7C& > > > sdata=Hk7d%2FCOOkCey6iMs7e4GL%2FsSq%2BhggIQiOP068KVyCwI%3D&reserve > d=0 > > 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 > > > > > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
