Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2023-03-29
02 Amy Vezza Responsible AD changed to Jim Guichard from Andrew Alston
2022-03-23
02 Amy Vezza Responsible AD changed to Andrew Alston from Martin Vigoureux
2018-10-02
02 Cindy Morgan New version available: charter-ietf-spring-02.txt
2018-10-02
01-04 Cindy Morgan State changed to Approved from External review
2018-10-02
01-04 Cindy Morgan IESG has approved the charter
2018-10-02
01-04 Cindy Morgan Closed "Approve" ballot
2018-10-02
01-04 Cindy Morgan WG action text was changed
2018-10-02
01-04 Cindy Morgan New version to move milestones out of the charter text and into the milestone fields.
2018-10-02
01-04 Cindy Morgan New version available: charter-ietf-spring-01-04.txt
2018-10-02
01-03 Cindy Morgan Added charter milestone "Stateless service chaining with SR sent to IESG", due December 2019
2018-10-02
01-03 Cindy Morgan Added charter milestone "SR policies YANG model sent to IESG", due December 2019
2018-10-02
01-03 Cindy Morgan Added charter milestone "SRv6 Network Programming to IESG", due December 2019
2018-10-02
01-03 Cindy Morgan Added charter milestone "SR-IPv6 OAM sent to IESG", due July 2019
2018-10-02
01-03 Cindy Morgan Added charter milestone "SR-MPLS Performance Measurement to IESG", due July 2019
2018-10-02
01-03 Cindy Morgan Added charter milestone "SR-MPLS OAM sent to IESG", due July 2019
2018-10-02
01-03 Cindy Morgan Added charter milestone "SR-TE policy sent to IESG", due July 2019
2018-10-02
01-03 Cindy Morgan Added charter milestone "SR-MPLS configuration YANG model sent to IESG", due December 2018
2018-10-02
01-03 Cindy Morgan Added charter milestone "MPLS anycast sent to IESG", due October 2018
2018-10-02
01-03 Cindy Morgan Added charter milestone "SR-MPLS sent to IESG", due October 2018
2018-10-02
01-03 Martin Vigoureux New version available: charter-ietf-spring-01-03.txt
2018-09-27
01-02 Benjamin Kaduk [Ballot comment]
Alissa has some good questions, but I'm confident we can do the right thing.

Thanks for the updates to address my previous concerns.
2018-09-27
01-02 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-09-27
01-02 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-09-26
01-02 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-09-26
01-02 Alissa Cooper
[Ballot comment]
I'm not clear on the implications of the text about security considerations. If it turns out that people want to use this cross-domain, …
[Ballot comment]
I'm not clear on the implications of the text about security considerations. If it turns out that people want to use this cross-domain, will integrity protection be specified as a requirement? Will other security properties be specified as required in that scenario? If it turns out that the threat models require enhancements to the security properties of the underlying protocols, will the segment routing specs still be progressed even as those requirements are pitched over to other WGs, or will they not?
2018-09-26
01-02 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-09-26
01-02 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-09-25
01-02 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-09-25
01-02 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2018-09-25
01-02 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2018-09-24
01-02 Mirja Kühlewind
[Ballot comment]
This sentence is probably unnecessary as always true for all wgs:

"The SPRING WG will manage its specific work items by milestones agreed …
[Ballot comment]
This sentence is probably unnecessary as always true for all wgs:

"The SPRING WG will manage its specific work items by milestones agreed
with the responsible Area Director."
2018-09-24
01-02 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-09-10
01-02 Cindy Morgan Telechat date has been changed to 2018-09-27 from 2018-07-05
2018-09-10
01-02 Cindy Morgan WG new work message text was changed
2018-09-10
01-02 Cindy Morgan WG review text was changed
2018-09-10
01-02 Cindy Morgan WG review text was changed
2018-09-10
01-02 Cindy Morgan WG review text was changed
2018-09-10
01-02 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2018-09-10
01-02 Martin Vigoureux Created "Approve" ballot
2018-09-10
01-02 Martin Vigoureux Closed "Ready for external review" ballot
2018-09-10
01-02 Martin Vigoureux State changed to External review from Internal review
2018-09-05
01-02 Benjamin Kaduk
[Ballot comment]
Thanks for the updated text and the discussion to clarify that the actual protocol development
used for source routing is under the purview …
[Ballot comment]
Thanks for the updated text and the discussion to clarify that the actual protocol development
used for source routing is under the purview of different working groups, which explains the
removal of much of the text about specific work items.
2018-09-05
01-02 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Block
2018-09-05
01-02 Martin Vigoureux New version available: charter-ietf-spring-01-02.txt
2018-07-05
01-01 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-07-05
01-01 Alexey Melnikov [Ballot comment]
I am looking forward to hearing answers to/followup discussion of Benjamin's DISCUSS.
2018-07-05
01-01 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2018-07-05
01-01 Benjamin Kaduk
[Ballot block]
This proposed charter has minimal text on security concerns, asserting that
the scope is limited to a single trust domain and only applying …
[Ballot block]
This proposed charter has minimal text on security concerns, asserting that
the scope is limited to a single trust domain and only applying a weak
requirement to "strive to identify and address" security considerations
brought up by its technologies.

