Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Tue, 25 Feb 2003 18:19:55 -0500

Loa,
(I included ccamp as I was not sure everyone is on the mpls list)

The draft does not include any reference to liaisons (inputs from other standards groups). Will there be a separate process for liaisons or this draft will be extended to include? It would be useful (especially for other standards groups) to have clarification on how liaisons are input to a WG, generation of responses, and process required to coordinate work/initiate work within a working group in relation to other standards groups.

On section 2.2.2 problem statement review, and in other steps where decisions are taken, it would help to clarify if say that the decision (e.g., 'no action') plus the basis for the decision be posted to the Area/WG mailing list within a specified time period.

Thanks,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 14, 2003 6:44 AM
Subject: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: MPLS and GMPLS Change Process
	Author(s)	: L. Andersson
	Filename	: draft-andersson-mpls-g-chng-proc-00.txt
	Pages		: 11
	Date		: 2003-2-13
	
This memo describes the process through which individuals, working
groups and external standards bodies can influence the development of
MPLS and GMPLS standards.  With respect to standardization, this
process means that (G)MPLS extensions and changes can be done through
the IETF only, the body that created the (G)MPLS technology.  The
IETF will not publish a (G)MPLS technology extension RFC outside of
the processes described here.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-andersson-mpls-g-chng-proc-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 25 Feb 2003 15:39:26 -0800 (PST)

Hi Deborah,

On Tue, 25 Feb 2003, Brungard, Deborah A, ALABS wrote:

> The draft does not include any reference to liaisons (inputs from other
> standards groups). Will there be a separate process for liaisons or
> this draft will be extended to include? It would be useful (especially
> for other standards groups) to have clarification on how liaisons are
> input to a WG, generation of responses, and process required to
> coordinate work/initiate work within a working group in relation to
> other standards groups.

Good point.  CCAMP has received liaison statements in the past and
we haven't really responded to them -- in fact, I am not even sure
that there is a written process to handle liaison statements, nor a
well defined return channel.

Since this draft is about writing down processes, we should (a) figure
out how liaisons are handled; and (b) write that down as well.

Ron and I will have a pow-wow with the ADs and figure this out.

> On section 2.2.2 problem statement review, and in other steps where
> decisions are taken, it would help to clarify if say that the decision
> (e.g., 'no action') plus the basis for the decision be posted to the
> Area/WG mailing list within a specified time period.

Another good idea -- in line with the "new IETF with better visibility
and accountability" thrust.

Kireeti.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 26 Feb 2003 01:51:14 +0100

Deborah,

the non-mentioning of the liasions are quite intentionally, since we 
thought
that the liasion process is quite well described, understood and used. 
Later
communications have brought to our attention that this assumption is not 
entirely
true.

However, my take is that the liasions and the change-process address two
orthogonal issues. The liasion addreses how information is exchanged 
between
IETF and other organisations, this could be anything from general info 
on latest
development to specifics that one of the organisations sees as useful 
for the other
to be aware of.

It is below my current horizon if the liasion process needs to be 
defined in more
detail and in a draft ov its own, I guess I* in general and Harald in 
particular
could have a view on this.

The change-process on the other hand addresses a specific issue, how 
propsed new
work for the (g)mpls technology is accepted or rejected. This is 
something I feel
more comfortable to discuss than the IETF realtionships to other 
organisations.

In my mind there is no overlap between those two processes, the change 
process
in no way changes or affects the liasions, and the liasions is not the 
format to
bring new work into the IETF (in this case the (g)mpls) working groups. 
IETF working
groups work with Internet Drafts, either individual drafts or working 
group drafts.

I'm not entirely clear on if something that leaves one organisation as a 
liasion
could be received by the IETF as an Internet Draft, all other things 
equal. However
once it reaches the IETF, it will become an ID and published as such. In 
the other
direction I think it is clear if IETF or one of its working groups want to
communicate with another organisation, we will have to go through the 
liasion
process, that involves some approval on the iesg level. We do this out 
of respect
for how those organisations has told us they want this type of 
communication to
be handled and what format to use. What we do in the change process, is 
basically that
we give the same level of information on what is our process to 
accept/reject new
work and specifies input format to that process, declare that as long as 
we get
the input in that format we will in a timely fashion act on this input, 
and also
ask others to respect how our processes work.

