Hi Jim, Thanks for your review and comments. Please check inline below for response.
We've posted an update that includes changes to address your comments: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-12 On Wed, May 24, 2023 at 9:53 PM Jim Guichard via Datatracker < [email protected]> wrote: > Jim Guichard has entered the following ballot position for > draft-ietf-lsr-ospfv3-srv6-extensions-11: 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-ospfv3-srv6-extensions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - Section 1 Introduction: > > - Second paragraph last sentence reads 'SRv6 refers to this SR > instantiation on the IPv6 dataplane.' This sentence does not make much > sense. Suggest change to 'An SR instantiation on the IPv6 dataplane is > referred to as SRv6' or something along those lines. > KT> Ack. Fixed. > > - Fourth paragraph reads 'This document specifies OSPFv3 extensions to > support SRv6 as defined in [RFC8986].' This statement is not accurate > as > RFC 8986 does not define SRv6 but rather it defines SRv6 > network programming. Note further that the document provides > extensions > to support SRH, network programming and the O-bit so perhaps this > sentence should read 'This document specifies OSPFv3 extensions to > support SRv6 capabilities as defined in [RFC8986][RFC8754] and > [RFC9259]'. > KT> Ack. Fixed. > > - The text refers to 'algorithm-specific SIDs' - what are these > exactly? > there is no definition for this term, and I have not seen it in any > other > SRv6-related document. Is this a reference to the SR- > Algorithm TLV? > KT> Changed to IGP Algorithm specific SIDs as defined in RFC8402 and RFC8665. > > - Section 2 SRv6 Capabilities TLV: > > - This section refers to 'LSA ID' which is not a defined term anywhere > that > I can find. The OSPFv3 Router Information LSA uses 'Link State ID > (Instance > ID)' so please correct the last sentence of the second > paragraph to replace 'LSA ID' with 'Link State ID (Instance ID)'. > KT> Ack. Fixed. > > - Section 7.1 SRv6 Locator TLV: > > - The text 'Locator continued..' in Figure 5 might be confusing as > perhaps > it is just me but when I initially read it, I thought that multiple > Locators could be carried in the TLV. This is not the case of > course. It would be easier on the eyes if the entire 'Locator' field > of > Figure 5 were just a single block of 128-bits. Same comment for > Figures > 6, 7, and 8. > KT> Ack. Fixed based on suggestions from John. > > - The 'Locator Length' field indicates the number of Locator bits used > in > the 'Locator' field. This will almost certainly be less than 128-bits. > Should the unused bits in the 'Locator' field be set to 0? > please specify as currently, the text is silent. > > KT> Thanks for catching this. We realize that the description was not clear and the updated text has the reference to base OSPFv3 RFC5340 on encoding of IPv6 Prefixes. Thanks, Ketan
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
