Source Packet Routing in Networking (SPRING) Problem Statement and Requirements
draft-ietf-spring-problem-statement-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-05-19
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-05-06
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-04-27
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-04-13
|
08 | (System) | RFC Editor state changed to EDIT |
2016-04-13
|
08 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-04-13
|
08 | (System) | Announcement was received by RFC Editor |
2016-04-13
|
08 | (System) | IANA Action state changed to No IC from In Progress |
2016-04-13
|
08 | (System) | IANA Action state changed to In Progress |
2016-04-13
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2016-04-13
|
08 | Amy Vezza | IESG has approved the document |
2016-04-13
|
08 | Amy Vezza | Closed "Approve" ballot |
2016-04-13
|
08 | Amy Vezza | Ballot approval text was generated |
2016-04-13
|
08 | Amy Vezza | Ballot writeup was changed |
2016-04-13
|
08 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2016-04-12
|
08 | Deborah Brungard | [Ballot comment] Thanks for addressing my Discuss and improving Section 3.3. I still find the various comparisons on using a distributed approach vs. a centralized … [Ballot comment] Thanks for addressing my Discuss and improving Section 3.3. I still find the various comparisons on using a distributed approach vs. a centralized controller as lacking in accuracy and a poor justification for SPRING. Just say simply you do not want to use a distributed control plane. This is not the first time that IETF had this requirement for one of their data planes. I won't block publication, so my "Abstain" position. |
2016-04-12
|
08 | Deborah Brungard | [Ballot Position Update] Position for Deborah Brungard has been changed to Abstain from Discuss |
2016-04-06
|
08 | Terry Manderson | [Ballot comment] Thank you for the update in addressing my concerns in this rev, clearing my DISCUSS. |
2016-04-06
|
08 | Terry Manderson | [Ballot Position Update] Position for Terry Manderson has been changed to No Objection from Discuss |
2016-04-06
|
08 | Stefano Previdi | New version available: draft-ietf-spring-problem-statement-08.txt |
2016-03-17
|
07 | Bruno Decraene | Added to session: IETF-95: spring Tue-1400 |
2016-03-02
|
07 | Stephen Farrell | [Ballot comment] Thanks for adding the new security considerations text. My take-away from that is: - The architecture needs to have a clearly defined … [Ballot comment] 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. |
2016-03-02
|
07 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2016-03-01
|
07 | Brian Haberman | [Ballot comment] Thank you for addressing the discuss points raised... I do not see a benefit in the publication of this document (or most problem … [Ballot comment] Thank you for addressing the discuss points raised... I do not see a benefit in the publication of this document (or most problem statement documents) as a standalone document. The type of justification provided in this document could easily exist as a section within a proposed solution. |
2016-03-01
|
07 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to Abstain from Discuss |
2016-03-01
|
07 | Benoît Claise | [Ballot comment] - 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. … [Ballot comment] - 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" |
2016-03-01
|
07 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2016-03-01
|
07 | Stefano Previdi | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2016-03-01
|
07 | Stefano Previdi | New version available: draft-ietf-spring-problem-statement-07.txt |
2016-02-04
|
06 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2016-02-04
|
06 | Stephen Farrell | [Ballot discuss] I concur with the other folks who've bemoaned the fact that the security considerations text is less comprehensive than the charter text. Which … [Ballot discuss] I concur with the other folks who've bemoaned the fact that the security considerations text is less comprehensive than the charter text. Which document in the WG will document the security issues with SPRING generally and which WG documents currently contain the kind of security analysis called for in the charter? (I had a quick look and didn't see anything obvious.) I'm making this a DISCUSS ballot on the assumption that we're better off having the "who's doing the work and where is it?" discussion now and not each time a document gets to the IESG without that work having been done. |
2016-02-04
|
06 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2016-02-04
|
06 | Joel Jaeggli | [Ballot comment] I find myself rather unsatisfied by The SPRING architecture SHOULD leverage the existing MPLS dataplane without any modification and leverage IPv6 … [Ballot comment] 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. |
2016-02-04
|
06 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2016-02-03
|
06 | Barry Leiba | [Ballot comment] I agree with Alia's comment, "This draft doesn't feel as if it will be a useful RFC in 2 years." I think this … [Ballot comment] I agree with Alia's comment, "This draft doesn't feel as if it will be a useful RFC in 2 years." I think this is an example of a document that should be kept within the working group and used to guide its progress, but that doesn't seem to be a good candidate for going into the RFC archival series. I don't think my view on this should get in the way of publication, and so my "abstain" position. |
2016-02-03
|
06 | Barry Leiba | [Ballot Position Update] New position, Abstain, has been recorded for Barry Leiba |
2016-02-03
|
06 | Ben Campbell | [Ballot 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 … [Ballot 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. |
2016-02-03
|
06 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2016-02-03
|
06 | Brian Haberman | [Ballot discuss] The following is a training review from the Suresh Krishnan (incoming INT AD) * Section 3.4 If the intent is to create a … [Ballot discuss] The following is a training review from the Suresh Krishnan (incoming INT AD) * Section 3.4 If the intent is to create a new RH type how will the interoperability or backward compatibility be possible? Specifically because intermediate nodes (that are segment routing hops) that encounter unknown RH types are required to drop the packet and send an ICMPv6 Parameter Problem back. * Security considerations In general this document does not talk anything about the security issues with IPv6 routing headers and how they would be avoided. e.g. The following paper describes an attack. [CanSecWest07] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest Security Conference 2007, April 2007. http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf I think the security considerations are very light and need to be greatly improved. |
2016-02-03
|
06 | Brian Haberman | Ballot discuss text updated for Brian Haberman |
2016-02-03
|
06 | Brian Haberman | [Ballot discuss] * Section 3.4 If the intent is to create a new RH type how will the interoperability or backward compatibility be possible? Specifically … [Ballot discuss] * Section 3.4 If the intent is to create a new RH type how will the interoperability or backward compatibility be possible? Specifically because intermediate nodes (that are segment routing hops) that encounter unknown RH types are required to drop the packet and send an ICMPv6 Parameter Problem back. * Security considerations In general this document does not talk anything about the security issues with IPv6 routing headers and how they would be avoided. e.g. The following paper describes an attack. [CanSecWest07] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest Security Conference 2007, April 2007. http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf I think the security considerations are very light and need to be greatly improved. |
2016-02-03
|
06 | Brian Haberman | [Ballot comment] * Section 2 This section talks about the Routing header defined in RFC2460 but does not mention that the RH0 has been deprecated … |
2016-02-03
|
06 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2016-02-03
|
06 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2016-01-31
|
06 | Deborah Brungard | IESG state changed to IESG Evaluation from IESG Evaluation - Defer |
2016-01-31
|
06 | Deborah Brungard | [Ballot comment] As others commented, the document is missing the identification of key requirements, “MUST”. The Abstract’s last sentence and Section 3.1 say the objective … [Ballot comment] As others commented, the document is missing the identification of key requirements, “MUST”. The Abstract’s last sentence and Section 3.1 say the objective is to address use cases where removal of signaling and path state in the core is a requirement. Yet, 3.1.1 and 3.2 only say it “SHOULD” work without the addition of a signaling protocol. If any requirement is a “MUST”, it would seem this requirement needs to be a “MUST”. There is no need to make statements that RSVP-TE is complex and not scalable to justify. Just say simply you do not want to use a distributed control plane for your problem. This is not the first time for this requirement. As for no need for state at transit nodes, it’s not quite true, as there probably is a need to map the SR “label” to a label stack instruction and a forwarding instruction. Hint, the “MUST” would be similar to MPLS-TP requirements [RFC5654], “SPRING MUST support the capability for network operation without the use of any control-plane protocols.” The interchangeability of the terms “SPRING” and “segment routing” are confusing. I think if you would clarify the control model, it may help with the definitions. Section 1: “allow optimal virtualization by putting policy state in the packet header” and “policy is completely virtualized away from midpoints and tail-ends” doesn’t parse. By definition, it’s not “virtual” if it’s in the packet header. Seems to be a marketing statement, not a technical requirement. Section 2: It seems the document is already defining the solution for IPv6 segment routing. It would help to say what is the actual requirement – packets should be forwarded transparently through a legacy v6 network? Identifiable by SPRING-capable devices? Section 3: These use cases appear to be defining desired capabilities for a controller, not SPRING. It would be helpful to clarify what are the requirements for the dataplane’s “simple support” e.g. section 3.2 on FRR appears to be requirements on the controller, not the dataplane. And 3.3.1.2.1 on a capacity planning process in the controller. Section 3.3 Traffic Engineering: While this is labelled Traffic Engineering, the examples are only on traffic placement. Only a subset of Traffic Engineering. The other key aspect of TE is resource reservation. The text should clarify and refer to traffic placement and not the general term “TE”. Section 3.3.1.1 are all load balancing examples – not “TE”. While valid and useful, should not confuse the reader that it is TE. Section 3.3.1.2.2 I don’t think everyone would agree that a stateful PCE is an SDN controller. I think there is some confusion, especially the next paragraph, on a controller vs. orchestrator. There’s a lot of marketing hype in this section, best would be to say something generic and what it is doing (technically) e.g. “centralized-based optimization” (next paragraph). The requirements in this section seem to be generic, not “SDN”. I don’t understand the last one, “no delay is introduced to programming the midpoints and tail-end along the path”. Compared to what? If a change, is there a change for traffic placement within the network? Before a change, there also is delay - the controller usually will sync with the current state of the network. This sounds marketing “highly responsive to change”. State the requirement for SPRING. Missing requirements: OAM, any requirements on limiting the increased headers and overall frame size? |
2016-01-31
|
06 | Deborah Brungard | Ballot comment text updated for Deborah Brungard |
2016-01-31
|
06 | Deborah Brungard | [Ballot comment] As others commented, the document is missing the identification of key requirements, “MUST”. The Abstract’s last sentence and Section 3.1 say the objective … [Ballot comment] As others commented, the document is missing the identification of key requirements, “MUST”. The Abstract’s last sentence and Section 3.1 say the objective is to address use cases where removal of signaling and path state in the core is a requirement. Yet, 3.1.1 and 3.2 only say it “SHOULD” work without the addition of a signaling protocol. If any requirement is a “MUST”, it would seem this requirement needs to be a “MUST”. There is no need to make statements that RSVP-TE is complex and not scalable to justify. Just say simply you do not want to use a distributed control plane for your problem. This is not the first time for this requirement. As for no need for state at transit nodes, it’s not quite true, as there probably is a need to map the SR “label” to a label stack instruction and a forwarding instruction. Hint, the “MUST” would be similar to MPLS-TP requirements [RFC5654], “SPRING MUST support the capability for network operation without the use of any control-plane protocols.” The interchangeability of the terms “SPRING” and “segment routing” are confusing. I think if you would clarify the control model, it may help with the definitions. Section 1: “allow optimal virtualization by putting policy state in the packet header” and “policy is completely virtualized away from midpoints and tail-ends” doesn’t parse. By definition, it’s not “virtual” if it’s in the packet header. Seems to be a marketing statement, not a technical requirement. Section 2: It seems the document is already defining the solution for IPv6 segment routing. It would help to say what is the actual requirement – packets should be forwarded transparently through a legacy v6 network? Identifiable by SPRING-capable devices? Section 3: These use cases appear to be defining desired capabilities for a controller, not SPRING. It would be helpful to clarify what are the requirements for the dataplane’s “simple support” e.g. section 3.2 on FRR appears to be requirements on the controller, not the dataplane. And 3.3.1.2.1 on a capacity planning process in the controller. Section 3.3 Traffic Engineering: While this is labelled Traffic Engineering, the examples are only on traffic placement. Only a subset of Traffic Engineering. The other key aspect of TE is resource reservation. The text should clarify and refer to traffic placement and not the general term “TE”. Section 3.3.1.1 are all load balancing examples – not “TE”. While valid and useful, should not confuse the reader that it is TE. Section 3.3.1.2.2 I don’t think everyone would agree that a stateful PCE is an SDN controller. I think there is some confusion, especially the next paragraph, on a controller vs. orchestrator. There’s a lot of marketing hype in this section, best would be to say something generic and what it is doing (technically) e.g. “centralized-based optimization” (next paragraph). The requirements in this section seem to be generic, not “SDN”. I don’t understand the last one, “no delay is introduced to programming the midpoints and tail-end along the path”. Compared to what? If a change, is there a change for traffic placement within the network? Before a change, there also is delay - the controller usually will sync with the current state of the network. This sounds marketing “highly responsive to change”. State the requirement for SPRING. Missing requirements: OAM, any requirements on limiting the increased headers and overall frame size? |
2016-01-31
|
06 | Deborah Brungard | Ballot comment text updated for Deborah Brungard |
2016-01-31
|
06 | Deborah Brungard | [Ballot discuss] The main focus of my discuss are the disparaging comments on MPLS and RSVP-TE for the apparent purpose of justifying the need for … [Ballot discuss] The main focus of my discuss are the disparaging comments on MPLS and RSVP-TE for the apparent purpose of justifying the need for SPRING. The statements in Section 3.3, paragraph 2, are not accurate. As an IETF document, even though Informational, it harms another IETF technology. This paragraph needs to be removed. Very disappointing to see this unfair comparison of centralized control vs. distributed control in an IETF document. |
2016-01-31
|
06 | Deborah Brungard | [Ballot comment] As others commented, the document is missing the identification of key requirements, “MUST”. The Abstract’s last sentence and Section 3.1 say the objective … [Ballot comment] As others commented, the document is missing the identification of key requirements, “MUST”. The Abstract’s last sentence and Section 3.1 say the objective is to address use cases where removal of signaling and path state in the core is a requirement. Yet, 3.1.1 and 3.2 only say it “SHOULD” work without the addition of a signaling protocol. If any requirement is a “MUST”, it would seem this requirement needs to be a “MUST”. There is no need to make statements that RSVP-TE is complex and not scalable to justify. Just say simply you do not want to use a distributed control plane for your problem. This is not the first time for this requirement. As for no need for state at transit nodes, it’s not quite true, as there probably is a need to map the SR “label” to a label stack instruction and a forwarding instruction. Hint, the “MUST” would be similar to MPLS-TP requirements [RFC5654], “SPRING MUST support the capability for network operation without the use of any control-plane protocols.” The interchangeability of the terms “SPRING” and “segment routing” are confusing. I think if you would clarify the control model, it may help with the definitions. Section 1: “allow optimal virtualization by putting policy state in the packet header” and “policy is completely virtualized away from midpoints and tail-ends” doesn’t parse. By definition, it’s not “virtual” if it’s in the packet header. Seems to be a marketing statement, not a technical requirement. Section 2: It seems the document is already defining the solution for IPv6 segment routing. It would help to say what is the actual requirement – packets should be forwarded transparently through a legacy v6 network? Identifiable by SPRING-capable devices? Section 3: These use cases appear to be defining desired capabilities for a controller, not SPRING. It would be helpful to clarify what are the requirements for the dataplane’s “simple support” e.g. section 3.2 on FRR appears to be requirements on the controller, not the dataplane. And 3.3.1.2.1 on a capacity planning process in the controller. Section 3.3 Traffic Engineering: While this is labelled Traffic Engineering, the examples are only on traffic placement. Only a subset of Traffic Engineering. The other key aspect of TE is resource reservation. The text should clarify and refer to traffic placement and not the general term “TE”. Section 3.3.1.1 are all load balancing examples – not “TE”. While valid and useful, should not confuse the reader that it is TE. Section 3.3.1.2.2 I don’t think everyone would agree that a stateful PCE is an SDN controller. I think there is some confusion, especially the next paragraph, on a controller vs. orchestrator. There’s a lot of marketing hype in this section, best would be to say something generic and what it is doing (technically) e.g. “centralized-based optimization” (next paragraph). The requirements in this section seem to be generic, not “SDN”. I don’t understand the last one, “no delay is introduced to programming the midpoints and tail-end along the path”. Compared to what? If a change, is there a change for traffic placement within the network? Before a change, there also is delay - the controller usually will sync with the current state of the network. This sounds marketing “highly responsive to change”. State the requirement for SPRING. Missing requirements: OAM, any requirements on limiting the increased headers and overall frame size? |
2016-01-31
|
06 | Deborah Brungard | [Ballot Position Update] New position, Discuss, has been recorded for Deborah Brungard |
2016-01-25
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Tim Chown. |
2016-01-22
|
06 | Benoît Claise | [Ballot comment] - 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. … [Ballot comment] - 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" - The SPRING architecture SHOULD support traffic engineering, including: To be consistent with the two previous use cases, I guess you want: The SPRING architecture SHOULD support the following traffic engineering, requirements: Otherwise, it seems that TE is an optional use case, which somehow contradicts: In this context, Source Packet Routing in Networking (SPRING) architecture is being defined in order to address the use cases and requirements described in this document. =============================================================== Now updated with Tim Chown's OPS DIR review: Overall this document is quite close to being ready, but I have a few comments below for consideration by the AD / authors. This draft is a problem statement (in the form of a number of use cases) and a set of requirements for Source Packet Routing in Networks (SPRING) or, as it is otherwise known, Segment Routing. It is one of a large number of active documents in the SPRING WG, as listed at https://tools.ietf.org/wg/spring/. These include forays into solution space (e.g. the IPv6 SRH, tagged as a 6man draft) and the SPRING architecture, which can be found at https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07. There is clearly significant interest in the IETF in developing the SR architecture(s) and solutions. The work in SPRING is already quite advanced, and thus one might query the value of extensive effort in nailing down the problem statement and requirements. However, I feel it is proper that the WG should ensure that the basis for their published solutions has been through an appropriate consensus process, esp. should the rationale for certain requirements need to be revisited in the future. In that light, the document feels somewhat ânote formâ, in that requirements are scattered through the discussed use cases, and many are not explained in any detail (presumably as the authors assume certain level knowledge from those in the WG), e.g. what is meant by âshared risk constraintsâ? The terminology could be better explained, for a broader audience, and to reduce any potential ambiguity. The requirements take the form of (depending on how you count them) 32 SHOULDs, and there are, perhaps a little surprisingly, no MUSTs. Are the authors confident that every SHOULD is just that, and that there are no mandatory requirements? I might have queries over certain capabilities (implementations of requirements) in the document, e.g. insertion / removal of IPv6 SRHs, but I think itâs better that this document avoids drifting into discussing potential solution spaces. The Security Considerations section is quite light, though it does contain one SHOULD. I assume more detailed security discussion is to be contained in the solution documents, although I note that the Security Considerations section of the architecture document is also very brief. |
2016-01-22
|
06 | Benoît Claise | Ballot comment text updated for Benoit Claise |
2016-01-20
|
06 | Deborah Brungard | Telechat date has been changed to 2016-02-04 from 2016-01-21 |
2016-01-20
|
06 | Deborah Brungard | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2016-01-20
|
06 | Alissa Cooper | [Ballot comment] (1) I'm surprised that almost all of the requirements in this document are SHOULDs, since they mostly apply to an architecture and not … [Ballot comment] (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. |
2016-01-20
|
06 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2016-01-20
|
06 | Alia Atlas | [Ballot comment] A terminology section and describing at all the bullets of desired functionality would improve the readability. This draft doesn't feel as if it … [Ballot comment] 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. |
2016-01-20
|
06 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2016-01-18
|
06 | Terry Manderson | [Ballot discuss] Thanks for putting in the effort in writing this. Firstly, I concur with Benoit's observation about text taken from the charter and laid … [Ballot discuss] Thanks for putting in the effort in writing this. Firstly, I concur with Benoit's observation about text taken from the charter and laid in to the document verbatim. That tends not to help the reader and a large assumption is made that the reader understands the concerns of source based routing for partitioning VPNs, fast re-route, TE, signalling, and so on. Please consider rewriting the intro and other parts to help with understanding (for example in 3.2 Fast Reroute; microploop avoidance is listed as a requirement, however a sensible coverage of microloop avoidance is not found in the draft, nor in the nearby referenced spring-resiliency-use-cases). This also leaves me scratching my head as to why we don't see this document and the resiliency-use-cases (and others) at the same time when they are aligned? Or restructure the document to be more informative on these facets in the first case. Can the document also be explicit that while the SPRING problem/solution space needs to be cognisant of autonomous systems that share policy/interoperate across boundaries the primary port of call is in regard to the IGP. This will certainly aide in restraining everyone (esp. the reader) from trying to boil the 'internet ocean'. (this at least should be easy to address :) |
2016-01-18
|
06 | Terry Manderson | [Ballot Position Update] New position, Discuss, has been recorded for Terry Manderson |
2016-01-18
|
06 | Benoît Claise | [Ballot discuss] I would like to discuss this point with the responsible area director during the telechat. No action from the authors is required on … [Ballot discuss] I would like to discuss this point with the responsible area director during the telechat. No action from the authors is required on this point at this point. The manageability considerations section is a direct cut/paste from a charter (i.e. minimal effort) + two informative references to drafts, not even WG docs. What are we suppose to conclude from this, in terms of manageability requirements? |
2016-01-18
|
06 | Benoît Claise | Ballot discuss text updated for Benoit Claise |
2016-01-18
|
06 | Benoît Claise | [Ballot discuss] I would like to discuss this point with the responsible area director during the telechat. No action from the authors is required on … [Ballot discuss] I would like to discuss this point with the responsible area director during the telechat. No action from the authors is required on this point at this point. The manageability considerations section is a direct cut/paste from a charter (i.e. minimal effort) + two informative references to drafts, not even WG docs. What are we suppose to conclude from this? |
2016-01-18
|
06 | Benoît Claise | [Ballot comment] - 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. … [Ballot comment] - 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" - The SPRING architecture SHOULD support traffic engineering, including: To be consistent with the two previous use cases, I guess you want The SPRING architecture SHOULD support the following traffic engineering, requirements: Otherwise, it seems that TE is an optional use case, which somehow contradicts: In this context, Source Packet Routing in Networking (SPRING) architecture is being defined in order to address the use cases and requirements described in this document. |
2016-01-18
|
06 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2016-01-16
|
06 | Meral Shirazipour | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2016-01-15
|
06 | Meral Shirazipour | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2016-01-14
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2016-01-14
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Meral Shirazipour |
2016-01-07
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Klaas Wierenga. |
2016-01-05
|
06 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
2016-01-05
|
06 | Alvaro Retana | Ballot has been issued |
2016-01-05
|
06 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2016-01-05
|
06 | Alvaro Retana | Created "Approve" ballot |
2016-01-05
|
06 | Alvaro Retana | Ballot writeup was changed |
2016-01-05
|
06 | Alvaro Retana | Ballot approval text was generated |
2016-01-05
|
06 | Alvaro Retana | Changed consensus to Yes from Unknown |
2016-01-05
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-12-28
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-12-28
|
06 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-spring-problem-statement-06.txt, which is currently in Last Call, and has the following comments: We understand that this … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-spring-problem-statement-06.txt, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal IANA Specialist ICANN |
2015-12-22
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2015-12-22
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2015-12-19
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2015-12-19
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2015-12-17
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2015-12-17
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2015-12-16
|
06 | Pierre Francois | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational as indicated in the title page header. This type of RFC is relevant for problem statement and requirements documents. (2a) Technical Summary: This document lists requirements and main use-cases to be considered in the design of architectures aimed at reaching the goals of the SPRING working group. It highlights the importance of supporting both MPLS and IPv6 data-planes in SPRING solutions. It provides a description of use cases (TE, FRR, Disjoint services, …) and associated requirements, illustrating the expected behavior of a network supporting such use cases. Detailed documents focusing on specific use-cases have been proposed to the WG (Resiliency, OAM), and this document refers to them (as informative references). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document is actually a solution to a controversy at the early days of SPRING, where problem description and solutions were tied in single documents. Debates on the content were numerous and vivid. After going back over all the threads related to this document, I found no items for which consensus was particularly rough. Document Quality: Are there existing implementations of the protocol? There is no protocol proposal in this document. Have a significant number of vendors indicated their plan to implement the specification? A large number of vendors have supported the adoption of this draft. A large number of vendors co-author drafts proposing solutions to this problem statement. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Yakov Rekhter has provided substantial comments on the Spring ML, aimed at removing parts of the document that were still oriented towards a solution proposal. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Pierre Francois (myself). It was Alvaro Retana initially, but he became the responsible Area Director, and I inherited the Shepherding task. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Back in October 2014, the main concerns of the Document Shepherd (Alvaro Retana) were that some references were still made to an architecture proposal, although this document cannot pre-suppose that the working group works on an existing proposal. The SPRING working group seems to be discussing and reaching consensus on a single proposal rather than letting multiple independent proposals compete, and I think it led the authors to making that mistake. This has been corrected since then. A lot of terminology was used without reference and Alvaro insisted on this being solved, aside other editorial comments. These comments have been dealt with. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I don’t see any. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors have declared they were not aware of any IPR related to this draft, on the Spring ML. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document received strong support from many members of the WG (30+ support emails during call for WG adoption, after many discussions on its content). (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. Outdated references: I-D.geib-spring-oam-usecase should be draft-ietf-spring-oam-usecase-01 I-D.kumar-spring-sr-oam-requirement should be draft-ietf-spring-sr-oam-requirement-00 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. I don’t think this applies to this doc. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are RFC’s. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does no change the status of any existing RFC. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document does not request IANA allocations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2015-12-15
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-12-15
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: pifranco@cisco.com, aretana@cisco.com, draft-ietf-spring-problem-statement@ietf.org, spring-chairs@ietf.org, spring@ietf.org Reply-To: ietf@ietf.org … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: pifranco@cisco.com, aretana@cisco.com, draft-ietf-spring-problem-statement@ietf.org, spring-chairs@ietf.org, spring@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (SPRING Problem Statement and Requirements) to Informational RFC The IESG has received a request from the Source Packet Routing in Networking WG (spring) to consider the following document: - 'SPRING Problem Statement and Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-01-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption. In this context, the term 'source' means 'the point at which the explicit route is imposed' and therefore it is not limited to the originator of the packet (i.e.: the node imposing the explicit route may be the ingress node of an operator's network). This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use- cases and requirements are out of scope of this document. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-12-15
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-12-15
|
06 | Alvaro Retana | Placed on agenda for telechat - 2016-01-21 |
2015-12-15
|
06 | Alvaro Retana | Last call was requested |
2015-12-15
|
06 | Alvaro Retana | Ballot approval text was generated |
2015-12-15
|
06 | Alvaro Retana | Ballot writeup was generated |
2015-12-15
|
06 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-12-15
|
06 | Alvaro Retana | Last call announcement was changed |
2015-12-15
|
06 | Alvaro Retana | Last call announcement was generated |
2015-12-15
|
06 | Alvaro Retana | Last call announcement was generated |
2015-12-14
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-12-14
|
06 | Stefano Previdi | New version available: draft-ietf-spring-problem-statement-06.txt |
2015-12-10
|
05 | Alvaro Retana | AD Review: I just finished reviewing this document. I do have some comments (below); I don't think any of them can be called a "show … AD Review: I just finished reviewing this document. I do have some comments (below); I don't think any of them can be called a "show stopper", but I would like to the an updated draft before starting the IETF Last Call. Thanks! Alvaro. Major: Section 4. (Security Considerations). I think the first paragraph is not strict enough: "…trust boundaries should strip explicit routes from a packet". I think you should be more prescriptive and s/should/SHOULD. Minor: (1) Please add references for these: "tunnel services (VPN, VPLS, VPWS)" "Traffic Engineering has been addressed using IGP protocol extensions (for resources information propagation) and RSVP-TE for signaling explicit paths." "next-hop-self" (2) Please expand on first use: FRR, PCE. (3) Section 2. (Dataplanes) I find the IPv6 paragraph unnecessary because it goes into what the solution could look like. Instead, it might be more appropriate for this document to point at further IPv6 requirements (draft-ietf-spring-ipv6-use-cases). (4) Section 3.3. (Traffic Engineering) Without talking about the solution, you might need to expand a little on these requirements: "egress peering traffic engineering" (a reference to Section 3.3.1.1.2 should be enough) (5) The text in Section 3.3.1.1.1. (Disjointness in dual-plane networks) which describes Figure 2 starts talking about "access region", but the figure (and the later text) use "aggregation region" (6) In Section 3.3.1.1.3. (Load-balancing among non-parallel links), do you mean unequal-cost paths when you use "non-parallel links"? If so, then using unequal-cost may be clearer. (7) Section 3.3.1.2.2. (SDN/SR use-case) - There are several references in this section to potential pieces of a solution that would incorporate a controller and SR: PCE, BGP-LS, i2rs, etc. I think that those pieces of a system are outside the scope of this use cases document. (8) Section 3.4. (Interoperability with non-SPRING nodes) What does "inter-operate with non-SPRING nodes" mean? It is part of a normative statement, but there's no explanation of what the real requirement is. Nits: The 3 paragraphs in Section 3.1. (IGP-based MPLS Tunneling) say (almost) the same thing — delete one. |
2015-12-10
|
05 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2015-12-10
|
05 | Alvaro Retana | Notification list changed to aretana@cisco.com |
2015-12-09
|
05 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2015-11-01
|
05 | John Scudder | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational as indicated in the title page header. This type of RFC is relevant for problem statement and requirements documents. (2a) Technical Summary: This document lists requirements and main use-cases to be considered in the design of architectures aimed at reaching the goals of the SPRING working group. It highlights the importance of supporting both MPLS and IPv6 data-planes in SPRING solutions. It provides a description of use cases (TE, FRR, Disjoint services, …) and associated requirements, illustrating the expected behavior of a network supporting such use cases. Detailed documents focusing on specific use-cases have been proposed to the WG (Resiliency, OAM), and this document refers to them (as informative references). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document is actually a solution to a controversy at the early days of SPRING, where problem description and solutions were tied in single documents. Debates on the content were numerous and vivid. After going back over all the threads related to this document, I found no items for which consensus was particularly rough. Document Quality: Are there existing implementations of the protocol? There is no protocol proposal in this document. Have a significant number of vendors indicated their plan to implement the specification? A large number of vendors have supported the adoption of this draft. A large number of vendors co-author drafts proposing solutions to this problem statement. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? Yakov Rekhter has provided substantial comments on the Spring ML, aimed at removing parts of the document that were still oriented towards a solution proposal. If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? N/A Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Pierre Francois (myself). It was Alvaro Retana initially, but he became the responsible Area Director, and I inherited the Shepherding task. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Back in October 2014, the main concerns of the Document Shepherd (Alvaro Retana) were that some references were still made to an architecture proposal, although this document cannot pre-suppose that the working group works on an existing proposal. The SPRING working group seems to be discussing and reaching consensus on a single proposal rather than letting multiple independent proposals compete, and I think it led the authors to making that mistake. This has been corrected since then. A lot of terminology was used without reference and Alvaro insisted on this being solved, aside other editorial comments. These comments have been dealt with. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I don’t see any. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors have declared they were not aware of any IPR related to this draft, on the Spring ML. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document received strong support from many members of the WG (30+ support emails during call for WG adoption, after many discussions on its content). (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There is 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 5735 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Outdated references: A later version (-06) exists of draft-geib-spring-oam-usecase-04 A later version (-11) exists of draft-ietf-idr-ls-distribution-10 A later version (-06) exists of draft-ietf-pce-segment-routing-03 I-D.crabbe-pce-pce-initiated-lsp should be draft-ietf-pce-pce-initiated-lsp-04. I-D.kumar-spring-sr-oam-requirement should be draft-ietf-spring-sr-oam-requirement-00 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. I don’t think this applies to this doc. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All normative references are RFC’s. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does no change the status of any existing RFC. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document does not request IANA allocations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2015-11-01
|
05 | John Scudder | Responsible AD changed to Alvaro Retana |
2015-11-01
|
05 | John Scudder | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2015-11-01
|
05 | John Scudder | IESG state changed to Publication Requested |
2015-11-01
|
05 | John Scudder | IESG process started in state Publication Requested |
2015-10-19
|
05 | Stefano Previdi | New version available: draft-ietf-spring-problem-statement-05.txt |
2015-10-14
|
04 | (System) | Notify list changed from "Pierre Francois" to (None) |
2015-10-05
|
04 | Pierre Francois | Changed document writeup |
2015-09-08
|
04 | Bruno Decraene | Notification list changed to "Pierre Francois" <pifranco@cisco.com> |
2015-09-08
|
04 | Bruno Decraene | Document shepherd changed to Pierre Francois |
2015-06-16
|
04 | John Scudder | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2015-04-27
|
04 | Stefano Previdi | New version available: draft-ietf-spring-problem-statement-04.txt |
2014-10-23
|
03 | Stefano Previdi | New version available: draft-ietf-spring-problem-statement-03.txt |
2014-10-07
|
02 | Alvaro Retana | Document shepherd changed to Alvaro Retana |
2014-10-01
|
02 | Stefano Previdi | New version available: draft-ietf-spring-problem-statement-02.txt |
2014-09-23
|
01 | Alvaro Retana | IETF WG state changed to In WG Last Call from WG Document |
2014-06-26
|
01 | Stefano Previdi | New version available: draft-ietf-spring-problem-statement-01.txt |
2014-06-05
|
00 | Alvaro Retana | Intended Status changed to Informational from None |
2014-06-05
|
00 | Alvaro Retana | This document now replaces draft-previdi-spring-problem-statement instead of None |
2014-05-13
|
00 | Stefano Previdi | New version available: draft-ietf-spring-problem-statement-00.txt |