The text concerning a single trust domain seems to implicitly assume that
there is thus no need for cryptographic assurance of the integrity and/or
authenticity of origin for route information, a position whose accuracy
remains unclear to me.

A commitment to "strive" to do something is hardly any commitment at all,
in that failing to do that thing remains consistent with the commitment.

Additionally, the current charter text includes some security-related
items, noting that "there are a number of serious security concerns with
source routing at the IP layer", committing to define the SRv6 header so
that blind attacks are never possible (and with options to provide
additional security in some networks), and committing to provide a security
analysis for each protocol being developed.  Has anything changed in the
intervening five years to render these items unnecessary?  I don't see any
justification for why these commitments are being abandoned.
2018-07-05
01-01 Benjamin Kaduk [Ballot Position Update] New position, Block, has been recorded for Benjamin Kaduk
2018-07-05
01-01 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-07-05
01-01 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-07-04
01-01 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2018-07-04
01-01 Suresh Krishnan [Ballot comment]
Can you please add 6man as a co-ordination working group for the SRv6 Network programming item as well
2018-07-04
01-01 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-07-03
01-01 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-07-02
01-01 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-06-29
01-01 Spencer Dawkins
[Ballot comment]
I'm balloting No Objection, but hope that people look at the SPRING/IPPM interaction I mentioned below. Otherwise, this is mostly editorial.

I'm not …
[Ballot comment]
I'm balloting No Objection, but hope that people look at the SPRING/IPPM interaction I mentioned below. Otherwise, this is mostly editorial.

I'm not sure who or what finds it advantageous to use loose routing in this text -

"Full explicit control (through loose or strict
path specification) can be achieved in a network comprising only SPRING
nodes, however SPRING nodes must inter-operate through loose routing in
existing networks and may find it advantageous to use loose routing for
other network applications."

I THINK the reference is to a SPRING node, which doesn't make a lot of sense to me, but I'm guessing.

Does everyone else know what "specificities" are meant here?

"o Operation, Administration and Management (OAM), and traffic accounting
in networks with SR-MPLS and SRv6 data planes in the case where SR
introduces specificities compared to MPLS or IPv6 technologies."

and

"o Performance Management (PM) and monitoring in networks with SR-MPLS
and SRv6 data planes in the case where SR introduces specificities
compared to MPLS or IPv6 technologies."

On "Performance Management and monitoring", I note that https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ includes Segment Routing as one of its targeted encapsulations. IPPM is Mirja's working group as of about a month ago, but I'm wondering what the overlap might be. Is this something the two groups/ADs have talked about?

It might be less surprising to readers if the working group names under

"Specific expected interactions"

were capitalized.
2018-06-29
01-01 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-06-29
01-01 Martin Vigoureux New version available: charter-ietf-spring-01-01.txt
2018-06-29
01-00 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2018-06-29
01-00 Amy Vezza Telechat date has been changed to 2018-07-05 from 2013-10-24
2018-06-29
01-00 Amy Vezza WG action text was changed
2018-06-29
01-00 Amy Vezza WG review text was changed
2018-06-29
01-00 Amy Vezza WG review text was changed
2018-06-29
01-00 Amy Vezza Created "Ready for external review" ballot
2018-06-29
01-00 Amy Vezza State changed to Internal review from Informal IESG review
2018-06-29
01-00 Martin Vigoureux State changed to Informal IESG review from Approved
2018-06-29
01-00 Martin Vigoureux New version available: charter-ietf-spring-01-00.txt
2018-03-21
01 Amy Vezza Responsible AD changed to Martin Vigoureux from Alvaro Retana
2018-01-30
01 Amy Vezza Responsible AD changed to Alvaro Retana from Stewart Bryant
2013-10-25
01 Cindy Morgan New version available: charter-ietf-spring-01.txt
2013-10-25
01 Cindy Morgan State changed to Approved from IESG review
2013-10-25
01 Cindy Morgan IESG has approved the charter
2013-10-25
01 Cindy Morgan Closed "Approve" ballot
2013-10-25
01 Cindy Morgan Closed "Ready for external review" ballot
2013-10-25
00-18 Cindy Morgan WG action text was changed
2013-10-24
00-18 Stewart Bryant Added charter milestone "Recharter or close WG.", due February 2016
2013-10-24
00-18 Stewart Bryant Added charter milestone "Inter-operability reports pertaining to the implementation of extensions supporting SPRING.", due January 2016
2013-10-24
00-18 Stewart Bryant Added charter milestone "Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols.", due November 2015
2013-10-24
00-18 Stewart Bryant Added charter milestone "Specify the OAM mechanisms needed to support SPRING.", due November 2015
2013-10-24
00-18 Stewart Bryant Added charter milestone "Management requirements document.", due July 2015
2013-10-24
00-18 Stewart Bryant Added charter milestone "One or more control protocol extensions requirements documents. ", due July 2015
2013-10-24
00-18 Stewart Bryant
Added charter milestone "One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data planes.", due July …
Added charter milestone "One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data planes.", due July 2015
2013-10-24
00-18 Stewart Bryant Added charter milestone "Specification of any required new procedures to support SPRING use cases.", due March 2015
2013-10-24
00-18 Stewart Bryant Added charter milestone "Requirements for modifications if any to IPv6 architecture to support SPRING use cases.", due January 2015
2013-10-24
00-18 Stewart Bryant Added charter milestone "Requirements for modifications if any to MPLS architecture to support SPRING use cases.", due December 2014
2013-10-24
00-18 Stewart Bryant Added charter milestone "Specification of a high-level abstract architecture for SPRING.", due November 2014
2013-10-24
00-18 Stewart Bryant Added charter milestone "One or more documents describing SPRING use cases.", due July 2014
2013-10-24
00-18 Stewart Bryant New version available: charter-ietf-spring-00-18.txt
2013-10-24
00-17 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to Abstain from Block
2013-10-24
00-17 Martin Stiemerling
[Ballot comment]
I'm also concerned about Sean's issues and wonder if the quoted text implies a show stopper if no secure solution can be found …
[Ballot comment]
I'm also concerned about Sean's issues and wonder if the quoted text implies a show stopper if no secure solution can be found at all:
" 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 "
2013-10-24
00-17 Martin Stiemerling Ballot comment text updated for Martin Stiemerling
2013-10-24
00-17 Stephen Farrell
[Ballot comment]

- I agree with Sean's comment (of course:-)

- "These applications" in the para after the 1st bullet list
could maybe be clearer.  …
[Ballot comment]

- I agree with Sean's comment (of course:-)

- "These applications" in the para after the 1st bullet list
could maybe be clearer.  I guess you mean the "network
functions" mentioned before.
2013-10-24
00-17 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-10-24
00-17 Brian Haberman
[Ballot block]
I agree with Ted and will probably move to Abstain on this as well, but I want to have a discussion with the …
[Ballot block]
I agree with Ted and will probably move to Abstain on this as well, but I want to have a discussion with the rest IESG about Sean's point.  Given the issues raised during the deprecation of the RH0 routing header in IPv6 (RFC 5095), should the charter require that the security analysis for the two types of source routing be performed before any protocol work can be published?  This seems logical given the concerns raised.  It is not out of the ordinary given the restrictions that have been levied in other WG charters.
2013-10-24
00-17 Brian Haberman [Ballot Position Update] New position, Block, has been recorded for Brian Haberman
2013-10-24
00-17 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-10-24
00-17 Benoît Claise
[Ballot comment]
OLD:
In the context of this charter, 'source' means 'the point at which the explicit route is imposed.