I also agree on that if we can clarify and make more precise on how 
decisions are
taken, documented and communicated, though we need to remember that 
everything that
is a decision in this meaning will be taken by the iesg. Again I'm under 
the
impression that there is a quite well understood and used way of taking, 
documenting
and communicating iesg decision. You might be right that when it comes 
to wg chairs
and ADs and the responsibility to communicate (iesg) decision relating 
to the
working group in general and the people the made the proposal in 
particular, the
change-process could very well state something.

Hope this clarifies at least some of the issues!

/Loa

---

From: Scott Bradner <[email-masked]>
Date: Wed, 26 Feb 2003 04:29:18 -0500 (EST)

this ID was brought up in a meeting I am at in the ITU - there 
is some concern about it - I have asked that people with 
concerns please send their concerns in.

Scott

---

From: Scott Bradner <[email-masked]>
Date: Wed, 26 Feb 2003 04:45:09 -0500 (EST)

>.Good point.  CCAMP has received liaison statements in the past and
> we haven't really responded to them -

this was pointed out to me (again) this week :-)

we (the IETF) need to work out a reliable way to respond to liaison
statements

Scott

---

From: Scott W Brim <[email-masked]>
Date: Wed, 26 Feb 2003 15:53:13 -0500

On Wed, Feb 26, 2003 08:05:35PM +0100, Loa Andersson allegedly wrote:
> We need to document the (g)mpls-change process, most of this is in the
> current draft. The concerns I've seen so far is on how and what could
> be accepted as input to the process, that should be easily solvable.
> 
> We need to doucment the ietf way of responding to liasions.
> 
> It is my immediate reaction that this do not really belong in the same
> document, if for no other reasons, at least for practical reasons. If
> there is a strong motive to put them in the same document, I can live
> with that.

They don't.  The change process is specific to a particular protocol
group.  Liaisons are an IETF-wide issue.

I think if we want to send a liaison to another group, the AD just sends
e-mail, and archives it on ietf.org.  That's just an administrative
matter, nothing we even need a draft for.

Incoming liaisons take a little more policy but not much.  We want them
archived, so just saying "submit a draft" isn't good enough.  I'm afraid
we need to provide mailto:[email-masked], and yet another folder
on the web pages.  All ADs get to hear about all incoming liaisons, and
if they think it's appropriate for one of their WGs they forward it.
Done?

But this shouldn't be discussed on these lists anyway :-)

---

From: Stephen Trowbridge <[email-masked]>
Date: Wed, 26 Feb 2003 15:21:26 -0700

All,
draft-andersson-mpls-g-chng-proc-00.txt seems to be addressed at a
noble goal of bringing some order to new applications and extensions
of the (G)MPLS protocols. However, as Deborah, Kireeti, and Scott
have observed, the way it is written it seems to hinder rather than
help the process of collaborating with other Standards Developement
Organizations(SDOs) and doesn't provide a good way to deal with and respond
to liaison statements, which is the avenue by which many of these
requests will arrive from other SDOs.

It speaks well for the protocols that others will find applications
of them beyond the scope for which they were originally designed, and
even outside the scope of areas addressed by the IETF. The document as
written creates impediments to the ability to apply, and extend as
necessary, these protocols to new problem spaces. I think it would be
a far better goal to promote the reuse and widest application of these
protocols, and to try to enable these new applications through a
process that keeps some order to the applications and extensions of
the protocols.

As noted, biggest flaw seems to be the way in which the document deals
with new applications or requirements identified by external standards
organizations. In addition to not recognizing that this information may
come to IETF via liaison statements, the document seems not to consider
the fact that there may be a valid application that is outside of the
scope of IETF (and in the scope of another standards development
organization) to which the (G)MPLS protocols may be applied, and for
which the (G)MPLS protocols may require extension. By insisting that
every possible extension be done internally in IETF, the IETF either
(1) Extends the scope of its work without bound; or (2) Needlessly
restricts the application of its protocols. Neither one of these is
good for IETF or for the Standards Development community at large.

