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

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

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

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

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

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

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

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

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