Document: draft-andersson-rtg-gmpls-change-06 Reviewer: Spencer Dawkins Review Date: 2006-11-17 IETF LC End Date: 2006-11-27 Summary: This document is on the right track for publication as a BCP, but some work is still needed. Comments: I have lots of questions, but most are requests for greater clarity - I would not expect Brian to DISCUSS based on most of the questions I listed in this review. If I could make any single suggestion, it would be to remove anything that describes "business as usual" in the working group process ("As with all Internet-Drafts produced by a working group, ..."), for two reasons - the focus should be on what happens that is NOT "business as usual", and the detailed description here will be very fragile - for example, if the RTG ADs decided they would accept directorate reviews instead of conducting their own reviews, this procedure would be out of step. It adds no value to say that the IESG MUST ballot any Internet-Draft forwarded for publication by a working group. Abstract The process allows individuals, IETF working groups, and external standards bodies to influence the development of the MPLS and GMPLS standards. When possible, existing liaison relationships are used. Spencer: it just seems odd to list individuals and IETF working groups separately here (and in the Introduction). After reading further, I wondered if the point was not that IETF working groups *other than the (G)MPLS working groups* could influence the development of these standards, but that wasn't clear from this text, either. 1. Introduction This document recognizes that the Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) protocol families were created within the IETF and constitute significant protocol suites that are strategic to the development of the Internet. They should not be extended or varied without IETF review, and that should preferably only be extended within the IETF process. Spencer The last sentence doesn't parse well for me, "preferably" seems weak, and I'm not sure why it says "extended" and not "varied". Suggest "These protocol families should only be extended or varied within the IETF process." - and even this seems inconsistent with MUSTs later in the document. The IETF will not endorse the publication of any MPLS or GMPLS protocol or technology extensions in RFCs or other documents where Spencer: suggest "until the process described here has been followed" - you're not saying you won't endorse them under any circumstances, right? but only that you won't endorse the documents without considering them as described in this document. the process described here have 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]. IANA is responsible for managing many codepoints registries including those for MPLS and GMPLS protocols. These registries have specific allocation policies that IANA uses in order to determine whether codepoints can be allocated and which codepoints to allocate. In many cases, the rules require IANA to refer back to the IETF when asked to make an allocation. In the case of changes or extensions to the MPLS or GMPLS protocols, IANA will use its normal documented procedures to Spencer: got a reference for the "normal documented procedures" you have in mind? judge whether or not a code point allocation should be made. 2.2 Other (G)MPLS Technology Working Groups Problem statements and requirements for (G)MPLS technology have been produced by several working groups in addition to the MPLS and CCAMP working groups. For example, the IP over Optical (IPO) working group Spencer (nit): "Examples are" (need a verb) ... and the Internet Traffic Engineering working group (TEWG). These working groups have not specified any protocols, but have been a source of problem statements and requirements to be considered by the (G)MPLS working groups. 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. The Layer 1 VPN (L1VPN) working group is chartered to specify mechanisms necessary for providing layer 1 VPN services (establishment of layer 1 connections between CE devices) over a GMPLS-enabled transport service-provider network. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the Spencer: you guys are the experts, but L2VPN is conspicuous by its absence in this list - it's named previously, so perhaps this is an accidental omission? L1VPN will not develop GMPLS protocol extensions in isolation, but will develop requirements and propose extensions that will be reviewed and approved by the (G)MPLS working groups. 2.3 Organizations Outside the IETF A number of standards development organizations (SDOs) and industrial forums use or reference the (G)MPLS protocols in their specifications. Some of these organizations have formal or less Spencer: either "formal or informal" or "more or less formal", I think. formal liaison relationships with the IETF [RFC4052]. The IETF exchanges information with these organizations about what is happening on both sides, including plans and schedules, using liaison statements [RFC4053]. More details about the cooperation relationship between the IETF and the ITU-T can be found in [RFC3356]. The procedures in this document are applicable to all organizations outside the IETF whether or not they have formal liaison relationships with the IETF. If any organization outside the IETF has a requirement, or believes it may have a requirement, for Spencer: I'd remove ", or believes it may have a requirement," - just seems too legalistic. extensions or modifications to the (G)MPLS protocols then the procedures in this document apply. 2.4 Terminology This section defines terms for use in the context of this document. o (G)MPLS protocols The set of RFCs that constitutes the (G)MPLS protocols are the standards track RFCs from the (G)MPLS working groups (see below). A list of these RFCs is not supplied here since new RFCs are produced from time to time. Spencer: I'm visualizing an ugly race condition here (with someone who starts extending something before it's been published as an RFC). "Standards-track specifications"? For the purpose of extending and changing any protocols specified in Experimental, Informational, or BCP RFCs developed by the (G)MPLS working groups, those protocols are considered to be part of the (G)MPLS protocols. Spencer: this is just odd. Are there any protocols defined in these types of documents today? If so, and you're going this direction - what about Historic? but I think you're really saying "ANY specification from the (G)MPLS working groups". o Requirement evaluating working group (rewg) Spencer (nit) - "rewg" and "pswg" would look less odd in caps, and they are acronyms ... The rewg is the IETF working group charged with the task of evaluating a specific set of requirements and the associated problem statement. 3. Summary of Procedures Whenever there is reason to believe that a particular problem may be solved by use of or extensions to the (G)MPLS protocols, a preliminary investigation phase may be used to discuss the requirements with the IETF. This may lead to an understanding that the problem is already solved, is outside the scope of the IETF, or requires more investigation possibly leading to changes to the (G)MPLS protocols. Spencer: It seems odd that the requirements statement Internet-Draft is mentioned here, but the problem statement internet-draft has not been mentioned previously in this section. Whenever any extension or change to the (G)MPLS protocols is desired, a requirements statement must be produced and must be submitted to IETF as an Internet-Draft. Spencer: the following text would be a lot more readable as a list of bullets. In assessing the requirements statement I-D, the IETF may determine: that the requirements can be satisfied without modifications to the (G)MPLS protocols; that the requirements are not sufficiently general to warrant a change to the (G)MPLS protocols; that the requirements justify a change to the (G)MPLS protocols that will be created by the IETF or within another organization; that the requirements might not be possible to satisfy without violating the (G)MPLS architecture in a way that would harm the (G)MPLS technology; or that the requirements should be combined with other requirements to solve a more general problem or solve the same problem in a more flexible way. The solutions that are developed within the IETF may be sourced from external organizations and presented for review, discussion, modification, and adoption as Internet-Drafts. Such solutions drafts may be presented to the IETF in advance of the completion of the requirements work, but all solutions will compete through the normal IETF process with other proposed solutions, and none will be adopted as an IETF working group draft until the requirements are agreed by the rewg chairs to be stable and, in any case, not before the pswg has a charter item to cover the solutions work. Spencer: "has a charter item" is awfully formal - could the last condition be that an AD AGREES to add a charter item to cover the solutions work, if no charter item already exists? I do see WGs that run under this type of informal working arrangement with ADs for new milestones. 4. MPLS and GMPLS Change Process 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 Spencer: I know that the text in previous sections was not normative, but it contained lower-case "should". Suggest that the text in previous sections changes to lower-case "must"? 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 the procedures in this document. Spencer: wow. Does the IETF usually adopt these kinds of self-restraints? 4.1 Flow Diagram Figure 1 is presented to give a visual overview of the process. It does not contain all of the possible interactions of procedures, and the text in the subsequent sections should be used for a definitive description of the process. Spencer: Use of "ACK" and "NACK" in Figure 1 is cute, but "YES" and "NO" seems clearer, I think. 4.2.1 Preliminary Investigation This step SHOULD be carried out informally on the mailing list of the rewg or on the Routing Area discussion mailing list and MAY be Spencer: I wish there was one place you could point to for these discussions - multiple rewgs are fine, but the conversation could be on the Routing Area discussion mailing list, so monitoring the rewgs you care about isn't sufficient. initiated by any individual, group of individuals, external organization, or IETF working group. A possible outcome of this preliminary investigation is that the requirements and problem are understood, but agreed to be out of scope for the IETF. Alternatively it may be that the problem can be solved with existing protocols. The full list of outcomes from the preliminary investigation phase are identical to those for the requirements statement evaluation phase described in section 4.2.2, but the requirements statement evaluation phase MUST form part of the process if the requirements are understood and the IETF would like to develop protocol solutions - the process cannot move direct form the Spencer: s/direct form/directly from/ preliminary investigation pahse to the development of solutions. Spencer: s/pahse/phase/ 4.2.2 Requirements Statement Evaluation After discussion on the IETF mailing lists, the appropriate IETF working group chairs and the Routing Area Directors MUST decide whether the requirements will be formally evaluated by the IETF, and MUST deliver a response to the requirements statement I-D. Spencer: The following text says pretty clearly how the IETF wg chairs and RTG ADs respond to a formal liaison, but I didn't see any discussion of how they respond in the absence of a formal liaison. b. Requirements understood, but judged to be out of scope for the IETF. In this case, the originator of the requirements can work on on requirements and solutions and will not be impeded by the Spencer: s/on on/on/ IETF. The IETF may request to be kept informed of progress. 4.2.3 Chartering the Rewg Spencer: this section actually seems to be about modifying the rewg's charter, not chartering the rewg. Perhaps "Reviewing the Requirements Statement I-D"? In many cases the problem covered by the requirements statement I-D will fall within the scope of the existing charter of a working group. In this case, the Routing Area Directors SHOULD designate the working group as the rewg and pass the requirements statement I-D to the working group for evaluation. Spencer: it was not obvious to me how the case is handled when a new requirements evaluation working group must be created - is anyone in particular responsible for developing a proposed charter? 4.2.5 AD Evaluation of Completed Requirements Statement I-D As with all Internet-Drafts produced by a working group, the ADs MUST review the completed requirements statement I-D produced by the rewg to determine its fitness for publication. At their discretion, the ADs MAY use an Area Directorate and/or other subject matter experts to assist them in this review Spencer: missing period after "review". 4.2.7 Solutions Work 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. Solutions I-Ds MAY be prepared externally (such as within an external organization) or within the IETF, submitted to the IETF for publication, and introduced to the pswg for consideration. Such I-Ds MAY be submitted at earlier stages in the process to assist the rewg in its development and discussion of the requirements, but no I-D will be formally considered as a solutions I-Ds until the pswg has a charter item that covers the work and the rewg chairs are confident that the requirements are stable. Even at this stage in the process, 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 as a possible solution I-D. Spencer: is there any potential for misunderstanding by an SDO who might expect that "MUST consider" requires the I-D to be "baseline text", become a WG draft, etc? (The text is clear to me, but I think I understand how the IETF works) In particular, we're a lot more casual about big changes to individual drafts than we are about big changes to working group drafts, or at least, we should be. Where the requirements originated from an external organization, the pswg SHOULD regularly communicate its progress using a formal liaison process if one exists. This communication SHOULD also be used to request review input and comment on the development of the solutions I-D. The solutions I-D MUST be communicated to the originating organization during working group last call for final review against the requirements. When the solutions I-D is complete (normally upon completing working group last call and/or on entering the RFC Editor's queue) the pswg MUST inform the originating organization of the completed solution. Spencer: "when the solutions I-D is complete" probably isn't WGLC... suggest "on entering the RFC Editor's queue" as the only triggering condition. 5. Rejecting Requirements Statements I-D The requirements can be rejected at various stages of the process as described in the previous sections. The person or grouping that makes Spencer: I think this is "or group"? the rejection is responsible for generating an explanation of the rejection and MUST follow the process described in this section. 5.1 Reasons for Rejection The requirements statement I-D can only be rejected using one of the following reasons. Each reason MUST be stated with the acceptable next steps as described here. - Requirements not understood. At the early stage of evaluation of the requirements statement I-D before the rewg has been tasked with performing a full evaluation and completing the requirements statement I-D or during the optional preliminary investigation it is not clear what the requirements are for or what the problem being addressed is. Spencer: the "not understood" explanation is way too complex. Perhaps "Either during preliminary investigation or during evaluation of the requirements statement I-D, it wasn't clear what the requirements are, or what the problem being addressed is." - Out of scope for the IETF. Many stages of this process may determine that the requirements are out of scope for the IETF. In this case, the IETF MUST NOT constrain the authors of the requirements statement I-D permission to work on a solution. Spencer: "constrain ... to work ..." isn't quite right. "prevent ... from working ..."? And I'm not sure what this is saying - "permission to work on a solution in other SDOs"? Or something else? - No protocols extensions or changes are needed. At some stage in the evaluation of the requirements it may become clear that they can all be met through appropriate use of existing protocols. In this case no further evaluation of the requirements is required, but the IETF MUST explain how the protocols can be used to meet the requirements and MAY cooperate with the authors of the requirements Spencer: these IETF MUST/MAY statements can require real work, for which "IETF" isn't quite right - you need a stuckee. Does this become something like "the rewg chairs or their delegates"? statement I-D in the production of an Applicability Statement Internet-Draft or a Profiles Internet-Draft that explains precisely how the existing protocols can be used to meet the requirements. - Insufficient support within the IETF. Although the work described within the requirements statement I-D is within scope for the IETF, and despite the support of the originators of the requirements statement I-D on the rewg mailing list, the chairs of the rewg have determined that there is insufficient support in the rewg to complete requirements statement I-D. In this case, the IETF MUST grant the authors of the requirements statement I-D permission to work on a solution. 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. Spencer: the SHALL and SHALL NOT in the last sentence don't seem quite right. If this is saying "if you work on a solution anyway, we still review it", this could be clearer. - Insufficient support for the work. If the authors of the Spencer: is this "insufficient support from the requestors"? This could be clearer. As it is, this category sounds like a superset containing the previous category. requirements statement I-D do not make themselves available on the rewg mailing list for discussion of the requirements or do not contribute the completion of the requirements statement I-D, the chairs of the rewg MAY determine that there is insufficient support for the work and MAY reject the requirements statement I-D. In this case, the IETF MUST NOT grant permission for the work to be carried out in any other organization, and MUST NOT endorse the publication of any changes or extensions to the (G)MPLS protocols and MUST NOT instruct IANA to allocate any codepoints. The requirements may be re-introduced by starting the procedure again from the top. - Satisfying the requirements would break the technology. It is possible that an assessment will be made that, although the requirements are reasonable, it is not possible to satisfy them through extensions or changes to the (G)MPLS protocols without violating the (G)MPLS architecture in such a way as would break the (G)MPLS technology. In this case a recommendation will be made that some other technology be used to satisfy the requirements. See Spencer: just checking my understanding - there's no expectation that the IETF make any recommendation about what other technology would be used, right? If I got this correctly, no change needed. Section 7 for further discussions of the protection of the integrity of the (G)MPLS technology. 5.2 Actions Upon Rejection Spencer: this section seems to be "Rejecting a requirements statement I-D" - the current title isn't clear about whether the actions are taken by the requestor or the rejecter. Spencer: there are several SHOULDs in this section with no discussion of why they aren't MUSTs. This seems awkward. ("SHOULD, unless you just decide not to ...") - If the requirements are brought to the IETF as a preliminary investigation (see Section 4.2.1) through an email exchange then the response SHOULD be made as an email response and SHOULD be archived through an IETF email archive. Spencer: 4.2.1 says "SHOULD be carried out on rewg mailing list or routing area mailing list", so I think the "SHOULD be archived" can be dropped - this is required for all IETF working group mailing lists. The responsibility for the generation of the response lies with the person, people, or grouping that instigates the rejection. This may be the IESG, one or more Area Directors, one or more working group chairs, or a protocol caretaker. In the case of the use of a liaison Spencer: I was asking "who is the stuckee?" in a previous comment. You might consider putting a list (perhaps this list) in one place in the document, and using it by reference, especially in the places where you're saying "the IETF will ...". The IETF, as a whole, doesn't do much except express consensus or lack thereof. relationship, the IETF's liaison manager has responsibility for ensuring that the procedures in this document, and particularly the rejection procedures, are followed. 6. Abandonment of the Solutions I-D Once the solutions work has been started by the pswg, it MAY be Spencer: this is probably a lower-case "may". abandoned before completion. This can happen if the pswg chairs determine that there is no longer working group support for doing the work. This could arise, for example, if no-one (including the originators of the requirements statement I-D) is willing to contribute to the development of a solutions I-D. In the event that the solutions work is abandoned by the pswg, the Area Directors responsible for the pswg MUST be consulted. The originators of the requirements statement I-D MUST be informed that the work has been stopped using a mechanism dependent on how the Spencer: "has been abandoned"? Perhaps good to avoid saying we "stopped" doing anything? requirements were introduced (as discussed in Section 5.2). 7. (G)MPLS Integrity The (G)MPLS working groups are REQUIRED to protect the architectural integrity of the (G)MPLS protocols and SHOULD NOT extend the GMPLS Spencer: this SHOULD NOT seems to beg for an explanation of why it's not MUST NOT. It's the only SHOULD (NOT) in this section, which seems to be the "line in the sand" section. architecture with features that do not have general use beyond the specific case. They also MUST NOT modify the architecture just to make some function more efficient at the expense of simplicity or generality.