Subject: [Gen-art] Gen-ART LC review of draft-andersson-rtg-gmpls-change-06

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 18 Nov 2006 08:49:55 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Thanks,

Spencer

Document: draft-andersson-rtg-gmpls-change-06
Reviewer: Spencer Dawkins
Review Date: 2006-11-17
IETF LC End Date: 2006-11-27
IESG Telechat date:

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. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 19 Nov 2006 12:05:38 -0000

Good morning Spencer,

Thanks for the review.

> would not expect Brian to DISCUSS based on most of the questions I listed 
> in this review.
>
> 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.

The problem I have in documenting this is that it is partly aimed at 
consmption by external parties that do not understand the IETF process and 
are looking for a single description of how their work will be handled. I'll 
think some more about this and if we can find something coherent to 
reference instead of redescribing the IETF process we will do that.

> 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.

Hmmm. Actually the point may be to target other SDOs without saying so :-(
What we are trying to say is "everyone is on an even playing field". No-one 
is held back, and no-one is advanced.
We wanted to cover:
- individual draft submissions
- working group drafts
- material from other SDOs.

> process." - and even this seems inconsistent with MUSTs later in the 

Changed to...
   These protocols should
   not be extended or varied without IETF review, and they should
   only be extended within the IETF process.

The point of diversion from "MUST" is that the procedures defined later 
allow the IETF to say: "OK, you are free to make the change."

> 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 

Right.

> Spencer: got a reference for the "normal documented procedures" you have 
> in mind?

Hmmmm :-)

I used to have a description of what IANA was required to do, but I got 
warned off redefining IANA procedures.

Is RFC2434 any use?

> Spencer (nit): "Examples are" (need a verb) ...

OK

> in this list - it's named previously, so perhaps this is an accidental 

Deliberate. The L1VPN working group doesn't appear to have any protocol 
overlap with L2VPN. Curious but true. L3 and L1 are very similar, but L2 is 
off in its own set of weeds.

> Spencer: either "formal or informal" or "more or less formal", I think.

OK

> Spencer: I'd remove ", or believes it may have a requirement," - just 
> seems too legalistic.

:-)

> "Standards-track specifications"?

Yes. This race condition exists with PWE3, BFD, and L3VPN.
We are going to have to handle it (are already handling it) through good 
will.

> 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 

Yes. "any specification" would be better. The list we had just grew.

> Spencer (nit) - "rewg" and "pswg" would look less odd in caps, and they 
> are acronyms ...

Can do.

> mentioned previously in this section.

OK

> Spencer: the following text would be a lot more readable as a list of 

Yup.

> informal working arrangement with ADs for new milestones.

Oooh: rat-hole!

I don't believe WGs should run in this mode. I believe WG chartering is by 
IETF consensus under IESG guidance, so individual ADs are not so powerful 
(which is possibly why they allow things to happen without re-charetering 
:-).

I really don't want to go down the path of this discussion in this I-D, and 
I'm happy to require charter items (!= milestones) before work starts. The 
current text, I believe, covers us for charter items that already exist.

> 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"?

Don't get it.
There is no 2119 language before section 4. First para of section 4 is also 
non-2119. From then on, everything is procedural and is in 2119 language.

> Spencer: wow. Does the IETF usually adopt these kinds of self-restraints?

Nope.
And this lack of self-restraint has led us to blindly allocate codepoints 
for harmful (deliberately harmful?) changes to the core protocols.

Actually, when I say no, I really mean yes :-)
We have plenty of self-restraints wrt codepoint allocation. For example: the 
definition of "IETF Consensus" for a code point is pretty much a constraint.

> Spencer: Use of "ACK" and "NACK" in Figure 1 is cute, but "YES" and "NO" 

Thanks. Yes.

> 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.

Agree. But it is "generally accepted" (hah!) that you have to subscribe to 
the specific WG mailining lists you care about, and the parent area 
mailining list, and the IETF discussion mailing list. It is a bother, but I 
don't know how you can otherwise be sre to capture everything important if 
it comes out as a new discussion point. Fortuantely:
- we are not requiring to follow the IETF discussion list because everything 
here falls under Routing
- the Routing discussion list is very quiet.

> Spencer: s/direct form/directly from/

Yes and no.

from/form is one of my favorite finger dibbles.
"directly" refers to time: i.e. immediately.
"I will do it directly" == "I will do it at once"
"direct" refers to space: i.e. without intervening steps
"I will go there direct" == "I will not stop in the sports bar to catch the 
second half of the game"

>   preliminary investigation pahse to the development of solutions.

Yes

> 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.

Yes.
   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. 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.

>       on on requirements and solutions and will not be impeded by the

on and on and on?

> charter, not chartering the rewg. Perhaps "Reviewing the Requirements 

"Chartering or Rechartering the REWG"

> particular responsible for developing a proposed charter?

   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.

> Spencer: missing period after "review".

Yes.

> 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.

   MUST consider such an I-D for review and revision as a possible solution 
I-D.

> 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.

I'm inclined to agree in principle, but I am worried abot the two year 
hiatus between the two events.

> Spencer: I think this is "or group"?

yes

> what the problem being addressed is."

OK

> working ..."? And I'm not sure what this is saying - "permission to work 
> on a solution in other SDOs"? Or something else?

Yes. I got confused trying to write in American. I'll put it into English 
and leave the RFE Editor to sort out the detail.

What is intended is a passive version of "grant permission to work in 
another SDO". That is, "not block work in another SDO"

