Subject: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Dec 2017 19:03:36 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-spring-segment-routing-13: 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/iesg/statement/discuss-criteria.html
for more information about IESG 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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

- I support Alissa's discuss and Adam's major comment.

- Requirements Language: There are lower case instances of 2119 keywords.
Unless you mean for those to also be normative, please use the boilerplate from
RFC 8174.

-3.1.1, last paragraph: Why are the SHOULDs not MUSTs?

-12.2: The citations to the following references seem to be used normatively:
I-D.ietf-6man-segment-routing-header
I-D.ietf-isis-segment-routing-extensions
I-D.ietf-ospf-ospfv3-segment-routing-extensions
I-D.ietf-ospf-segment-routing-extensions

Editorial Comments and Nits:

-1, 2nd paragraph: s/"referred by"/"referred to by"

-2, definition of "Active Segment" : "The segment that MUST be used..."
The MUST seems like a statement of fact. (If that is actually intended to
define a requirement, please state it more directly.)

-8, 2nd paragraph, first sentence: s/on/to

-8.2, 2nd paragraph, first sentence: s/on/to

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 20 Dec 2017 23:35:57 +0000

Ben -

Thanx for the review.
V14 has been published and it attempts to address the Security concerns.
Look forward to your feedback.

Inline.

> -----Original Message-----
> From: spring [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Wednesday, December 13, 2017 7:04 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment-
> routing-13: (with COMMENT)
> 
> 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.)
> 
> 
> Unless you mean for those to also be normative, please use the boilerplate
> from RFC 8174.
> 
[Les:] Failure to do the validation will result in the packet being dropped when it reaches a node which does not support the algorithm i.e., the algorithm specific label will not match any installed incoming label. This is sub-optimal but not fatal - hence SHOULD rather than MUST.

> I-D.ietf-ospf-segment-routing-extensions
[Les:] I respectfully disagree.
The architecture document is NOT dependent upon the IGP/6man documents - the dependency is the other way around.
The referenced documents are useful for readers who wish to better understand how the architecture is supported by routing protocols/IPv6 - but there is no dependency that the architecture definition has on the implementation specifics.

> -1, 2nd paragraph: s/"referred by"/"referred to by"
[Les:] Fixed

> define a requirement, please state it more directly.)
[Les:] Fixed

> -8, 2nd paragraph, first sentence: s/on/to
[Les:] Fixed

> -8.2, 2nd paragraph, first sentence: s/on/to

[Les:] Fixed

   Les

> 
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring