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

[Dimitri.Papadimitriou@alcatel.be]

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