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

From: "Mak, L (Leen)" <[email-masked]>
Date: Fri, 28 Feb 2003 16:52:40 +0100

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:[email-masked]]
> Sent: vrijdag 28 februari 2003 16:18
> To: [email-masked]
> Cc: John Drake; Kireeti Kompella; [email-masked]; [email-masked]
> 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
> 
> [email-masked] 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 : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : +32 3 240-8491
>

---

From: Scott W Brim <[email-masked]>
Date: Fri, 28 Feb 2003 11:08:03 -0500

> a wider scope than ccamp and mpls.

Yes, but wrong problem.  They're working on truly fundamental processes
right now, and won't have room for issues of external relations until
they finish with the internals.