> like "the rewg chairs or their delegates"?

Ah yes. In my experience it is usually me :-(
I guess we should stick it to the REWG and by default the REWG chairs.

> right. If this is saying "if you work on a solution anyway, we still 
> review it", this could be clearer.

Actually, there wasn't any intent to promise review.

> clearer. As it is, this category sounds like a superset containing the 

OK

> right? If I got this correctly, no change needed.

Yeah. I suppose we could make a suggestion, but we can't guarantee to.

> 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.

Oh.
Right, that's easy to fix.

> 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 ...")

Right.
I think I had become tired.

> this is required for all IETF working group mailing lists.

Reworded.

> 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.

Yup. I have gone back to all instances of "the IETF" and applied a little 
more focus.

The stuckee does depend on where we are in the process at the time.
I found that "the IETF MUST NOT" is acceptable, but "the IETF MUST" needed 
refinement.

> Spencer: this is probably a lower-case "may".

Yes

> Spencer: "has been abandoned"? Perhaps good to avoid saying we "stopped" 

:-)

> MUST NOT. It's the only SHOULD (NOT) in this section, which seems to be 
> the "line in the sand" section.

I agree with you, but I'm finding it hard to type "MUST NOT" just in case.

OK. I managed it!

>   make some function more efficient at the expense of simplicity or

Cheers,
Adrian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 19 Nov 2006 06:53:35 -0600

Hi, Adrian,

The high-level bit is that I am now happy with the document, with the 
changes you propose (I'm not the one who has to be happy, but that's ONE set 
of last call comments gone).

I deleted everything that we agreed on, just so you could see what's left. 
You might not change anything beyond your first e-mail, but in a couple of 
places, I wasn't clear on what I was saying, and in a couple of places, I 
need to punt to ADs for guidance (and not just about this document, relax).

Thanks for getting back so quickly. I can still remember what I was thinking 
last time.

See you in Prague,

Spencer

From: "Adrian Farrel" <[email-masked]>

>> 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.
>
> are looking for a single description of how their work will be handled. 
> I'll think some more about this and if we can find something coherent to 

Dear Brian, cc: Bill and Ross,

Please note that this document is longer than it needs to be because no one 
outside the IETF can reasonably figure out our process, so Adrian has to 
describe it for them, but also please note that this draft is targeted for 
publication as a BCP, and the procedures described here overlap with other 
BCPs, so it's likely to conflict with new BCP text over time, and is even 
more likely to conflict with ION text as you describe more WG and IESG 
procedures in IONs - and I Would Have Thought that in the event of a tie, 
BCP text would trump ION text, if process BCPs are to have any meaning after 
IONs enter common use. Sigh.

> What we are trying to say is "everyone is on an even playing field". 
> No-one is held back, and no-one is advanced.
> We wanted to cover:

Ah. The focus on document origins makes much more sense than the focus on 
participants, because there's no overlap in the document origins.

Perhaps "The process describes how individual draft submissions, working 
group drafts, and inputs from external standards bodies influence the 
development of the MPLS and GMPLS standards", as the first sentence?

> warned off redefining IANA procedures.

Dear Brian, Ross, and Bill,

I'm NOT the genius of IANA allocation process. Any guidance here?

> We are going to have to handle it (are already handling it) through good 

OK, but it seems like you guys are going to a lot of trouble to avoid having 
to rely on good will for everything else (not arguing, just wondering if you 
can head off trouble here - answer may be "no").

>> 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.
>
> Oooh: rat-hole!
>
> I really don't want to go down the path of this discussion in this I-D, 
> and I'm happy to require charter items (!= milestones) before work starts. 
> The current text, I believe, covers us for charter items that already 
> exist.

OK - I was worried about having a couple of months delay while charters are 
added to IESG agendas, sent out for external review, added to IESG agendas, 
... but that's really not much time in the life of an SDO, is it?

> There is no 2119 language before section 4. First para of section 4 is 
> also non-2119. From then on, everything is procedural and is in 2119 
> language.

Sorry if I'm not being clear. I was wondering why the previous section was 
"should", and this is now "MUST" - having "must" in the previous section 
made more sense to me. You had a previous note about the "should" I was 
thinking of allowing IETF to say "sure, go ahead and good luck", so I can 
live with this text.

> We have plenty of self-restraints wrt codepoint allocation. For example: 
> the definition of "IETF Consensus" for a code point is pretty much a 
> constraint.

This text makes more sense now that I understand you are telling people who 
don't understand our process how IANA works. I'm OK with it.

> hiatus between the two events.

Dear Bill and Ross, cc: Brian,

Grrr. Adrian is caught between saying WGLC="we think we know what the answer 
is, but it could change" and saying RFC Editor queue="we knew what the 
answer was at some point in the past, but couldn't tell you then because it 
could have changed". I know that the fairly-new IESG guidelines for document 
handling timelines is shorter than two years, and I know the RTG area has 
been reducing their backlog.

Want to tell him that two year hiatuses (hiatii?) are a memory of the Bad 
Old Days? :-) The current text will probably generate a "but you TOLD US 
that it had been approved in WGLC!!!" conversation sooner or later.

> Actually, there wasn't any intent to promise review.

Ah. Then should this be saying, "if you work on a solution anyway, we still 
reserve the right to review it"? In legalese, of course.

> I think I had become tired.

:-) I can imagine why...

Have a lovely American Thanksgiving (much like Bastille Day - even if you 
don't celebrate it, there IS a July 14th on the calendar in most countries 
:-)