One reality that this draft fails to recognize is that, while IETF may
be able to say "no" to standardizing something proposed by an individual,
it does not have the ability (or the right) to say "no" to something
proposed by another Standards Development Organization. As a practical
matter, the IETF is not the only place where something can be standardized.
If the IETF creates impediments to applying IETF protocols to
the application space of another standards development organization,
there is really nothing that the IETF can do to prevent that the other
organization standardizes something themselves. The result would tend
to be a proliferation of (G)MPLS "like" protocols instead of a coherent
suite of protocols with broad applicability. This result would not be
good for the IETF or the industry in general.

A better approach would be for the IETF to PROMOTE the use of its
protocols for new applications, and, when another Standards Development
Organization wishes to apply (G)MPLS protocols to an application domain
outside of the scope of IETF, that IETF will (1) assist with the development
of any necessary extensions; and (2) to facilitate documentation of
such new applications and extensions in a central place (e.g., by
informational RFC, even for extensions that are developed outside of
IETF) and to insure that code points are assigned in a coherent manner
through IANA to avoid collisions where different extensions may use
the same code points to indicate different things.

I think that this could lay the groundwork for a much more constructive
collaborative relationship between the IETF and other Standards Development
Organizations than the draft as it stands.

The difference in flavor for what I am proposing is that IETF should
try to position itself as a Clearinghouse for (G)MPLS protocol extensions
rather than as a Gatekeeper for (G)MPLS protcol extensions.

What I have included below are some specific proposed text changes to
try to change the flavor of the current draft to try to accomplish this.

One final question regarding the applicability of this draft: The
sub-IP area is still classified as a temporary area, and it seems
that this particular procedure that will not be valid as written if
remaining sub-IP work is returned to the "native" IETF areas. I
don't have any specific suggestion as to how to solve this problem.

My specific text proposals follow below.
Regards,
Steve

Specific text proposals are as follows:
=======================================================================
Abstract
 Original Text:
   This memo describes the process through which individuals, working
   groups and external standards bodies can influence the development of
   MPLS and GMPLS standards.  With respect to standardization, this
   process means that (G)MPLS extensions and changes can be done through
   the IETF only, the body that created the (G)MPLS technology.  The
   IETF will not publish a (G)MPLS technology extension RFC outside of
   the processes described here.
_______________________________________________________________________
 Proposed New Text:

   This memo describes the process through which individuals, working
   groups and external standards bodies can influence the development of
   MPLS and GMPLS standards.

   MPLS and GMPLS technology has attracted the interest of individuals
   and other Standards Development Organizations (SDOs) to apply and,
   where necessary, extend the protocols to cover problems and
   application spaces beyond those for which the protocols were
   originally designed. This speaks well for the architecture of the
   protocols that they can find such widespread application, and it
   is highly desirable to find ways to reuse and extend existing protocols
   rather than inventing new protocols to address these other problem
   areas.

   The challange going forward is to find ways to maximize the opportunities
   for reuse of these protocols, while trying to maintain architectural
   integrity of the protocols themselves. This draft outlines a proposal
   for such a process.

==========================================================================

Terminology:
Add:
problem statement liaison
  a formal liaison statement from another Standards Development Organization (SDO)
  that initiates the discussion on extending the (G)MPLS protocols. This
  liaison will generally include a detailed problem description and a set of
  requirements that the (G)MPLS protocols need to meet to solve the problem.
  Such a liaison statement may contain a draft or approved document from
  the originating standards organization that characterizes the problem,
  indicating the level of agreement or approval that such a document has
  acheived in the originating organization.

Supplement existing definition:
requirement evaluating working group (rewg) -
  in the process descreibed below, the Working Group charged with the
  task of evaluating a certain problem statement and a certain set of
  requirements is termed the rewg. The focus of this group is somewhat
  different for the cases described here based on whether the problem
  statement and requirements came from an individual or another Standards
  Development Organization (SDO): in the individual case, the group may focus
  on assessing the validity of the requirements. In the case of a problem
  statement or requirements coming from an SDO, the other SDO may already
  have decided that the problem statement and requirements are valid for
  their application space, so the focus is directed more toward evaluation
  of whether IETF should be involved in developing the solution to that
  problem.

==========================================================================

