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

[John Drake <jdrake@calient.net>]

Stephen,

This is the note I sent yesterday, which I thought was fairly clear.

Thanks,

John
============================================================================
====================================
Kireeti,

Extremely well reasoned and thoughtful.  As I understand it, this document
is intended to prevent the situation that just occured, in which the IETF
published an RFC which detailed some changes to RSVP-TE (which had technical
issues) without any review by the CCAMP or MPLS working groups, thereby
explicitly appearing to endorse these changes.

The minutes of the Yokohama CCAMP meeting (see below) seem to indicate that
the CCAMP working group wanted to work on the ASON extensions, so I am still
puzzled as to why the authors of the ASON draft decided, after the Yokohama
meeting, to progress the draft as an informational RFC rather than as a
normal working group draft.

Thanks,

John

> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Friday, February 28, 2003 6:22 AM
> To: John Drake
> Cc: Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> 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
>