Adam - Thanx for the review. V14 has been published and it attempts to address the Security concerns raised by you and others. Look forward to your feedback.
Inline. > -----Original Message----- > From: Adam Roach [mailto:[email protected]] > Sent: Wednesday, December 13, 2017 9:59 AM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: Adam Roach's No Objection on draft-ietf-spring-segment-routing- > 13: (with COMMENT) > > 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. > [Les:] SR is to be deployed within a trusted domain. This point has been emphasized/clarified in the Security section changes. We have also provided a few examples of the problems which could occur should appropriate protection not be implemented/fail. > 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. > [Les:] Fixed > Section 3.4.2: > > These extensions are defined in IGP SR extensions documents. > > Please add a citation to the relevant documents. [Les:] There is a citation to the IGP documents in Section 3. I did not see the necessity to repeat it in the sub-sections. > > 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. > [Les:] Fixed. Les _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