NEW:
In the context of …
[Ballot comment]
OLD:
In the context of this charter, 'source' means 'the point at which the explicit route is imposed.

NEW:
In the context of this charter, 'source' means 'the point at which the explicit route is imposed'.

OLD:

filtering,  cryptographic

NEW
filtering, cryptographic

OLD:

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

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


- Some alignment issues with the Milestones

We might consider the comments above as trivial, but when I see alignment issues in the charter pages, and the charters are in THE contracts between the IESG and the WGs, I have the feeling that this doesn't look too professional.
Mea culpea: it even happens in one of my OPS charters, even if I tried hard to fix all issues.
2013-10-24
00-17 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-10-23
00-17 Ted Lemon
[Ballot comment]
I have yet to see a reason given why this is a good idea, but the routing guys seem to want it, and …
[Ballot comment]
I have yet to see a reason given why this is a good idea, but the routing guys seem to want it, and I think the security requirements in the charter are probably adequate, so I'm not going to block it.  I share Sean's concerns about security handwaving.
2013-10-23
00-17 Ted Lemon [Ballot Position Update] New position, Abstain, has been recorded for Ted Lemon
2013-10-23
00-17 Richard Barnes
[Ballot comment]
I agree with Sean's security concerns, especially given that security problems in the routing domain have often proven tricky to solve -- and …
[Ballot comment]
I agree with Sean's security concerns, especially given that security problems in the routing domain have often proven tricky to solve -- and even harder to solve post-hoc.
2013-10-23
00-17 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-10-23
00-17 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-10-23
00-17 Sean Turner
[Ballot comment]
Not blocking but I'm curious whether the security analysis has to be done before they get to bring the protocol to the IESG?  …
[Ballot comment]
Not blocking but I'm curious whether the security analysis has to be done before they get to bring the protocol to the IESG?  I'd hate to follow the normal path which is yeah yeah we'll do security, but we'll probably get distracted by this cool protocol work, and then loose energy and just pass the protocol to the IESG.
2013-10-23
00-17 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2013-10-23
00-17 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2013-10-23
00-17 Barry Leiba
[Ballot comment]
No objection to the charter text.  It's not clear, though, what the milestones are specifying.  For the documents, I presume it's the end …
[Ballot comment]
No objection to the charter text.  It's not clear, though, what the milestones are specifying.  For the documents, I presume it's the end of the process (publication requested).  For some of the milestones, though, is it possible to meet them with a working group consensus that does not turn into a document?
2013-10-23
00-17 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-10-23
00-17 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2013-10-23
00-17 Stewart Bryant New version available: charter-ietf-spring-00-17.txt
2013-10-23
00-16 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2013-10-23
00-16 Stewart Bryant Created "Approve" ballot
2013-10-23
00-16 Stewart Bryant State changed to IESG review from External review
2013-10-22
00-16 Stewart Bryant New version available: charter-ietf-spring-00-16.txt
2013-10-15
00-15 Cindy Morgan Telechat date has been changed to 2013-10-24 from 2013-10-10
2013-10-15
00-15 Cindy Morgan State changed to External review from Internal review
2013-10-15
00-15 Cindy Morgan WG review text was changed
2013-10-15
00-14 Cindy Morgan WG review text was changed
2013-10-14
00-15 Stewart Bryant New version available: charter-ietf-spring-00-15.txt
2013-10-14
00-14 Joel Jaeggli
[Ballot comment]
As a part
of its work, the working group will define the new
IPv6-based routing header in way that blind attacks
are never …
[Ballot comment]
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.
2013-10-14
00-14 Joel Jaeggli [Ballot Position Update] Position for Joel Jaeggli has been changed to No Objection from Block
2013-10-14
00-14 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Block
2013-10-14
00-14 Benoît Claise
[Ballot comment]
Thanks for addressing my BLOCK.

- The ability for a node to specify a forwarding path, other than the normal shortest path, that …
[Ballot comment]
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
2013-10-14
00-14 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Block
2013-10-14
00-14 Stewart Bryant New version available: charter-ietf-spring-00-14.txt
2013-10-11
00-13 Stewart Bryant New version available: charter-ietf-spring-00-13.txt
2013-10-11
00-12 Stewart Bryant New version available: charter-ietf-spring-00-12.txt
2013-10-10
00-11 Stewart Bryant New version available: charter-ietf-spring-00-11.txt
2013-10-10
00-10 Stewart Bryant New version available: charter-ietf-spring-00-10.txt
2013-10-10
00-09 Stewart Bryant New version available: charter-ietf-spring-00-09.txt
2013-10-10
00-08 Stewart Bryant New version available: charter-ietf-spring-00-08.txt
2013-10-10
00-07 Stephen Farrell
[Ballot comment]

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

