Hi Mike, Thanks for the review.
> On Mar 3, 2026, at 3:04 PM, Mike Bishop via Datatracker <[email protected]> > wrote: > > Mike Bishop has entered the following ballot position for > draft-ietf-lsr-ospf-ls-link-infinity-23: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # IESG review of draft-ietf-lsr-ospf-ls-link-infinity-23 > > CC @MikeBishop > > ## Comments > > ### Section 6, paragraph 0 > > Please add links to the relevant registries. Okay. > > ## Nits > > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > ### Typos > > #### Section 2.2, paragraph 11 > ``` > - 3. LSLinkInfinity Based Solution > - ^ > + 3. LSLinkInfinity-Based Solution > + ^ > ``` Ok. > > #### Section 3.2, paragraph 7 > ``` > - metric of LSLinkInfinity MUST be treated as unreachable. Upon > - ^^ > - detection of a change in the number of routers in the area not > + metric of LSLinkInfinity MUST be treated as unreachable. When the number > of routers in the area not + > > ^^^^^^^^^^^^^^^^ +++++++++++ +++++++++++++ ``` Agreed - this is clearer. > > #### Section 3.3, paragraph 4 > ``` > - [RFC5340] to prevent usage stub router links for transit traffic. > + [RFC5340] to prevent the usage of stub router links for transit traffic. > + ++++ +++ > ``` Ok - this is more consistent with previous text. > > #### Section 5, paragraph 2 > ``` > - The security considerations for [RFC2328],[RFC5340], [RFC6987], and > + The security considerations for [RFC2328], [RFC5340], [RFC6987], and > + + > ``` Ok. > > #### Section 5, paragraph 3 > ``` > - SSH [RFC4252], TLS [I-D.ietf-tls-rfc8446bis], and QUIC [RFC9000]) and > - ^^^ > + SSH [RFC4252], TLS [I-D.ietf-tls-rfc8446bis], or QUIC [RFC9000]) and This is the boilerplate from section 3.7.1 in https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/. > + ^^ > ``` > > ### URLs > > These URLs in the document did not return content: > > * > https://www.iana.org/assignments/iana-ospf-functional-cap-bits/iana-ospf-functional-cap-bits.xhtml This is what the URL is expected to be when IANA completes its actions. I replaced with TBD. > > ### Grammar/style > > #### Section 4.2.5, paragraph 8 > ``` > egistry with all spaces replaced with “-“. The "identity" statement should ha > ^ ^ > ``` > Please do not use "smart-quotes". I don't understand this comment. I believe this text is boilerplate for IANA modules. Thanks, Acee > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
