Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures
RFC 4929
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
08 | (System) | Notify list changed from loa@pi.se,adrian@olddog.co.uk,swallow@cisco.com,dbrungard@att.com,fenner@research.att.com,rcallon@juniper.net,Kireeti@juniper.net,zinin@psg.com,sob@harvard.edu to swallow@cisco.com, zinin@psg.com, fenner@research.att.com, sob@harvard.edu, rcallon@juniper.net, Kireeti@juniper.net |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the No Objection position for Mark Townsley |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the No Objection position for Sam Hartman |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the No Objection position for Ted Hardie |
2007-06-28 |
08 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2007-06-28 |
08 | Amy Vezza | [Note]: 'RFC 4929, BCP 0129' added by Amy Vezza |
2007-06-26 |
08 | (System) | RFC published |
2007-03-27 |
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-03-19 |
08 | (System) | IANA Action state changed to No IC from In Progress |
2007-03-19 |
08 | (System) | IANA Action state changed to In Progress |
2007-03-18 |
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-03-18 |
08 | Amy Vezza | IESG has approved the document |
2007-03-18 |
08 | Amy Vezza | Closed "Approve" ballot |
2007-03-18 |
08 | Brian Carpenter | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Brian Carpenter |
2007-03-18 |
08 | Mark Townsley | [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Discuss by Mark Townsley |
2007-03-18 |
08 | Mark Townsley | [Ballot discuss] Section 2.1.2 states: > The procedures in this document assume that the CCAMP working group > remains the authority on GMPLS technologies, … [Ballot discuss] Section 2.1.2 states: > The procedures in this document assume that the CCAMP working group > remains the authority on GMPLS technologies, but acknowledges that However, you also have this mostly new paragraph in section 7 which seems a bit more ambiguous: > The architectural implications of additions or changes to the (G)MPLS > protocols MUST consider interoperability with existing and future > versions of the protocols. The effects of adding features that > overlap, or that deal with a point solution and are not general, are > much harder to control with rules and risk impacting the protocol as > a whole. Therefore to minimize operational and technical risks to the > (G)MPLS technology, IETF processes SHALL be followed for any requests > on extensions to (G)MPLS protocols. With respect to (G)MPLS > protocols, the (G)MPLS PSWG is the chartered "owner" of the (G)MPLS > protocol, as long as the working group exists. All changes or > extensions to (G)MPLS MUST first be reviewed by the (G)MPLS PSWG. Please clarify for me whether you mean that ccamp is the "owner" for (G)MPLS changes, or if "(G)MPLS PSWG" is being used as a token for any working group is chartered to extend (G)MPLS protocols. e.g., could the "(G)MPLS PSWG" be PWE3 in some cases here? |
2007-03-18 |
08 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Undefined by Cullen Jennings |
2007-03-18 |
08 | Brian Carpenter | [Ballot comment] s/thatmay/that may > In the event that the IETF agrees to develop a solution, the IETF > will set milestones that would … [Ballot comment] s/thatmay/that may > In the event that the IETF agrees to develop a solution, the IETF > will set milestones that would result in timely delivery of the > solution in a timely manner. Redundant use of "timely" clause. > evaluated by the IETF, and MUST deliver a response to the per s/to the per/ per ?? |
2007-03-13 |
08 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie |
2007-03-13 |
08 | Sam Hartman | [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman |
2007-03-02 |
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-03-02 |
08 | (System) | New version available: draft-andersson-rtg-gmpls-change-08.txt |
2007-01-11 |
08 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2007-01-11 |
08 | Bill Fenner | [Ballot Position Update] New position, Recuse, has been recorded by Bill Fenner |
2007-01-11 |
08 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by IESG Secretary |
2007-01-11 |
08 | Mark Townsley | [Ballot discuss] I understand the motivation behind this document with respect to interaction with other SDOs, and am not opposed to defining a formal procedure … [Ballot discuss] I understand the motivation behind this document with respect to interaction with other SDOs, and am not opposed to defining a formal procedure for those SDOs that want to see one (because, of course, if they want to ignore us there is nothing much other than their own honor to stop them). However, the document needs to clarify rather than confuse, and should not vary exceptionally from our base processes and current practices (to do so for every technology group in the IETF simply does not scale). As far as I can tell, the procedures defined in this document are not an accurate reflection of how we have been operating for a number of years, and publishing it in its current form and liaised to another SDO would simply embarrass us in the face of even a light-handed check on whether we practice what we preach. In general, I suggest a very different tone for this document. One that uses a lot less normative language, and is far lighter on additional process. I would personally be much happier if it were directed specifically at external SDOs rather than treating internal and external process as one in the same. The introduction claims that the procedures defined in this document do not violate RFC2026 or RFC2418, but this is not true in a number of areas in the document. Sam captures these issues well in his DISCUSS, which I will try not to repeat in mine. Brian's suggested way forward (checked in as a comment in the tracker) addresses a number of my specific concerns (and concerns of other affected parties) brought up in email discussions on this document and should be incorporated as well. In addition, I would like to point out: - The document seems to weigh heavily on use of requirements document for any change to GMPLS, and forces that a requirements document be approved by the IESG before work on solutions can begin. Requirements documents are but one tool in our arsenal of understanding a problem sufficiently for it to be solved, and do not always need to be published as separate documents or at all. - Section 6 discusses abandonment of solutions work, stating that in the event solutions work is abandoned the "originators of the requirements statement I-D" MUST be informed. Often, particularly in long drawn out work that is abandoned, the "originators" are either unknown, no longer exist (in the case of an SDO or organization), or are not involved enough with the work to know or care about its abandonment. Further, institutional memory may not be able to accurately recall who or what the originators were. It's understandable to want to close the loop here, but it is unrealistic to put a finger on what an "originator" is over a very long period of time. For internal IETF purposes, an email to the mailing list, LC to the main IETF list, etc. should be sufficient to notify all concerned (probably what we would do anyway, though this is not written down as far as I know). If the purpose behind this section was to define a process for notifying external SDOs or organizations, I would recommend that when the WG is (re)chartered based on external SDO activity, a mention of any concerned SDOs be recorded in the charter at that time. Then, if work is abandoned a liaison is sent to any listed SDOs or external parties of concern. This will not leave people guessing as to who the "originators" are (something that is not only annoying for the folks in charge at the time, but something that could lead to ugly appeal situations if one of the "originators" is somehow missed). I don't think that "solution abandonment" or "how best to garbage collect abandoned work" is something that is very well defined in the IETF, but perhaps it should be. I would argue that this is an effort best solved in a general sense rather than for one specific piece of technology. The minimal action item for this point is to (1) define what an "originator" is, (2) define when it is necessary to followup with an "originator" (e.g., if the originator is the IETF, you cannot add additional procedure for notifying the IETF without modifying the current IETF process), (3) state where the "originator" is recorded so that it can be followed up in the future in the event work is abandoned. Or, simply remove this and help start work on a wider-scoped IETF effort for this (I'd be happy to help in that regard). - Section 5: Defining specific text to select for requirements ID rejection by each and every major technology component in the IETF simply does not scale. If we are going to laden ourselves with additional procedures, I would much rather see them applied consistently (perhaps with tool support, etc.) than as one-offs for each set of protocols. - The security considerations section correctly identifies that the IETF process, like any process, is subject to a denial of service attack. I do not agree with the assessment that, if these procedures were truly followed for all internal and external changes to GMPLS that it would not pose a DOS attack on the process. There is ample evidence that the process as it stands today does not move as swiftly as it should, I see nothing in this document that will do anything other than exacerbate the problem. In addition, it is not mentioned that additional procedures are potential for additional process appeal in the event that the process is not (inadvertently or otherwise) followed. Appeals are one of the most vulnerable points for DOS of the IESG and IAB, and the more process hoops we have to jump through, the more chance we have of missing one even if we are acting in good faith and to the best benefit of the community and Internet. I will add that the example given at the end of section 8 makes it even more clear to me that this document is targeted more to external SDOs than internal process, something that I wish the document would simply be up front about from the start. |
2007-01-11 |
08 | Mark Townsley | [Ballot discuss] I understand the motivation behind this document with respect to interaction with other SDOs, and am not opposed to defining a formal procedure … [Ballot discuss] I understand the motivation behind this document with respect to interaction with other SDOs, and am not opposed to defining a formal procedure for those SDOs that want to see one (because, of course, if they want to ignore us there is nothing much other than their own honor to stop them). However, the document needs to clarify rather than confuse, and should not vary exceptionally from our base processes and current practices (to do so for every technology group in the IETF simply does not scale). As far as I can tell, the procedures defined in this document are not an accurate reflection of how we have been operating for a number of years, and publishing it in its current form and liaised to another SDO would simply embarrass us in the face of even a light-handed check on whether we practice what we preach. In general, I suggest a very different tone for this document. One that uses a lot less normative language, and is far lighter on additional process. I would personally be much happier if it were directed specifically at external SDOs rather than treating internal and external process as one in the same. The introduction claims that the procedures defined in this document do not violate RFC2026 or RFC2418, but this is not true in a number of areas in the document. Sam captures these issues well in his DISCUSS, which I will try not to repeat in mine. Brian's suggested way forward (checked in as a comment in the tracker) addresses a number of my specific concerns (and concerns of other affected parties) brought up in email discussions on this document and should be incorporated as well. In addition, I would like to point out: - The document seems to weigh heavily on use of requirements document for any change to GMPLS, and forces that a requirements document be approved by the IESG before work on solutions can begin. Requirements documents are but one tool in our arsenal of understanding a problem sufficiently for it to be solved, and do not always need to be published as separate documents or at all. - Section 6 discusses abandonment of solutions work, stating that in the event solutions work is abandoned the "originators of the requirements statement I-D" MUST be informed. Often, particularly in long drawn out work that is abandoned, the "originators" are either unknown, no longer exist (in the case of an SDO or organization), or are not involved enough with the work to know or care about its abandonment. Further, institutional memory may not be able to accurately recall who or what the originators were. It's understandable to want to close the loop here, but it is unrealistic to put a finger on what an "originator" is over a very long period of time. For internal IETF purposes, an email to the mailing list, LC to the main IETF list, etc. should be sufficient to notify all concerned (probably what we would do anyway, though this is not written down as far as I know). If the purpose behind this section was to define a process for notifying external SDOs or organizations, I would recommend that when the WG is (re)chartered based on external SDO activity, a mention of any concerned SDOs be recorded in the charter at that time. Then, if work is abandoned a liaison is sent to any listed SDOs or external parties of concern. This will not leave people guessing as to who the "originators" are (something that is not only annoying for the folks in charge at the time, but something that could lead to ugly appeal situations if one of the "originators" is somehow missed). I don't think that "solution abandonment" or "how to best to garbage collect abandoned work" is something that is very well defined in the IETF, but perhaps it should be. I would argue that this is an effort best solved in a general sense rather than for one specific piece of technology. The minimal action item for this point is to (1) define what an "originator" is, (2) define when it is necessary to followup with an "originator" (e.g., if the originator is the IETF, you cannot add additional procedure for notifying the IETF without modifying the current IETF process), (3) state where the "originator" is recorded so that it can be followed up in the future in the event work is abandoned. Or, simply remove this and help start work on a wider-scoped IETF effort for this (I'd be happy to help in that regard). - Section 5: Defining specific text to select for requirements ID rejection by each and every major technology component in the IETF simply does not scale. If we are going to laden ourselves with additional procedures, I would much rather see them applied consistently (perhaps with tool support, etc.) than as one-offs for each set of protocols. - The security considerations section correctly identifies that the IETF process, like any process, is subject to a denial of service attack. I do not agree with the assessment that, if these procedures were truly followed for all internal and external changes to GMPLS that it would not pose a DOS attack on the process. There is ample evidence that the process as it stands today does not move as swiftly as it should, I see nothing in this document that will do anything other than exacerbate the problem. In addition, it is not mentioned that additional procedures are potential for additional process appeal in the event that the process is not (inadvertently or otherwise) followed. Appeals are one of the most vulnerable points for DOS of the IESG and IAB, and the more process hoops we have to jump through, the more chance we have of missing one even if we are acting in good faith and to the best benefit of the community and Internet. I will add that the example given at the end of section 8 makes it even more clear to me that this document is targeted more to external SDOs than internal process, something that I wish the document would simply be up front about from the start. |
2007-01-11 |
08 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-01-11 |
08 | Dan Romascanu | [Ballot comment] I agree with many of the concerns expressed in the DISCUSSes written by Ted and Sam. Although the document declares that it adheres … [Ballot comment] I agree with many of the concerns expressed in the DISCUSSes written by Ted and Sam. Although the document declares that it adheres to the existing IETF process it seems to be extending it for a specific family of protocols and create new functions and terminology that at best make the process more complex. In particular I do not understand why the procedures in the document do not refer to the existing procedures for BOFs, and why there is a need to define a Caretaker function. |
2007-01-11 |
08 | Lars Eggert | [Ballot comment] I strongly agree with a lot of Sam's concerns. |
2007-01-10 |
08 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from No Objection by Cullen Jennings |
2007-01-10 |
08 | Brian Carpenter | [Ballot comment] Dummy comment to check a tracker feature |
2007-01-10 |
08 | Sam Hartman | [Ballot discuss] This is a long discuss. First, Brian has proposed directions forward; this discuss assumes that all of his changes are adopted and builds … [Ballot discuss] This is a long discuss. First, Brian has proposed directions forward; this discuss assumes that all of his changes are adopted and builds from there. I think his changes are a critical first step. My discuss has a few basic concerns: 1) The document claims not to change IETF process but actually does. 2) The document attempts to describe a finite set of outcomes of IETF processes that are not so limited. 3) The document inaccurately describes existing process. The IETF will not endorse the publication of any MPLS or GMPLS protocol or technology extensions in RFCs or other documents where the process described here has not been followed. If publication of individual Internet-Drafts describing extensions or changes to the MPLS or GMPLS protocols is requested of the RFC Editor the documents will be returned to the process described in this document using the mechanism described in [RFC3932]. s/will be returned/may be returned/ We'll follow RFC 3932; sometimes that allows us to return things sometimes not. The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have been chartered to specify a limited number of solutions for Provider Provisioned VPNs. Both working groups are in the Internet Area. The work of the L2VPN and L3VPN working groups does not include specifying new protocols, however, protocol changes and extensions to the (G)MPLS protocols may be needed. If so, the procedures specified in this document are applicable. Perhaps may be applicable given Brian's change to the introduction. The Pseudo Wire Emulation End to End (PWE3) working group is another working group in the Internet Area that also uses the (G)MPLS protocols in its specifications. Should the PWE3 specifications require extension or changes to the (G)MPLS protocols the procedures specified in this document are applicable. First, they already have extended LDP. Again may be applicable. I'd really like it if section 3 avoided lower case must; it sounds too normative. That's a comment though not a discuss. Anyone who intends to use one of the existing (G)MPLS protocols, but thinks that it will not satisfy their needs MUST use the procedures described in this document. Changes or extensions to the (G)MPLS protocols MUST NOT be made by any other mechanism. The IETF MUST NOT endorse any publications (including RFCs whether on the Standards Track, Informational, or Experimental) that change or extended the (G)MPLS protocols except for those that arise through the correct execution of the procedures in this document. The IETF MUST NOT endorse any IANA action that allocates (G)MPLS protocol codepoints except as a result of actions arising from the correct execution of That's way too strong given Brian's proposed changes. Also, the claim about IANA is just wrong and internally inconsistent. If there are FCFS or expert review codepoints these procedures are not needed. If a formal liaison is used, the IETF MUST respond to pursue the discussion. The liaison process should not be changed by this specification. That means you should not have any normative statements about what we do with liaison statements; we have BCPs for that. They do currently agree with what you say. Proposed rewording: "If a formal liaison is used, the IETF MUST follow its procedures for handling liaisons, including replying to these statements as required by IETF procedures." If the requirements statement I-D is brought to the IETF through a formal liaison, the working group chairs, ADs or their delegates MUST respond using one of the following answers in a formal liaison reply. I have a huge problem with mandating the set of responses like this. In addition to the general problem, there is a missing response. "The IETF understands the requirements, agrees protocol extensions are necessary, but there is not sufficient consensus to work on solutions within the IETF." You may not like giving that answer, but prohibiting it is a huge change in our process. If the charter change is not approved, the IESG MUST respond to the requirements statement I-D and, if the requirements were introduced through a formal liaison from another SDO, the IESG MUST send a liaison response using the options described in Section 5, although the IESG MAY delegate such responses. This is way too prescriptive. What if the IESG fails to approve the charter because the WG is behind on its existing deliverables? Also, again, stop providing normative language for the liaison process. This text needs to be toned down so it does not change RFC 2418. Under unusual circumstances the Routing Area Directors MAY decide to charter a new working group to act as the REWG. In this case, the ADs are responsible for drafting the charter of the new working group and MUST follow the procedures set out in the previous paragraph. This precludes a BOF. That is a bug. The output of the REWG MUST be either: - a completed requirements statement I-D that has been accepted by working group consensus within the REWG and has passed through working group last call; or: - a rejection of the requirements following exactly the same format and procedure as described in Section 5. Limiting a WG in this manner is not consistent with RFC 2418. The WG may conclude that there is insufficient interest; the WG could not come to consensus on the document; etc. All these are permitted outcomes under our process. Section 4.2.5 is inconsistent with RFC 2026. As best I can tell, AD evaluation is purely an IESG procedure for internal delegation and is not required by RFC 2026. I propose adding the following at the top. "As a matter of current internal procedure, drafts submitted to the IESG for publication are first delegated to an individual area director for review. This procedure may change in the future. However, to clearly describe today's practice, this non-normative section describes expectations for the AD review stage of the process. The normative requirement is that the IESG evaluation as a whole, including any IETF-wide last call and any internal IESG procedures such as AD review, meet the requirements of section 4.2.6." When the ADs accept the requirements statement I-D they MUST pass it to the IESG for review, and propose any charter changes necessary to select a PSWG. What about potential BOFing of a PSWG? As with all Internet-Drafts, the IESG MUST take a ballot on the progression of the requirements statement I-D. As with AD review, balloting is a purely procedural matter; it is how the IESG judges consensus today. Also, why do we require that these requirements IDs be published as RFCs? Is that always desirable? The IESG MUST take a ballot on any proposed charter changes for the PSWG. This MAY include the formation of a new working group specifically to work on the solutions, although it is also possible that the solutions work is covered by an existing working group charter without any changes. The IESG does not currently ballot charter changes. Also this normative must changes RFC 2418 and a lot of established procedure around formation of new WGs. Is a BOF needed? What if chairs cannot be found? What if insufficient participants are around? What if we don't believe the solution space is ready for engineering? If the IESG rejects working group charter changes such that it is not possible for the IETF to work on solutions for the requirements in the requirements statement I-D, this MUST be treated as a rejection of the requirements statement I-D, and the requirements statement I-D MUST NOT be published as an RFC. First why? If we agree the requirements are important but we cannot find a good chair at the current time, why can't we publish the requirements as an RFC? Also, this is in conflict with RFC 3932; we cannot stop someone from taking the requirement ID to the rfc editor if we're not working in the space. Once the PSWG has been identified and (re-)chartered as necessary and the requirements statement I-D has been approved by the IESG, the PSWG can start work on solutions following the normal IETF process. Why do we block the PSWG on the draft being approved? the IETF makes no guarantees that an externally produced solutions I-D will form the basis of the PSWG solutions I-D, but the PSWG MUST consider such an I-D for review and revision as a possible solution I-D. Why do we have that must; it seems like a process change. 5.1 I disagree that it is appropriate for us to have a finite set of reasons for rejection. I've listed reasons sprinkled throughout this text to demonstrate that you cannot have a finite set of reasons. Section 5.2: Same comments about respecifying liaison process. |
2007-01-10 |
08 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
2007-01-09 |
08 | Amy Vezza | State Changes to IESG Evaluation from IESG Evaluation - Defer by Amy Vezza |
2007-01-08 |
08 | Brian Carpenter | -------- Original Message -------- Subject: Direction for draft-andersson-rtg-gmpls-change Date: Thu, 21 Dec 2006 15:51:15 +0100 From: Brian E Carpenter <brc@zurich.ibm.com> Organization: IBM To: Loa Andersson … -------- Original Message -------- Subject: Direction for draft-andersson-rtg-gmpls-change Date: Thu, 21 Dec 2006 15:51:15 +0100 From: Brian E Carpenter <brc@zurich.ibm.com> Organization: IBM To: Loa Andersson <loa@pi.se>, Adrian Farrel <adrian@olddog.co.uk> Let me try to give you some direction on this. I've asked Sam and Mark to write their concerns up as a DISCUSS, but am still waiting. However, I think you should get a new version out before the IESG call on January 11, to make progress if possible. Here is what I propose (and remember, this is looking for a consensus, so people including the editors may end up in a <shrug> state rather than a <YES> state): 1. Add in the Introduction, wherever it seems to fit best, something like: This document does not change the formal IETF standards proces as defined in [RFC2026] and [RFC2418]. It is consistent with the general procedures for protocol extensions defined in [RFC4775] and shows how they are applied in the case of (G)MPLS. Any additional procedures described in this document are to be implemented in a way consistent with those three documents. They MUST be used when other SDOs wish to propose (G)MPLS changes and SHOULD be used internally within the IETF unless the changes concerned are considered minor or non-controversial by the responsible Area Directors, in which case the normal IETF standards process is necessary and sufficient. 2. Apply s/Routing AD/appropriate AD/ pretty much everywhere 3. Remove all four instances of "IAB" in Figure 1: Change Process Overview 4. In Section 4.2.3 "Chartering or Rechartering the REWG", please delete "and IAB" in the second paragraph. (I wouldn't object to an informative statement that the IAB may be consulted.) 5. Change the last paragraph of 4.2.3 as follows: OLD: Under unusual circumstances the Routing Area Directors MAY decide to charter a new working group to act as the REWG. In this case, the ADs are responsible for drafting the charter of the new working group and MUST follow the procedures set out in the previous paragraph. NEW: Under unusual circumstances the IESG MAY decide to charter a new working group to act as the REWG. In this case, the appropriate Area Directors are responsible for drafting the charter of the new working group and MUST follow the procedures set out in the previous paragraph. 6. I think we have to say somewhere (maybe in the Introduction) something like: If a requirement can be met simply by an appropriate IANA assignment, without defining new protocol elements or protocol procedures, it is both necessary and sufficient to apply the IANA Requirements prescribed for this assignment in the relevant RFCs. 7. Please drop the "protocol caretaker" terminology and use Designated Expert instead. 8. In "5.1 Reasons for Rejection", please change: OLD: The solution SHALL be presented to the IETF for review and possible publication as an Informational or Experimental RFC, and the IETF SHALL NOT block applications to IANA for codepoints. NEW: The solution SHALL be presented to the IETF for review and possible publication as an Informational or Experimental RFC. If IANA codepoint assignments are required, the IANA Requirements prescribed for those assignments in the relevant RFCs MUST be satisfied. Thanks, and God Jul! Brian |
2006-12-28 |
08 | Mark Townsley | [Ballot Position Update] New position, Discuss, has been recorded by Mark Townsley |
2006-12-13 |
08 | Sam Hartman | State Changes to IESG Evaluation - Defer from IESG Evaluation by Sam Hartman |
2006-12-13 |
08 | Ted Hardie | [Ballot discuss] I'd like to understand two things; what the rational is for introducing a "protocol caretaker" designation apart from the usual Designated Expert, especially … [Ballot discuss] I'd like to understand two things; what the rational is for introducing a "protocol caretaker" designation apart from the usual Designated Expert, especially given that they appear together. I'd also like to understand how the "insufficient support" track of rejection will work with any codepoints restricted to standards track documents. The document says: The solution SHALL be presented to the IETF for review and possible publication as an Informational or Experimental RFC, and the IETF SHALL NOT block applications to IANA for codepoints. If the RFC governing the codepoint allocation requires standards track, is this an effective block? |
2006-12-13 |
08 | Ted Hardie | [Ballot Position Update] New position, Discuss, has been recorded by Ted Hardie |
2006-12-13 |
08 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2006-12-12 |
08 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2006-12-11 |
08 | Ross Callon | [Ballot Position Update] New position, Recuse, has been recorded by Ross Callon |
2006-12-11 |
08 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2006-12-11 |
08 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2006-12-06 |
08 | Brian Carpenter | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Brian Carpenter |
2006-12-05 |
08 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Jeffrey Altman. |
2006-12-01 |
08 | Brian Carpenter | Telechat date was changed to 2006-12-14 from by Brian Carpenter |
2006-12-01 |
08 | Brian Carpenter | [Ballot Position Update] New position, Yes, has been recorded for Brian Carpenter |
2006-12-01 |
08 | Brian Carpenter | Ballot has been issued by Brian Carpenter |
2006-12-01 |
08 | Brian Carpenter | Created "Approve" ballot |
2006-12-01 |
08 | Brian Carpenter | Placed on agenda for telechat - 2006-12-14 by Brian Carpenter |
2006-11-29 |
07 | (System) | New version available: draft-andersson-rtg-gmpls-change-07.txt |
2006-11-29 |
08 | Yoshiko Fong | IANA Last Call Comment: The document says there are no IANA actions needed, but it instructs IANA to adheare to its polices when dealing with … IANA Last Call Comment: The document says there are no IANA actions needed, but it instructs IANA to adheare to its polices when dealing with MPLS registry allocations, It would have been nice to get a list of registries that are covered by this statement. when scanning all registries that have MPLS in their name some where found to be missing allocation policy statement. Action #1 Registry "MPLS Label Values - per [RFC3032]" at http://www.iana.org/assignments/mpls-label-values needs to list allocation policy: IETF Standards Action as specified in RFC3032 |
2006-11-27 |
08 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-11-08 |
08 | (System) | Request for Last Call review by SECDIR is assigned to Jeffrey Altman |
2006-11-08 |
08 | (System) | Request for Last Call review by SECDIR is assigned to Jeffrey Altman |
2006-10-30 |
08 | Amy Vezza | Last call sent |
2006-10-30 |
08 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-10-28 |
08 | Brian Carpenter | Last Call was requested by Brian Carpenter |
2006-10-28 |
08 | Brian Carpenter | State Changes to Last Call Requested from AD Evaluation by Brian Carpenter |
2006-10-28 |
08 | (System) | Ballot writeup text was added |
2006-10-28 |
08 | (System) | Last call text was added |
2006-10-28 |
08 | (System) | Ballot approval text was added |
2006-10-23 |
06 | (System) | New version available: draft-andersson-rtg-gmpls-change-06.txt |
2006-10-23 |
08 | Brian Carpenter | Intended Status has been changed to BCP from None |
2006-10-18 |
08 | Brian Carpenter | State Changes to AD Evaluation from Publication Requested by Brian Carpenter |
2006-10-16 |
08 | Brian Carpenter | State Changes to Publication Requested from AD is watching by Brian Carpenter |
2006-10-16 |
08 | Brian Carpenter | State Change Notice email list have been change to loa@pi.se,adrian@olddog.co.uk,swallow@cisco.com,dbrungard@att.com,fenner@research.att.com,rcallon@juniper.net,Kireeti@juniper.net,zinin@psg.com,sob@harvard.edu from |
2006-10-13 |
05 | (System) | New version available: draft-andersson-rtg-gmpls-change-05.txt |
2006-10-12 |
08 | Brian Carpenter | [Note]: 'Brian shepherds on behalf of the Routing ADs' added by Brian Carpenter |
2006-10-12 |
08 | Brian Carpenter | Status date has been changed to 2006-10-12 from |
2006-10-12 |
08 | Brian Carpenter | Shepherding AD has been changed to Brian Carpenter from Bill Fenner |
2006-10-04 |
04 | (System) | New version available: draft-andersson-rtg-gmpls-change-04.txt |
2006-08-22 |
08 | (System) | State Changes to AD is watching from Dead by system |
2006-08-21 |
03 | (System) | New version available: draft-andersson-rtg-gmpls-change-03.txt |
2006-07-10 |
08 | (System) | State Changes to Dead from AD is watching by system |
2006-07-10 |
08 | (System) | Document has expired |
2006-04-17 |
08 | Bill Fenner | Shepherding AD has been changed to Bill Fenner from Alex Zinin |
2006-04-17 |
08 | Bill Fenner | Area acronymn has been changed to rtg from gen |
2006-02-06 |
08 | (System) | State Changes to AD is watching from Dead by system |
2005-12-07 |
02 | (System) | New version available: draft-andersson-rtg-gmpls-change-02.txt |
2005-09-02 |
08 | (System) | Document has expired |
2005-09-02 |
08 | (System) | State Changes to Dead from AD is watching by system |
2005-02-22 |
01 | (System) | New version available: draft-andersson-rtg-gmpls-change-01.txt |
2005-02-21 |
08 | Alex Zinin | State Changes to AD is watching from Publication Requested by Alex Zinin |
2005-02-21 |
08 | Alex Zinin | Discussion ongoing |
2005-01-05 |
08 | Alex Zinin | Draft Added by Alex Zinin in state Publication Requested |
2004-11-23 |
00 | (System) | New version available: draft-andersson-rtg-gmpls-change-00.txt |