Hi Eric, Thanks for your review and your comments. Please check inline below for responses.
On Thu, Feb 17, 2022 at 8:23 PM Éric Vyncke via Datatracker < nore...@ietf.org> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: 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/blog/handling-iesg-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-spring-segment-routing-policy/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. I am afraid that, due to > lack of > available time, I only quickly reviewed this document and I will rely on > the > INT directorate review. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks to Jim Guichard for the shepherd's write-up including the > section about the WG consensus and discussion. > > Thanks also to Carlos Bernardos for the INT directorate review dated 13th > of > March. I have also seen that authors are in an email discussion with > Carlos and > I appreciate that Carlos was acknowledged in the acknowledgment section. > See > < > https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-policy-16-intdir-telechat-bernardos-2022-02-13/ > >. > > I hope that this helps to improve the document, > > Regards, > > -éric > > Generic comment: this document uses the term "headend", which is not used > in > other SRv6-related documents. Not really important though. > KT> It is used in RFC8402 and is base SR - i.e. not SRv6 specific. We'll try to explain that term when first used in the abstract similar to how it is in the Introduction section. > > ## Abstract > > Mostly cosmetic, but the abstract would benefit from being more concise and > straight to the point. > KT> Will rephrase. We have some text trying to give a brief overview of what SR Policy based on previous feedback during WG phase. > > ## Section 2.1 > > Please use "::" rather than "::0" to respect RFC 5952. Also for section > 8.8.1 > KT> Ack. > > I also share the concern of other AD for an ASCII-only symbolic name. > KT> Please see my response to other ADs. > > ## Section 2.3 > > Why are the values 10, 20, and 30 only RECOMMENDED in a standard track > document > and are not a MUST ? KT> It cannot be a MUST since operators want the flexibility to determine the precedence of the source protocols/mechanisms that they use. > If this is about distance, then let's be clear and name > this value as "distance" or "origin-precedence". > KT> "origin-precedence" is indeed a good suggestion and it is unfortunate that this didn't come earlier in the WG process. I am ok to change it, but it will have repercussions not only on this document but in other protocol specifications as well. Let me hold off from making this change for some time to give chance if anyone has concerns and if not, I will make the change in an upcoming version. > > ## Section 2.13 > > Rather than using 1.1.1.1 or 2.2.2.2 please use the documentation > addresses for > IPv4 / IPv6. Same reasoning for using the example ASN. > KT> Ack > > # NITS > > Probably a topic beaten to death but isn't "ISIS" spelled "IS-IS" ? > KT> Ack > > Usually, "i.e." is always followed by a "," > KT> Ack. Thanks, Ketan
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
