Source Packet Routing in Networking
charter-ietf-spring-02

Thanks for addressing my BLOCK.

- The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions, for example:

Isn't more precise to say "that a particular flow will traverse"?
I guess it depends if you have in mind the data plane (per packet) or the application using SPRING, which I believe, will be using flows

I have no problems with this going to external review, but I think my English parser is broken.  The "and/or" construct in the last three work items is confusing.  Can the proposed WG define encodings, control plane mechanisms, or management plane mechanisms *without* defining the requirements for those new items?

Another thing that caught my eye was the mention of loose and strict source routing.  Is the group completely aware of the issues surrounding IP-layer source routing?  For example, RFC 5095 deprecates a type of routing header that was found to be a vehicle for attacks (e.g., the CanSecWest reference is quite useful).

 As a part 
of its work, the working group will define the new 
IPv6-based routing header in way that blind attacks 
are never possible, i.e., attackers will be unable to 
send source routed packets that get successfully 
processed, without being part of the negations for 
setting up the source routes or being able to eavesdrop 
legitimate source routed packets. In some networks 
this base level security may be complemented with 
other mechanisms, such as packet filtering,  cryptographic 
security, etc.

I believe it should be negotiations rather than negations

former block, 

I am strongly in favor of jari's, statement.

I would very much like to see the charter address first why it is believed that now it is feasible to do this when we've been down this path before.

clearing.

Thanks to Adrian for reminding me to wear my other glasses :)

Agreeing in part with Spencer's comment: Is there any reason *not* to ask the WG to recharter simply to add a work item if they really to work on a change to architectures, data planes, or control or management plane protocols? We have WGs update their charters for far less impressive changes.

It's not clear to me why we think this will succeed where other source-routing systems have failed.  But that's probably a topic for a separate discussion.

I'm not objecting, especially if this goes for external review, but I'm not following this text:

"Any 
modification of or extension to existing architectures,
data planes, or control or management plane protocols 
must be carried out in the working groups responsible 
^^^^^^^
for the architecture, data plane, or control or 
management plane protocol being modified and in 
co-ordination with this working group, but may be 
                                       ^^^^^^^^^^
done in this working group after agreement with 
all the relevant WG chairs and responsible Area Directors."

Is this saying something besides "we'll do the right thing"? The text here feels loose enough that I'm not sure why it needs to be in the charter.

I thnk Jari/Joel make good points that the lessons from other 
SR attempts should be seriously considered.

I also reckon that packet injection is probably not the only
threat that should be considered, e.g. having some compromised
nodes in a "trusted" domain should probably also be up
for consideration. In terms of charter text that could be a
very simple fix, e.g. 

OLD:

For each data plane technology that SPRING specifies, 
a security analysis must be provided showing how protection 
is provided against an attacker disrupting the network by 
maliciously injecting SPRING packets.

NEW:

For each data plane technology that SPRING specifies, 
a security analysis must be provided showing how protection 
is provided against an attacker disrupting the network by 
for example, maliciously injecting SPRING packets.

I agree with the point Jari raised in his block, and with Spencer's advice about how to handle the situation where work ought to be done in some other working group, but based on some sort of discretion winds up being done in spring.