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

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

Dimitri,
I have to respond in the same flavor that I responded to John.

Why is it that when we send the same type of request to ATM
forum, the result is that they spend effort to try to understand
the problem we are trying to solve and provide a great deal
of helpful input directed at solving the problem we have raised?
They have been genuinely interested in trying to figure out how
their protocol can be applied and extended to solve our problem.

You mention needing a "decoder ring" to decipher G.8080 terminology,
yet this terminology is certainly as foreign to ATM forum as it
would be to ccamp (perhaps even moreso, since I think there is
far more overlap in attendance between ITU-T SG15 and ccamp than
there is between ITU-T SG15 and ATM forum). Yet ATM forum had no
difficulty to understand what we were trying to do and to help us
to develop the solution.

I do not think that this is because people in the ATM forum are
so much more intelligent than those in ccamp: in fact, many people
I have met in ccamp are absolutely brilliant. So if it is not the
ability of the people that prevents this kind of productive work,
I have to believe it is a shortcoming of the process.

IETF stands nearly alone in the community of International standards
development organizations in not taking incoming liaisons as a
very serious input. It is only recently that we even had a place
to post incoming liaisons for IETF (http://www.ietf.org/IESG/liaison.html).
Now it is important to develop a process to make sure that those liaisons
are considered.

In addition, IETF needs to be able to generate liaison statements
in order to effectively influence the work of other SDOs. IETF has
historically taken the view that they don't need to send anybody
anything because any information related to IETF can be found
on their web site or seen on the mailing list. But as a practical
matter, for most SDOs, input documents include contributions from
members, documents (like agendas and reports) prepared by those with
official positions, and LIAISON STATEMENTS. Surely you don't expect
that most SDOs will consider as serious input something that somebody
found on a web site or saw on a mailing list. To make IETF output
be an input to another SDO, in most cases IETF will need to formally
send it to the other SDO in the form of a liaison statement.
To date, IETF has been unsuccessful in doing this.
Regards,
Steve

Dimitri.Papadimitriou@alcatel.be wrote:
> 
> stephen
> 
> i am resending you the e-mail sent to john because
> i am not sure you have red it "> What we got from
> IETF ccamp was ignored (until we finally did the
> work somewhere else and tried to get code points
> assigned)."
> 
> ---
> 1) in order to initiate an action a clear under
> standing of the problem must be achieved by the
> ccamp wg community in order to make this happen
> 
> 2) expect that ietf community would understand
> the terminology used in g.8080 (and subsequently
> the issue) by sending a liaison was probably
> a bit too optimistic -> thus the idea was to
> initiate a sort of "decoder ring" (just to be sure
> that when we say a "table" we are all in common
> agreement on what a table is)
> 
> 3) instead of request changes to gmpls it would
> have been much more constructive to know really
> what are the architectural aspects covered by
> itu that are the key in enabling signalling for
> optical networks -> from that *clear* perspective
> the ccamp wg was expecting a "functional spec"
> i-d ... since the idea here was to understand
> the functional requirement outside of any specific
> signalling protocol (thus make abstraction of
> what was included in g.7713.x in a first phase)
> 
> 4) once terminology + functional aspects would
> have been understood by the ccamp wg deliver the
> right answer using the ccamp community tools and
> protocols
> ---
> 
> last it is not the ccamp wg consensus that has
> pushed itu editors to go to the info track ...
> 
> thanks,
> - dimiti.
> 
> Stephen Trowbridge wrote:
> >
> > John,
> >
> > > JD:  Is that a threat or a promise?  BTW, call & connection separation
> > > doesn't exist in PNNI either, at least up to the point that I stopped
> > > attending the ATM Forum.
> > Interesting that you should mention this.
> >
> > We sent liaisons to the ATM forum, just as we did to IETF ccamp.
> > The reaction we got from the ATM forum was a great deal of help to
> > extend the PNNI protocols to meet our requirements. They provided
> > us numerous, helpful comments all through the process of development
> > of G.7713.1.
> >
> > What we got from IETF ccamp was ignored (until we finally did the
> > work somewhere else and tried to get code points assigned).
> >
> > We seem to have different understandings of what the problem is that
> > needs to be solved. My belief is that the problem is that we don't
> > have a good process for dealing with liaisons in IETF, and this
> > inhibits the kinds of productive relationships between IETF and other
> > SDOs that exist between many other (non-IETF) SDOs.
> >
> > Some others on this thread seem to think that the problem is those
> > other pesky SDOs: after all, how could there possibly be a valid
> > problem statement or requirement that wasn't conceived of and developed
> > entirely within IETF? Every possible measure should be taken to
> > prevent that any work is done to address such requirements.
> >
> > What is your perception of the problem?
> > Steve
> 
> --
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491