[Status] Comments on -15

["John G. Scudder" <[e-mail]>]

This looks pretty well-baked, thanks. Some nits below.

--John

1. Thanks for fixing "negation", but even "negotiation" could be clearer:

"are never possible, i.e., attackers will be unable to 
send source routed packets that get successfully 
processed, without being part of the negotiation for 
setting up the source routes or being able to eavesdrop"

Perhaps what you mean is "... without being able to participate in the relevant control plane(s)"?

2. This text seems to have produced significant confusion among the IESG:

"Initial work will focus on SPRING within in a single AS, 
however design decisions must not preclude operation 
of SPRING across AS boundaries."

Possibly it would be worth spelling out explicitly that the previously-stated trust model continues to apply for multi-AS, e.g. by appending

"In such multi-AS deployments, the previously-stated trust model would still apply. This is relevant in the context of multiple ASes operated by a single entity."

3. This could be rewritten more concisely:

"The SPRING WG should provide OAM and the 
management needed to manage  SPRING enabled networks."

It becomes especially evident if you consider what the "M" in "OAM" stands for. (Does anyone know where the nearest ATM Machine is? :-)

Perhaps just

"The SPRING WG should address OAM for SPRING enabled networks"

Although one might argue even this is redundant and you could perfectly well get by with

"The SPRING WG should address OAM."

4. This makes an unwarranted presupposition:

"The SPRING protocol itself may also be used as a tool for OAM
in SPRING enabled networks."

I'm actually not sure what "the SPRING protocol" is, especially given the WG isn't being chartered to produce a "SPRING protocol" per se. Maybe,

"SPRING procedures may themselves also be used..."

5. s/architecture/architectures/ in:

"o Specification of a high-level abstract architecture for 
   SPRING and requirements for modifications to existing 
   architecture to support SPRING use cases."

6. The word "source" is sprinkled liberally around the charter without taking care to define what it means in this context -- whether it's the packet's originator (the usual meaning) or something else. One approach would be to rewrite all uses of "source" to be more explicit, but for expedience we might just insert a statement like "in the context of this charter, 'source' means 'the point at which the explicit route was imposed'."

7. s/mechanism/mechanisms/ in:

"o Definition of requirements and/or management  plane 
   mechanism needed to manage and operate a 
   SPRING enabled network."