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

["Mak, L (Leen)" <lmak@lucent.com>]

Wouldn't it be good to bring this whole discussion to the 
ietf-problem-statement mailing list? It appears to be of
a wider scope than ccamp and mpls.

Leen.



> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: vrijdag 28 februari 2003 16:18
> To: Dimitri.Papadimitriou@alcatel.be
> Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> 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
>