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

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

Kireeti,

snip
> I have started (belatedly) posting to the CCAMP list that such liaisons
> exist.  Note that I don't need to do that for IDs -- the authors generally
> do that, and there is a mailing list that one can subscribe for this.
I saw this, and I think it is definitely a step in the right direction. Thanks!

> 
> > But it is my opinion that the lack of a liaison process is really
> > the ROOT CAUSE of difficulties like what we saw in January.
> 
> If we really do a root cause analysis, it comes down to this (IMO):
> a) CCAMP gets a liaison statement stating that certain changes are
>    requested in the GMPLS specs (doesn't get posted to the list, though).
Perhaps we didn't get an email out the instant something appeared in
http://www.ietf.org/IESG/liaison.html, but I think that (at least for
liaisons to ccamp from ITU-T SG15 since Oct. 2001) there was always
an email from the presenter (Wesam or myself) at the occasion of the
next IETF meeting with reminders about the location of the liaison information
and the slides presented in the meeting to explain them. So within a
window of time, I think all incoming liaisons were advertised.

> b) CCAMP doesn't officially respond (mechanisms not in place).
> c) CCAMP WG gets requirements via Zhi's and Osama's drafts.
> d) CCAMP mailing list hosts discussions about whether these requirements
>    make sense in the IETF context.
> e) In the interest of quick allocation of code points, these two docs
>    are made Informational, and go through without much review.
> f) Various folks (CCAMP, RSVP, MPLS, ...) are very concerned about the
>    changes made to RSVP and CR-LDP.
> 
> (The intent here is not to point fingers, although I've already claimed
> my share of the blame.)
> 
> I see (b) and (e) as the most serious breakdowns in the process.  The
> GMPLS change doc should help alleviate (e), and hopefully help (a) as
> well.  And if we get started on the liaison doc, that should help (b).
Personally, I think that if we had done a good job at getting the bi-
directional communication channel going at (b), we wouldn't have run
into problems at (e). Either ccamp would have been actively involved in
producing the solution, or people would have understood the reasons
why it was being done outside and been OK with it at (e).

What happened at (e) was a step to try to unblock some ITU-T work that
was stuck because we didn't get the right communication to happen at (b).
I think what some of us worry about here is that if we remove the flexibility
we had at (e) without fixing the communication problem at (b), then IETF
ends up (intentionally or unintentionally, depending on who in this thread
you believe) putting up roadblocks to the progress in other organizations.
This is why we feel that the liaison process has to be either a prerequisite
(or a co-requisite) of the change control process.

> Or we could keep talking :-)
I'm sure we'll do this anyway ...
> 
> Kireeti.

Regards,
Steve