Section 2.1 Overview

  The existing diagram should be labeled "Procedure for initiation of New
  Applications and/or Extensions to (G)MPLS Protocols by Individuals".
  Even for individuals, there seems to be a missing "shortcut" from the
  document procedure. It seems to be assumed that we have already developed
  complete, perfect solutions to everything within the current charter,
  and not allow for the possibility that there is some missing element or
  overlooked requirement that may require a (G)MPLS extension that is
  within the current charter. This may require a line directly from the
  "review by wg chairs and ad's" box to the "IETF WG process" box to indicate
  the path taken where the problem statement is considered to fall entirely
  within the current charter.

  An additional diagram should be included labeled "Procedure for
  initiation of New Applications and/or Extensions to (G)MPLS protocols
  by other Standards Development Organizations (SDOs)"

         +---------+               
         |problem  |               
         |statement|<--------------------------------------------- Originating
         |liaison  |                                                  SDO  |
         +---------+                                                   ^   |
              |discusson                                               |   |
              |on mailing                                              |   |
              Vlist                                                    |   |
         +---------+                                                   |   |
         |review by|      NACK                                         |   |
       +-|WG chairs|--------------+                                    |   |
       | | and ADs |              |                                    |   |
       | +---------+              |                                    |   |
       |      |request IESG/IAB   |                                    |   |
       |      |to appoint rewg    |                                    |   |
       |      |and charter        |                                    |   |
       |      Vreq eval           |         +-------------------+      |   |
       | +---------+              +-------->|liaison indicating |      |   |
       | |IESG/IAB |              +-------->|out of scope or    |----->|   |
       | |decision |              |   +---->|interest for IETF  |      |   |
       | +---------+              |   |     +-------------------+      |   |
       |      |rewg chartered     |   |                                |   |
       |      |to work on         |   |                                |   |
       |      Vproblem statement  |   |     +-------------------+      |   |
       | +---------+       NACK   |   |     |liaison explaining |      |   |
       +>|rewg req |--------------+   |     |how problem can be |----->|   |
       +-| eval    |----------------------->|solved with        |      |   |
       | +---------+ no change reqd   |     |existing protocol  |      |   |
       |      |  |                    |     +-------------------+      |   |
       |      |  |         ACK        |                                |   |
       |      |  +------------------------------+                      |   |
       |      V                       |         |                      |   |
       | +---------+                  |         v                      |   |
       | |AD review|                  |     +-------------------+      |   |
       | +---------+                  |     |liaison accepting  |------+   |
       |      |request to IESG/       |     |new work item      |          |
       |      |IAB to approve         |     +-------------------+          |
       |      Vcharter changes        |         ^                          |
       | +---------+         NACK     |         |        +------------+    |
       | |IESG/IAB |------------------+         |        | Externally |    |
       | |decision |----------------------------+        | Developed  |<---+
       | +---------+         ACK                         | Solution   |
       |      |wg chartered to                           +------------+
       |      |work solution                                    |
       |      V                                                 v
       | +---------+                                     +------------+
       +-|IETF WG  |----/ /----> stds track RFC          | IANA code  |
         |process  |                                     |   points   |
         +---------+                                     +------------+
              ^                                                 |
              |                                                 v
          solutions                                        info RFC
             ID

=========================================================================
Section 2.2 - Change title to:
2.2. Changes or Extensions to (G)MPLS Protocols Initiated by Individuals

could also consider deleting item 4 of 2.2.4 since new section 2.3 is
proposed to handle proposals from other SDOs. item 4 of 2.2.4 would only
be valid in the case of an individual proposing a new problem to be solved
by extending (G)MPLS protocols that IETF decides would be better addressed
in another standards group. IETF could send a liaison to the other group
with the suggested problem. This case may not be important enough to
spell out explicitly in the document.

=========================================================================
Add new section 2.3:
2.3. Changes or Extensions to (G)MPLS Protocols Initated at the request of
     another Standards Development Organization (SDO)

