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

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

Deborah,

> I don't think you are requesting IETF to simply endorse another
> sdo's work without review (unless the interpretation of assist=review),
> and I am not so sure about the promotion either.

This is not quite what I am trying to say -
Presumably the other SDO starts communication at the problem statement
phase (e.g., the Oct 2001 liaisons SG15 to ccamp). IETF is free to decide
if it makes sense for IETF to be involved in development of the solution.

If they decide not to be involved and the other SDO goes ahead with
developing their own solution, they don't need to bless the extension,
or even like it, but they do need to accept it. At this point we may
as well document it in an info RFC (not standards track for IETF) and
make sure the codepoint assignments are done in a way that avoids conflict
or overlap with other extensions.

There is another subtlety that perhaps I failed to capture in
enough detail. If the IETF does decide to be involved, their involvement
is in applying their protocol expertise in determining HOW to solve the
problem that the other SDO has raised. I am uncomfortable with a
process that leaves the IETF as the sole arbiter of WHETHER the problem
will be solved or whether the requirements developed by the other SDO
are valid. The application domain being addressed by the other SDO
may very well be different than the one being addressed by IETF, and
the validity of what the other SDO sees as their requirements for
their application domain is not for IETF to decide.

I am also a concerned with the following:
> One option suggested by Kireeti "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."
This seems like a road to chaos. You end up with a proliferation of
(G)MPLS-like protocols which are all slightly different whenever there
is a requirement of another SDO that IETF doesn't accept or understand.
I think if we can come up with something more of the "clearinghouse"
flavor, we can at least keep a common umbrella over the family of
IETF and non-IETF developed extensions (based on whether IETF had
the interest or expertise to be involved in any particular extension),
to understand (as Stephen Shew pointed out) which extensions can
co-exist, to avoid conflicts, etc.

Regards,
Steve