Hi, see below for some comments.
> On Mar 2, 2016, at 1:21 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Stephen Farrell has entered the following ballot position for > draft-ietf-spring-problem-statement-07: 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-problem-statement/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for adding the new security considerations text. > > My take-away from that is: > > - The architecture needs to have a clearly defined > concept of domains so that you can strip source > routes on ingress/egress, if needed. sure. That was also my point. The problem-statement draft is clearly not the document that has to contain such details. > - We know there are (as yet unstated) security issues > with source routing. The architecture document is > where those are promised. Which document is that? > Is it draft-ietf-spring-segment-routing? > So far, that doesn't seem to be there, so we should > expect more discussion to be needed if that remains > the case. ok > - You figure spring is ok-ish for MPLS, or at least no > worse than today, is that right? yes. But if it turns out that additional mechanism are needed, we’ll certainly integrate them into the architecture and/or dataplane specific drafts (mpls and v6). > - There is a need for a digital signature mechanism > (or similar) for the IPv6 data plane. In which document > would I find that? > Is it draft-previdi-6man-segment-routing-header? draft-ietf-6man-segment-routing-header Thanks. s. > If so, that seems to call for pre-shared keys, which > seems likely to be tricky, if we consider BCP107. I > think we'll be heading for yet another discussion > of the need for automated key management here. > > I'm ok with letting this document go ahead, but I do hope > the WG have substantive discussion of the above topics and > we don't leave that to IESG review of the documents > concerned. I agree. Thanks. s. > I'm happy to try help get that done earlier if > the WG are up for that as leaving it to IESG review is > liable to be more painful all around. > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