2.3.1. Initiating changes or extensions to (G)MPLS Protocols

   If a Standards Development Organization (SDO) wishes to apply the
   (G)MPLS protocols to a new application problem space, or sees
   a need to extend the (G)MPLS protocols to support the requirements for
   that new application, they may inform the IETF in one of the following
   manners:

   -  An internet draft may be produced explaining the problem they are
      trying to solve and, if applicable, why the existing (G)MPLS protocols
      must be extended to address this problem. A note from the authors
      should be sent to the relevant mailing lists to initiate discussion.

   -  An SDO (particularly those SDOs with whom ISOC/IETF have a
      formal relationship, e.g, see RFC 3356 or ITU-T A.sup3, and ITU-T
      Rec. A.4 regarding the relationship and communication method with
      ITU-T) may also be communicated via a formal liaison or communication
      statement. Such a statement is posted via a link from
      http://www.ietf.org/IESG/liaison.html and advertised by the iesg
      secretariat (who posts the incoming liaison) via the mailing
      list to initiate discussion.

   The mailing list to use should be Area mailing list and, if known,
   the WG mailing list for the WG that will likely be the requirement
   evaluation working group. In the case of discussion initiated from
   an incoming liaison statement, the liaison may be addressed to a
   specific Area or Working Group and notification should me made to
   the indicated mailing lists accordingly.

   Note concerning work initiated as a result of a liaison statement:
   Often a liaison statement that indicates that it is for action will
   indicated a deadline. The ADs and WG chairs should be diligent to
   make sure that a reply liaison is generated by the requested date,
   even if all that can be reported by that date is current status or
   a positive acknowledgement of receipt of the information. When the
   IETF chooses to undertake work as a result of an incoming liaison,
   regular reports of progress should be made via reply liaisons
   including anticipated time frames for completion of the work. In
   this way, the originating SDO can assess whether they can wait for
   an IETF solution or should pursue other avenues.

2.3.2. Problem statement review

   The MPLS and CCAMP working group chairs in conjunction with the Area
   Directors will determine if the particular problems raised in the
   Internet Draft or Incoming Liaison should be evaluated by a working
   group. This decision will be based on mailing list discussion. If
   the decision is that a requirement evaluation is warranted a decision
   is taken on which working group should act as requirement evaluation
   working group (rewg).

   In the case where the decision is that the IETF will proceed with
   further examination of these requirements, the originating SDO should
   be informed of this decision in a reply liaison.

   In the case where the decision is that the IETF will not proceed
   with further requirements evaluation, the "dustbin" which would have
   been the result for an individual submission is not an option for
   the case where the problem satement and requirements have already
   been accepted by another SDO. Since the other SDO has already
   accepted the problem statement and requirements, the likelihood is
   that this will lead to a standardized solution whether or not IETF
   chooses to be involved. At the same time, IETF has an interest in
   the long term integrity of the protocol, and can choose one of two
   options:

   - Even though the particular problem may be out of scope for IETF,
     participants may have insight which would assist in the solution to that
     problem. For the integrity of the protocol, it is certainly best if
     similar problems are solved in similar ways, and since the IETF should
     have the broadest view of all applications of the protocol, they are
     in a position to offer helpful advice to the other SDO about how to
     solve it. This information should be collected from the aforementioned
     email discussion and sent to the other SDO in a reply liaison.

   - The IETF is not in a position to offer any advice or insight as
     to how the problem can be solved. In this case, the IETF should indicate
     to the other SDO via a reply liaison that the IETF cannot help them with
     the problem, and it is up to the other SDO to define any solution.

   In either of case, the reply liaison to the originating SDO should
   encourage them to document their additional application or protocol
   extension via an informational RFC, (to keep the most complete possible
   library of extensions in one place), and to have any protocol code points
   assigned via IANA to insure that there are no cases where the same
   protocol code points might mean different things in the context of
   different extensions developed by different SDOs. This documentation
   would also enable the IETF to have a repository of extensions that
   would enable it and others to assess relationships between extensions.
   Any two extensions might:

   - be complementary and be usable at the same time
 
   - co-exist at the same time but it would make sense to only use one or
     the other at a time 

   - not co-exist in an implementation but share a common base

2.3.3. Charter update

   If the chairs and the ADs both feel that the particular problems
   should be added to the MPLS or the CCAMP Working Group charter the
   ADs will propose specific charter modificiations for the Working Group
   to the IESG and the IAB. If the IESG and IAB approve of the charter
   changes the Working Group can then update its charter and start the
   work to study the requirements and the problems described in the
   Liaison statement.

