[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.