Hi Eric, Thanks for your review and feedback. Please check inline below for response to your comments.
I have posted an update including the changes discussed below: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-15 On Thu, Jun 22, 2023 at 11:31 AM Éric Vyncke via Datatracker < nore...@ietf.org> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-lsr-ospfv3-srv6-extensions-14: 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: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for > draft-ietf-lsr-ospfv3-srv6-extensions-14 > > Thank you for the work put into this document. Sorry for belated ballot, as > Roman cleared his DISCUSS, I just noticed today that there is one ballot > missing: here it is ;-) > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education). > > Special thanks to Acee Lindem for the shepherd's detailed write-up > including > the WG consensus *and* the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # COMMENTS > > ## SRv6 or Network Programming > > The name of the document and its abstract refer to SRv6 while it is rather > for > network programming (RFC 8986). > KT> This is just following the convention for SRv6 related control plane extensions. e.g. RFC9352, RFC9252, and several others. > > ## Section 5 > > `Locators associated with algorithms 0 and 1`, I must admit that I am not > familiar with OSPF/network programming, but is the reader expected to know > what > are "algorithms 0 and 1" ? Some short explanations are probably welcome. > KT> Ack. Added reference to sec 3.1.1 of RFC8402 where they are specified. > > ## Section 6 > > Bits in a flag field are more often specified by their position, bit 0, > rather > than by their value, 0x80. But, this is a matter of taste. The same > inconsistency happens in sections 13.3 (using a value) and 13.4 (using a > bit > position) in the IANA section. > KT> I agree and this is what has been done for the registry introduced by this document. However, we are not changing OSPFv3 Prefix Options that were introduced by RFC2740/RFC4940/RFC5340. > > ## Section 7.1 > > Should the obvious be stated for the Locator field ? I.e., this field > should be > the shortest as possible with unused bits set to 0 ? > KT> This is what has been specified normatively by the base OSPFv3 spec (refer https://datatracker.ietf.org/doc/html/rfc5340#appendix-A.4.1) - we are just pointing to that rather than repeating it as it could have somewhat unexpected interpretations. > > ## Section 8 > > `Every SRv6-enabled OSPFv3 router SHOULD advertise` as it is not a MUST, in > which case a router may deviate from the SHOULD behavior ? > KT> Technically, it is not a MUST if that router is not going to be used as a segment endpoint by any SR Source Node (e.g. for TE or for TI-LFA purposes). This is now clarified similar to how we have done for End.X in section 9. Thanks, Ketan
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
