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

[Kireeti Kompella <kireeti@juniper.net>]

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.