Looks good, thanks, Ketan. Jim
From: Ketan Talaulikar <[email protected]> Sent: Saturday, June 3, 2023 10:52 AM To: James Guichard <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: Jim Guichard's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-11: (with COMMENT) 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]<mailto:[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
