The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

FYI, this I-D has been updated after IETF last call and GenArt review as 
follows...

Adrian

===
General
s/rewg/REWG/
s/pswg/PSWG/
Typos
===
Section 1, para 2
OLD
   They should not be
   extended or varied without IETF review, and that should preferably
   only be extended within the IETF process.
NEW
   These protocols should
   not be extended or varied without IETF review, and they should
   only be extended within the IETF process.
===
Section 1, para 3
ADD
   The IETF's formal
   standards process is defined in [RFC2026] and [RFC2418], and is not
   changed by this document.
===
Section 2.2
OLD
   Other working groups, e.g., the Bidirectional Forwarding Detection
   (BFD) working group, also use the (G)MPLS protocols and mechanisms.
   When any of these working groups needs to extend or change the
   (G)MPLS protocols the procedures specified in this document are
   applicable.
NEW
   Other working groups, e.g., the Bidirectional Forwarding Detection
   (BFD) working group, also use the (G)MPLS protocols and mechanisms.
   When any of these working groups needs to extend or change the
   (G)MPLS protocols the procedures specified in this document are
   applicable. Some of those working groups (again, for example, the
   BFD working group) are already chartered for requirements evaluation
   and protocol specification, and can fit into the procedures in those
   roles.
===
Section 2.3
s/formal or less formal/formal or informal/
===
Section 2.3, para 2
OLD
   If any organization outside the IETF
   has a requirement, or believes it may have a requirement, for
   extensions or modifications to the (G)MPLS protocols then the
   procedures in this document apply.
NEW
   If any organization outside the IETF
   has a requirement for extensions or modifications to the (G)MPLS
   protocols then the procedures in this document apply.
===
Section 2.4, bullet 1
OLD
      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.
NEW
      For the purpose of extending and changing any protocols specified
      in any specification developed by the (G)MPLS working groups,
      those protocols are considered to be part of the (G)MPLS
      protocols.
===
Section 3, para 3
OLD
   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. As described in [RFC4052], when the
   requirements come from an external organization informal
   communications such as e-mail to working group mailing lists often
   facilitates cooperative work. However, if desired, the Internet-Draft
   containing the requirement may be submitted to the working group
   using a liaison statement. That way, the IETF's response to the
   request will be given as the reply to the liaison, with no risk of
   confusing an individual participant's opinion for that of the group
   as can happen on mailing lists.
NEW
   Whenever any extension or change to the (G)MPLS protocols is desired,
   a problem statement and/or requirements statement must be produced
   and must be submitted to IETF as an Internet-Draft. As described in
   [RFC4052], when the requirements come from an external organization
   informal communications such as e-mail to working group mailing lists
   often facilitates cooperative work. However, if desired, the
   Internet-Draft containing the requirement may be submitted to the
   working group using a liaison statement. That way, the IETF's
   response to the request will be given as the reply to the liaison,
   with no risk of confusing an individual participant's opinion for
   that of the group as can happen on mailing lists.
===
Section 3, para 4, convert to bullets
===
Section 4.1, figure 1
s/ACK/YES/
s/NAK/NO/
===
Section 4.2.2, para 4
OLD
   If the requirements statement I-D is brought to the IETF through a
   formal liaison, the IETF MUST respond using one of the following
   answers in a formal liaison reply:
NEW
   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.
   If a formal liaison was not used the response SHOULD be delivered
   using one of the following answers in an email copied to the
   appropriate mailing lists.
===
Section 4.2.3, title
s/4.2.3 Chartering the Rewg/4.2.3 Chartering or Rechartering the REWG/
===
Section 4.2.3
OLD
   If a new charter item is required, the Routing Area Directors with
   assistance from working group chairs MUST apply to the IESG and IAB
   for a modification of an existing working group's charter or for the
   creation of a new working group. If the IESG approves the charter,
   the requirements statement I-D is passed to the rewg for evaluation.
   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.
NEW
   If a new charter item is required for an existing working group, the
   Routing Area Directors with assistance from working group chairs MUST
   apply to the IESG and IAB for a modification of an existing working
   group's charter or for the creation of a new working group. If the
   IESG approves the charter, the requirements statement I-D is passed
   to the REWG for evaluation. 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.

   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.
===
Section 4.7, para 2
OLD
   but the pswg MUST
   consider such an I-D as a possible solution I-D.
NEW
   but the PSWG MUST
   consider such an I-D for review and revision as a possible solution
   I-D.
===
Section 5.1, bullet 1
OLD
   - 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.
NEW
   - Requirements not understood. 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.
===
Section 5.1, bullet 3
s/IETF/REWG/
===
Section 5.1, bullet 4
OLD
     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
NEW
     In this case, the IETF MUST
     NOT restrict the authors of the requirements statement I-D from
     working 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.
===
Section 5.1, bullet 5
s/Insufficient support for the work./Insufficient support for the work from
the original requesters./
===
Section 5.2, title
s/5.2 Actions Upon Rejection/5.2 Actions Required When Rejecting
Requirements Statement I-Ds/
===
Section 5.2, para 1
s/SHOULD/MUST/
===
Section 5.2, bullet 1
OLD
   - 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.
NEW
   - If the requirements are brought to the IETF as a preliminary
     investigation (see Section 4.2.1) through an email exchange then
     the response MUST be made as an email response copied to an IETF
     mailing list so that it is automatically archived.
===
Section 5.2, bullet 3
s/SHOULD/MUST/
===
New section 5.3 to point to the appeals process
===
Section 6, para 2
s/stopped/abandoned/
===
New section 6.1 to point to the appeals process
===
Section 7, para 1
s/SHOULD NOT/MUST NOT/
===
Section 9
Additional thankees
===
Section 11. Group all references into one section with two sub-sections
===
Section 11.1
Add RFC2026 and RFC2418
===
Split Editors' Addresses out of Authors' Addresses
===
Change boilerplate to IETF Trust

----- Original Message ----- 
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Sent: Wednesday, November 29, 2006 3:50 PM
Subject: I-D ACTION:draft-andersson-rtg-gmpls-change-07.txt


>A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : Change Process for Multiprotocol Label Switching (MPLS) and 
> Generalized MPLS (GMPLS) Protocols and Procedures
> Author(s) : L. Andersson, A. Farrel
> Filename : draft-andersson-rtg-gmpls-change-07.txt
> Pages : 23
> Date : 2006-11-29
>
> The issues surrounding the extensibility of IETF protocols have been
>   widely debated. These issues include when it is reasonable to
>   extend IETF protocols with little or no review, and when extensions
>   or variations need to be reviewed by the larger IETF community.
>   Experience with IETF protocols has shown that extensibility of
>   protocols without early IETF review can cause problems.
>
>   The Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
>   suites of protocols have become popular for a number of applications
>   and deployment scenarios. One result of this popularity is a large
>   number of suggestions for modifications and extensions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-07.txt



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls