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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 16 Feb 2022 22:36:16 -0800

Murray Kucherawy 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:
----------------------------------------------------------------------

Thanks to Cullen Jennings for his ARTART review.

I'm hardly an expert on the technologies described here, but most of the
SHOULDs I ran into left me wondering why they aren't MUSTs.  There's no obvious
(to me) implementation guidance present about when one might legitimately do
something other than what the SHOULD says.

Should Section 2.1 stipulate that symbolic names, if used, should be unique?

Thanks for the attention to detail in Section 12.

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 21:22:30 +0530

Hi Murray,

Thanks for your review and your comments. Please check inline below for
responses.

> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

KT> At the risk of getting things wrong in generalizing this, there are
deployment scenarios/designs where operators and vendors want flexibility
in having different behaviors than what would be 'a typical deployment
design". The use of SHOULD is to provide guidance while allowing
flexibility where needed.

> Should Section 2.1 stipulate that symbolic names, if used, should be

KT> We do cover the uniqueness aspect, but there was no need to stipulate
it as this is something entirely operator controlled and determined by
their requirements.

> Thanks for the attention to detail in Section 12.

Thanks,
Ketan