2.3.4. Problem statement study

   The rewg will study the problem statement liaison statement and based
   on the evaluation, generate a response to the originating SDO and, if
   further work is to be undertaken within IETF, make such a recommendation
   to the IESG/IAB. The recommendation may be:

   1  that no extensions to the (G)MPLS protocols are needed since the
      problem can be solved by the protocols as they exist. In this case,
      the WG chairs shall coordinate generating a liaison statement back
      to the originating SDO explaining how their problem can be solved
      with the current protocols.

   2  that there is no interest in extending this protocol in IETF.
      Note that in the individual submission case (section 2.2.4) IETF
      is in the position to decide not to continue the work. However,
      in the case of work initiated due to a liaison from another SDO,
      the other SDO has already decided that there is a problem for
      which a standardized solution should be pursued. If IETF decides
      at this point not to pursue a standardized solution to the
      problem proposed by the incoming liaisons, a reply liaison is
      needed at this point with the same information content as discussed
      in section 2.3.2 if the ADs and WG chairs had decided not to
      pursue a standardized solution within IETF.

   In cases 1 and 2, IETF will not publish a standards track RFC to
   address the problem. However, should the originating SDO standardize
   its own solution, IETF will facilitate documenting that extension
   via an informational RFC and assignment of code points via IANA so
   that there is no conflict between this extension and those that may
   arise from other sources.

   3  that the problem is of interest to IETF and the IETF is interested
      in developing extensions to the (G)MPLS protocols to address the
      problem. If the problem falls within the current charter,
      the normal WG process can be followed at this point. A reply
      liaison should be generated to the originating SDO indicating
      IETFs intent to accept the work and pursue a solution.

      If the problem requires extensions to the charter of the appropriate
      working group and the ADs agree, the proposal will be brought
      before the IESG and the IAB. If the IESG (with IAB advice) agrees
      that the task should be added to that particular charter then the
      rewg can work on it with the aim of adopting a final set of
      requirements to be forwarded to the working group that will handle
      the specification of the protocol changes.

      If the ADs or IESG/IAB do not agree to the charter extensions,
      a reply liaison should be sent to the originating SDO as in item
      2 above.

      If a charter revision is agreed, a liaison should be sent to the
      originating SDO informing them of the revised charter and the
      intent to pursue the work.

   The rewg will study and clarify the requirements, merging them with
   others if warranted. The resulting requirements should be verified
   with the originating SDO via liaison, or other method is appropriate
   for that SDO. With concurrence from the originating SDO, the result
   is published as a requirements RFC. When the IESG approves
   publication of the requirements RFC it will add it as a new task to
   the protocol specifying Working Group charter.

   The protocol specifying working group will then develop the modifications
   or extensions to the (G)MPLS protocols needed to fulfil the requirements.
   In the case that the originating liaison has indicated any work or
   progress in the originating SDO to develop a protocol solution, that
   work shall be taken into account by the protocol specifying working
   group. To the extent that sound decisions have been made by the
   originating SDO, this should be used as the basis for the work in IETF.
   If errors are found, these shall be brought to the attention of the
   originating SDO via a liaison statement. Every effort shall be made
   to make sure that either the protocol is developed in one place, or
   the results are aligned if two specifications cannot be avoided.

========================================================================

Section 4 (obviously):
Add:
RFC 3471
RFC 3472
RFC 3473
RFC 3477
RFC 3478
RFC 3479
RFC 3480
========================================================================
References
Add:
[RFC3356]
     Internet Engineering Task Force and International
     Telecommunication Union - Telecommunications Standardization Sector
     Collaboration Guidelines. G. Fishman, S. Bradner. August 2002.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 26 Feb 2003 20:05:35 +0100

this might be a candidate for the understatement of the month :)

>we (the IETF) need to work out a reliable way to respond to liaison
My understanding of where we are now in this discussion it could be 
summarized as:

We need to document the (g)mpls-change process, most of this is in the
current draft. The concerns I've seen so far is on how and what could be 
accepted as
input to the process, that should be easily solvable.

It is my immediate reaction that this do not really belong in the same
document, if for no other reasons, at least for practical reasons. If 
there is a
strong motive to put them in the same document, I can live with that.

It has been pointed out that - inter-organization information, requests, 
suggestions
and communications are handled different by differnt organisations.

