Thank you, Ketan, for your prompt reply and the revised I-D. I also agree with all your points below, still a little uneasy with the mix of flags by bit position or by value, but this is a matter of taste.
Regards -éric From: Ketan Talaulikar <ketant.i...@gmail.com> Date: Thursday, 22 June 2023 at 08:45 To: Eric Vyncke <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" <draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org>, "lsr-cha...@ietf.org" <lsr-cha...@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "a...@cisco.com" <a...@cisco.com> Subject: Re: Éric Vyncke's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-14: (with COMMENT) 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<mailto: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
