Subject: [spring] Ben Campbell's No Objection on draft-ietf-spring-problem-statement-06: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 03 Feb 2016 13:30:21 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-spring-problem-statement-06: 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:
----------------------------------------------------------------------

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.