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

[John Drake <jdrake@calient.net>]

Kireeti,

Extremely well reasoned and thoughtful.  As I understand it, this document
is intended to prevent the situation that just occured, in which the IETF
published an RFC which detailed some changes to RSVP-TE (which had technical
issues) without any review by the CCAMP or MPLS working groups, thereby
explicitly appearing to endorse these changes.

The minutes of the Yokohama CCAMP meeting (see below) seem to indicate that
the CCAMP working group wanted to work on the ASON extensions, so I am still
puzzled as to why the authors of the ASON draft decided, after the Yokohama
meeting, to progress the draft as an informational RFC rather than as a
normal working group draft.

Thanks,

John

============================================================================
====================================
"Minute takers were volunteered (Josh Broch and Eric Gray) 

Snipped...

Osama Aboul-Magd presented status on his draft on ASON extensions to CR-LDP.

He asked if the WG would accept this as a WG draft. 

Kireeti pointed out that there is a meta discussion on the issue of
progressing both CR-LDP and RSVP-TE in the MPLS working group tomorrow and
suggested that the discussion should be taken to the mailing list after that
has been addressed. 

Snipped...

Dimitri Papadimitriou discussed work on ASON extensions to RSVP-TE. He asked
if the WG believes this to be valuable work and should eventually be put
forward to the ITU. 

Kireeti talked about the need to work out the relationship with the ITU on
these issues. 

Choy asked why the work does nt include call/connection information. 

Kireeti said that the functional specification should first capture the
solution independent requirements. 

Stephen Trowbridge asked what further information the IETF requires. 

Dimitri and Kireeti answered the question in detail."
============================================================================
====================================

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: Thursday, February 27, 2003 12:57 AM
> To: Stephen Trowbridge
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Hi Steve,
> 
> On Wed, 26 Feb 2003, Stephen Trowbridge wrote:
> 
> > 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)
> 
> 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
> > to liaison statements, which is the avenue by which many of these
> > requests will arrive from other SDOs.
> 
> 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
> > written creates impediments to the ability to apply, and extend 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.
> 
> > 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,
> 
> 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
> > 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.
> 
> Not at all true.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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."
> 
> > A better approach would be for the IETF to PROMOTE the use of its
> > 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
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.
>