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

[Scott Bradner <sob@harvard.edu>]

yipe - go off-line for a long plane flight and kablooe the world 
explodes

You may rest assured that the intention of the ID (and the one that came
out today about change control for RSVP) is positive.

The basic concept is the same as RFC 3427 does for SIP - be sure that the
IETF is "in the loop" on extensions to IETF protocols.  Note that these two
IDs are 1st drafts and are meant to be discussed (that part seems to have
worked :-) )

We have had recent experience with the OIF UNI and ITU ASON documents that
it is easy to get into sort of a mess (and we are not accusing anyone
specific here). There were many reasons.  Including neglected liaison
statements from ITU and documents from ITU folk.  Clearly the IETF needs to
figure out a better way to deal with such messages (This was a topic at the
ITU-T TSAG (their sort of IESG) meeting this past week in geneva.)

So in order to try to regularize the change process with RSVP and (G)MPLS
the SUB-IP ADs with a few WG chairs prepared this document. The idea is
that we define the process so that it is clear how and when various steps
need to be taken and by whom. The doc is far from complete we suspect and
so comments (certainly ones with recommended wording) will be very welcome.
As noted above, these are first drafts and we expect that there will be
quite a few changes before these get adopted.

We also need to evaluate the issues w.r.t. to liaison statements. We think
we have seen quite a set of opinions on the usefulness and function of
liaison statements.  These opinions need to be evaluated and revised text
needs to be put in these documents to deal with them, but maybe this should
be done as a comprehensive IETF review of how we deal with liaison
statements.

It would be good to tone down the "discussion" a bit. We do not think that
making accusations etc helps the discussion.  The idea was to try and
prevent that from happening in the future. 
  
So now that you all have been able to blow of some steam, can you please
start to post constructive text proposals as how to do things in these
documents and relative to how the IETF deals with working with other SDOs
that want to use and extend IETF protocols.  

(BTW - it is not a bad thing that multiple SDOs want to make use of the
same protocols, it seems that it should be considered a good thing and we
should work out ways that using existing protocols or working together on
ways to extend current protocols is encouraged rather than making it more
likely that competing protocols doing the same function get developed.)

Thanks,
Bert and Scott