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 protected]] On Behalf Of Ben Campbell > Sent: Wednesday, December 13, 2017 7:04 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: [spring] Ben Campbell's No Objection on draft-ietf-spring-segment- > routing-13: (with COMMENT) > > 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? > [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. > -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 > [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. > Editorial Comments and Nits: > > -1, 2nd paragraph: s/"referred by"/"referred to by" > [Les:] Fixed > -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.) > [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 protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