I also reckon that packet injection …
[Ballot comment]

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.
2013-10-10
00-07 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-10-10
00-07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-10-10
00-07 Benoît Claise
[Ballot block]
- I've been trying very hard to understand this text, but failed:

    SPRING should both provide support for its use as …
[Ballot block]
- I've been trying very hard to understand this text, but failed:

    SPRING should both provide support for its use as
    an OAM tool in SPRING enabled networks, and the
    necessary OAM and other management tools needed to
    manage a SPRING enabled network.

"SPRING" as a subject, it's the meant as the WG, or the SPRING protocol? Note that there are other sentences starting with "SPRING"
Do you mean:

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

Which types of deliverables do you have mind?

- Considering the following text as the proposed milestones:

    The working group will develop the following documents:

    o One or more documents describing SPRING use cases.

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

    o Specification of any required new procedures to support
      SPRING use cases.

    o One or more data plane extension requirements documents,
      including documenting the impact on existing deployments
      of the existing data plane.

    o One or more control protocol extensions requirements
      documents.

    o Document inter-working and co-existence between the
      new procedures and the existing signalling and routing
      protocols.

    o Inter-operability reports pertaining to the implementation
      of extensions supporting SPRING.

My BLOCK is about: where is/are the deliverable(s) for this entry

    o Definition of requirements and/or management  plane
      mechanism needed to manage and operate a
      SPRING enabled network.
2013-10-10
00-07 Benoît Claise
[Ballot comment]
- The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, …
[Ballot comment]
- 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

