[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fw: I-D ACTION:draft-andersson-rtg-gmpls-change-07.txt

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