Subject: [spring] Éric Vyncke's No Objection on draft-ietf-spring-segment-routing-policy-17: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 17 Feb 2022 06:52:53 -0800

É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.

## Abstract

Mostly cosmetic, but the abstract would benefit from being more concise and
straight to the point.

## Section 2.1

Please use "::" rather than "::0" to respect RFC 5952. Also for section 8.8.1

I also share the concern of other AD for an ASCII-only symbolic name.

## Section 2.3

Why are the values 10, 20, and 30 only RECOMMENDED in a standard track document
and are not a MUST ? If this is about distance, then let's be clear and name
this value as "distance" or "origin-precedence".

## 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.

# NITS

Probably a topic beaten to death but isn't "ISIS" spelled "IS-IS" ?

Usually, "i.e." is always followed by a ","

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 23:42:57 +0530

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 <
[email-masked]> wrote:

> <
> https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-policy-16-intdir-telechat-bernardos-2022-02-13/
> >.
>

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.

> Mostly cosmetic, but the abstract would benefit from being more concise and

KT> Will rephrase. We have some text trying to give a brief overview of
what SR Policy based on previous feedback during WG phase.

> Please use "::" rather than "::0" to respect RFC 5952. Also for section

KT> Ack.

> I also share the concern of other AD for an ASCII-only symbolic name.

KT> Please see my response to other ADs.

> 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

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.

> IPv4 / IPv6. Same reasoning for using the example ASN.

KT> Ack

> 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