Source Packet Routing in Networking (SPRING) Problem Statement and Requirements
draft-ietf-spring-problem-statement-08

A terminology section and describing at all the bullets of desired functionality would
improve the readability.  This draft doesn't feel as if it will be a useful RFC in 2 years.

(1)
I'm surprised that almost all of the requirements in this document are SHOULDs, since they mostly apply to an architecture and not individual solutions. In general I think it would help to explain the exception cases or the rationale for uncertainty about what the architecture will or won't support.

(2)
The security considerations section here appears to borrow text from the SPRING WG charter, but then is actually less specific than the charter about the anticipated mitigations that the SPRING architecture will provide against known threats. Given the structure of this document I would have expected detailed security requirements that any SPRING solution will be required to meet.

I'm not going to block over this, but I share the question about why this should be published as an RFC. It seems to be intended to guide other work. Once that work is done, will people still need this? This might be more appropriate for a wg wiki.

The "Requirements Language" section contains the standard RFC 2119 boilerplate. But this draft does not use the terms as defined in 2119. That talks about implementation requirements, not requirements on new IETF work. If you want to keep the 2119 keywords, please adjust the boilerplate to say what you are actually doing. (Personally, I don't think the 2119 keywords add much, and may cause confusion. (Along those lines, I share Alissa's question about the heavy use of SHOULDs).

The security considerations are inadequate. I would like to see more about the potential threats for a source-routed system. For example, is it a privacy issue if you leak routes across a domain boundary? Could an attacker modify routes to cause traffic to be routed to a tap point? (etc)

Several of the informative references define use cases that seem to be necessary to fully understand this document. Please consider making them normative.

-
It seems to me that, when speaking of SPRING, people speaks of Segment Routing.
The section title 3.3.1.2.2. is "SDN/SR use-case" btw.
Why not mention it somewhere in the doc, for this first SPRING document? "SPRING is also known as Segment Routing"

I find myself rather unsatisfied by 

   The SPRING architecture SHOULD leverage the existing MPLS dataplane
   without any modification and leverage IPv6 dataplane with a new IPv6
   Routing Header Type (IPv6 Routing Header is defined in [RFC2460]).

in that the prospects for use of a new routing header, and ipv6 router/extension header treatment  seem poor. and the potential consequences for chaining these for example seem worth exploring before electing that course of action.

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.
- 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.
- You figure spring is ok-ish for MPLS, or at least no 
  worse than today, is that right?
- 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?
  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'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.

Thank you for the update in addressing my concerns in this rev, clearing my DISCUSS.