The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

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

Kireeti Kompella wrote:

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