Adam Roach 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: ---------------------------------------------------------------------- Thanks to everyone who put in work on this document. I do note that the list of authors is over the five-author recommended limit. I checked both the ballot and the shepherd write-up, and was a little surprised not to find an explanation of why this document is exceptional in this regard. I have one major comment and a handful of editorial comments. The major comment regards the treatment of trust assumptions in the security section. The SR-MPLS section asserts: "[T]here is an assumed trust model such that any node imposing a label stack on a packet is assumed to be allowed to do so"; the SRv6 section has a similar assertion: "[T]here is an assumed trust model such that any node adding an SRH to the packet is assumed to be allowed to do so." I leave it to the security area directors to speak to whether it is okay in 2017 to publish documents that forego integrity protection of source routing information based on assumptions of perfectly secured networks. Irrespective of the answer to that question, I'm perplexed that the security section does not go into detail about the consequences that arise when these assumptions are violated. I think a clear description of these consequences is relevant and necessary to include, as it informs the level of care that is appropriate for both implementation and deployment of these protocols. I want to be clear that I consider this a major flaw in the document, and am on the fence regarding whether it should constitute a blocking DISCUSS. I would support anyone else in issuing a DISCUSS on this topic. Editorial comments follow. Section 2 contains the following text: Active Segment: the segment that MUST be used by the receiving router to process the packet. I really don't think you want to use normative language in the terminology section. I strongly recommend moving this requirement down to a section that bears more directly on implementation. Section 3.4.2: These extensions are defined in IGP SR extensions documents. Please add a citation to the relevant documents. Section 3.5: ABRs G and J will propagate the prefix and its SIDs into the backbone area by creating a new instance of the prefix according to normal inter-area/level IGP propagation rules. Please expand the term "ABR" on first use. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