I think we should view the (g)mpls change process as IETF internal, and 
that we need
to add some text to explain how and when external documents sent to the 
ietf in
other format than IDs could and should be taken into the (g)mpls change 
process.

I will update the draft with some text addressing this, the darft won't 
be possible
to re-publish until after the IETF in SF, however we have allocated time 
on the ccamp
and mpls working group agendas for Ron to discuss the issues with this 
draft. I will
have this text ready in good time before this presentation.

/Loa

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 27 Feb 2003 00:57:18 -0800 (PST)

Hi Steve,

On Wed, 26 Feb 2003, Stephen Trowbridge wrote:

> However, as Deborah, Kireeti, and Scott
> Organizations(SDOs)

If this is the impression that my comments gave, I must have used the
wrong words.  The GMPLS change document is intended to help other SDOs
understand the change process, and as such *help* collaboration.

> and doesn't provide a good way to deal with and respond

This I agree with.  But as Loa pointed out, it was not the intent of
the gmpls change doc to address this issue -- that is the domain of
a different document; and as several people have pointed out by now,
the change document is very specific (a small set of WGs), whereas
a liaison document should probably be much broader (IETF-wide).

> The document as
> necessary, these protocols to new problem spaces.

I don't see this at all.  The IETF does have processes, for example,
RFC 2026.  So (I assume) does the ITU.  Most would consider writing
down a process for change, especially with the intent of maintaining
architectural soundness, a Good Thing, not an impediment.  Process
does on occasion slow things down.  Sometimes that is laudable --
deliberation vs haste; sometimes that is a price one pays in return
for avoiding chaos.  It takes longer for me to hang up my clothes rather
than throw them on the floor -- but I opt to hang them up.

> come to IETF via liaison statements,

Let's take these one at a time.  A liaison statement (LS) has not been
heretofore a replacement for an ID.  A LS of the form "we invite you
to take part in such-and-such meeting" or "we would like to bring to
your attention such-and-such work" are fine uses (in my opinion) for
LSs.  However, if an SDO thinks that x, y and z are requirements for
protocol foo, communicating this solely via a liaison statement is not
(again, IMO) the right approach.  Requirements need to be discussed,
possibly modified, and captured in some permanent form.  There is a
well established process in the IETF for that; introducing a new
vehicle for that process is neither necessary nor appropriate, at
least without a revision of 2026 that states this.  It is not the
intent of the gmpls change process to at the same time change the
IETF's process and to update 2026.

> the document seems not to consider
> which the (G)MPLS protocols may require extension.

Not at all true.

> By insisting that

The reason for insisting that extensions be done in the IETF is:
(a) the IETF developed the protocols, knows them best, and knows the
    bigger architectural picture in which they fit.  A good example
    is the (unnecessary) deprecation of RSVP messages in a recent RFC.
(b) when all is said and done, the IETF does own the protocols.

It is instructive to harken back to how CCAMP took extraordinary pains
*not* to change the SDH spec, nor even to give the impression of such a
change.  There was a clear recognition that SDH "belonged" to the ITU,
and when representatives felt that there was "intrusion", even if
unintended, CCAMP stepped back.  There were two reasons for this: we
recognized that we (as an SDO, not as individuals) didn't have the
expertise; and we wanted to maintain cordial relations.

> matter, the IETF is not the only place where something can be standardized.

I agree that the IETF cannot stop other SDOs from extending its
protocols; it can (I believe) insist that such modified protocols use a
new name to call out the differences.

However, the problem that the change document addresses is not what
other SDOs are doing, but what the IETF should be doing.  As far as
other SDOs are concerned, they can decide on their own to abide by
the IETF's rules if they want, or to forge ahead on their own, at
the risk (which they may consider worthwhile) of marring their relations
with the IETF.

> good for the IETF or the industry in general.

There is already a proliferation of GMPLS like protocols.  The OIF
has its own; the ITU is developing its own.  It is not the intention
of the change document to stop this, nor to create impediments.  But
there is the (fond!) hope that with such a change document in place,
other SDOs will say -- "hey, instead of changing the protocols ourselves,
there is this process whereby we can take our requirements to the IETF
and get the experts who really know that protocol to change it to meet
our needs."

> protocols for new applications