- Please put the milestones in the proper section, not the charter text.
2013-10-10
00-07 Benoît Claise [Ballot Position Update] New position, Block, has been recorded for Benoit Claise
2013-10-10
00-07 Stewart Bryant New version available: charter-ietf-spring-00-07.txt
2013-10-10
00-06 Martin Stiemerling [Ballot comment]
Thanks to Adrian for reminding me to wear my other glasses :)
2013-10-10
00-06 Martin Stiemerling Ballot comment text updated for Martin Stiemerling
2013-10-10
00-06 Joel Jaeggli
[Ballot 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 …
[Ballot 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.
2013-10-10
00-06 Joel Jaeggli [Ballot Position Update] New position, Block, has been recorded for Joel Jaeggli
2013-10-09
00-06 Ted Lemon
[Ballot comment]
I agree with the point Jari raised in his block, and with Spencer's advice about how to handle the situation where work ought …
[Ballot comment]
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.
2013-10-09
00-06 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2013-10-09
00-06 Jari Arkko
[Ballot block]
Early in my AD career I had to deal with the RH0 situation, and we ended up deprecating it. Like we have, for …
[Ballot block]
Early in my AD career I had to deal with the RH0 situation, and we ended up deprecating it. Like we have, for all practical purposes, done with the similar IPv4 mechanisms. What had initially seen as simple and useful tools turned out to be far trickier than people believed. The RH0 deprecation was not merely an IETF action - we deployed emergency patches to many products, worried about people taking down networks, worried about code left in unupdated routers, and so on.

I am not opposed to dealing with new and better mechanisms for source routing. We've since then succeeded in defining very constrained source routing models (RH2, for instance) that do not have the same problems.

But if we do start the work, we need to take the concerns that torpedoed earlier designs seriously. I'll observe that the charter has no text about the security, denial-of-service, or perimeter security concerns. It also talks about cross-AS designs. And it paints a very powerful, flexible model that supports a number of different applications. The combination of having something that doesn't open up all kinds of vulnerabilities and is still flexible is particularly worrying.

I'd like to understand what is our plan to address this and and I'd like to see some words in the charter text to talk about this aspect.

Also, this text:

"Source-based routing mechanisms have previously been
specified for network protocols, but have not seen
widespread adoption other than in MPLS traffic engineering.
These applications may require greater flexibility and
per packet source imposed routing than can be achieved
through the use of the previously defined methods."

seems like it is saying that the lack of flexibility caused the mechanisms to be not used. I don't think that is what happened. It was more about the security headaches that they caused to network managers...
2013-10-09
00-06 Jari Arkko
[Ballot comment]
A colleague commented that service chaining is not listed as a motivation. Should be it be?

This text seemed somehow odd:

  "The …
[Ballot comment]
A colleague commented that service chaining is not listed as a motivation. Should be it be?

This text seemed somehow odd:

  "The SPRING working group will not work on any
  mechanisms for use in networks that forward IPv4 packets."

Did you mean that the mechanisms can only work in v6-only networks, or that the mechanisms support only v6 traffic? I think you want the latter, not the former...
2013-10-09
00-06 Jari Arkko [Ballot Position Update] New position, Block, has been recorded for Jari Arkko
2013-10-09
00-06 Brian Haberman
[Ballot comment]
I have no problems with this going to external review, but I think my English parser is broken.  The "and/or" construct in the …
[Ballot comment]
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).
2013-10-09
00-06 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-10-09
00-06 Pete Resnick
[Ballot comment]
Agreeing in part with Spencer's comment: Is there any reason *not* to ask the WG to recharter simply to add a work item …
[Ballot comment]
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.
2013-10-09
00-06 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-10-09
00-06 Martin Stiemerling
[Ballot comment]
I struggle to fully understand what application is meant in the below text (I am fully aware of the differences in what's an …
[Ballot comment]
I struggle to fully understand what application is meant in the below text (I am fully aware of the differences in what's an application in the app area and in routing):

  Source-based routing mechanisms have previously been
  specified for network protocols, but have not seen
  widespread adoption other than in MPLS traffic engineering.
  These applications may require greater flexibility and
  per packet source imposed routing than can be achieved
  through the use of the previously defined methods.

Especially, as the term applications isn't showing up before that sentence.
2013-10-09
00-06 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-10-08
00-06 Richard Barnes
[Ballot comment]
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 …
[Ballot comment]
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.
2013-10-08
00-06 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-10-07
00-06 Spencer Dawkins
[Ballot comment]
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 …
[Ballot comment]
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.
2013-10-07
00-06 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-10-07
00-06 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2013-10-07
00-06 Adrian Farrel
[Ballot comment]
I am balloting Yes, but assume this will go for external review.

Just some nits...

---

"per-flow state information " was probably my …
[Ballot comment]
I am balloting Yes, but assume this will go for external review.

Just some nits...

---

"per-flow state information " was probably my text.
Would "per-path state information" be better?

---

"is gained through a network"
Maybe "can be achieved in a network"

---

Formatting in the second bullet list seems to be off.

---

The final bullet list...
"The working group will develop the following documents:"
...can presumably be deleted and replaced with milestones.
2013-10-07
00-06 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2013-10-04
00-06 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-10-02
00-06 Stewart Bryant New version available: charter-ietf-spring-00-06.txt
2013-10-01
00-05 Stewart Bryant New version available: charter-ietf-spring-00-05.txt
2013-10-01
00-04 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2013-10-01
00-04 Stewart Bryant WG action text was changed
2013-10-01
00-04 Stewart Bryant WG review text was changed
2013-10-01
00-04 Stewart Bryant Created "Ready for external review" ballot
2013-10-01
00-04 Stewart Bryant State changed to Internal review from Informal IESG review
2013-10-01
00-04 Stewart Bryant Placed on agenda for telechat - 2013-10-10
2013-10-01
00-04 Stewart Bryant Responsible AD changed to Stewart Bryant
2013-10-01
00-04 Stewart Bryant New version available: charter-ietf-spring-00-04.txt
2013-09-30
00-03 Stewart Bryant New version available: charter-ietf-spring-00-03.txt
2013-09-23
00-02 Stewart Bryant New version available: charter-ietf-spring-00-02.txt
2013-09-23
00-01 Stewart Bryant New version available: charter-ietf-spring-00-01.txt
2013-09-20
00-00 Stewart Bryant Initial review time expires 2013-09-27
2013-09-20
00-00 Stewart Bryant State changed to Informal IESG review from Not currently under review
2013-09-20
00-00 Stewart Bryant New version available: charter-ietf-spring-00-00.txt