Far be it for me to say what the IETF should or should not do.  However,
I personally don't think the IETF should promote its protocols.  In the
final analysis, the IETF is concerned with running (and promoting) the
Internet.  Any protocols it designs should have that as the end goal.

> and, when another Standards Development

If the IETF is convinced that such extensions will in some way help
to achieve its own goals AND will not hurt the protocol, the IETF can
and should undertake the activity.  If the extensions do not match
the IETF's goals, but they don't hurt the protocol, there should be
a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to
yield the floor to some other SDO.

> rather than as a Gatekeeper for (G)MPLS protcol extensions.

The Gatekeeper function is for the case where the said extensions do
hurt the protocol (in the eyes of the IETF).  This is where the SDO
can decide, as you point out, that it can do it on its own, but
changes the name of the protocol so that innocent bystanders can tell
the difference.

Kireeti.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 27 Feb 2003 13:32:35 +0100

Kireeti,

thanks you captured most of my points and said it possibly more clearly
and more polite than I would have.

I just want to strengthen one of the points a bit. Chapter 2
bullet 4 says clearly

>   4  that the problem is real and that they would be solved with exten-
>      sions to the (G)MPLS protocols, but that this for some reason is
>       not best done within the IETF, but some other organization. The
>      IETF might in such a case come to an agreement with this organiza-
>      tion to specify the protocol extensions and that these will be
>      described in a ID sent to the IETF for review and eventually be
>      published as an RFC.
>
>
>  
>
How this could be contrued as trying to stop other organizations from
extending and improving the IETF protocols escapes my imagination, we
even offer to put our expertise in for eview and makes it possible
to use the IETF as a vehicle for publication-

Further in testing Stephen logic on "you are not alone" - if I came
to the absurd conclusion that I wanted to use Q.931 for label distribution
and I failed to convince ITU that this was a good idea, would then ITU
accept that the IETF or any other SDO published an extension to Q.931?
Those arguments cuts both ways!

Last, the IETF standards process works with IDs and RFCs, that one
working group (or a coupel of them) should start working with another type
of document (liasions) in that process is ... It would also take us
to the point where we need to do the same thing with the prefered
document from other SDOs. "You are not alone!"

How would ITU react if I started sending IDs to them?

I think I've clearly pointed out the limited scope of the change process,
recognized that there is a orthogonal problem on how we treats liasions
coming into the ietf, that the liasion process needs to be documented, and
that we will add text to address the limited intersection of
the change-process and liasion process in order to promote the cooperation
with other SDOs.

/Loa

---

From: Eric Rosen <[email-masked]>
Date: Thu, 27 Feb 2003 13:22:48 -0500

It seems to me that Loa's  document simply describes how the IETF works.  As
such, I'm not sure it is even necessary. 

True, many people have  noticed that the IETF is free to  ignore the work of
other standard organizations.  True, the  fact that a particular proposal is
made by another  standards organization does not even  give the proposal any
special weight in the IETF.

I think these are  good things, and the IETF should not  make any changes in
this respect.  Hence I don't think  Loa's draft (if it needs to exist) needs
to change.

Certainly  the  fact  that  some  position  is  articulated  in  a  "liaison
statement"  should not  give  it any  special  weight.  The  fact that  some
position is supported  by "a threshold number of  vendors and SPs" shouldn't
give it any special weight either.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Feb 2003 14:14:22 -0500

In message <[email-masked]>, Eric Rosen wr
> give it any special weight either.  

Eric,

I completely agree with you but would like to make one clarification.

The "number of vendors and SPs" should not be given any weight at all
in toward the rough consensus criteria.  However, implementation by
vendors and deployment by SPs should be given strong consideration
regarding whether there exists any "running code" and "independent
interoperable implementations".

The IETF shouldn't care who you think you are or who you work for if
you don't show up with running code.  This eliminates committee
contributions such as study groups with a spec and no code or
deployment (and sometimes no valid requirement).

The number of internet-drafts that were not advanced due to not having
concensus on a requirements statement is quite large.  Few rejected on
that grounds resurfaced later when a need became evident and extremely
few resurfaced and were later implemented.  Diffserv-TE is about the
only set of drafts to get pushed back, resurface, and get implemented
and this was not a liason work.

Curtis