[Rsvp] RE: IANA Considerations for RSVP

[John Drake]

Scott,

You saved me some typing.

John

> -----Original Message-----
> From: Scott W Brim [mailto:sbrim@cisco.com]
> Sent: Thursday, January 23, 2003 4:27 PM
> To: Stephen Trowbridge
> Cc: John Drake; David Charlap; Brian Hassink; Bob Braden; 
> rsvp@ISI.EDU;
> ccamp@ops.ietf.org; mpls@UU.NET; kireeti@juniper.net; iana@ISI.EDU;
> sob@harvard.edu; mankin@psg.com; bwijnen@lucent.com
> Subject: Re: IANA Considerations for RSVP
> 
> 
> On Thu, Jan 23, 2003 04:24:31PM -0700, Stephen Trowbridge 
> allegedly wrote:
> > John,
> > Hmmm... a bit IETF centric.
> > Because some portion of a problem space touches or uses an 
> IETF protocol,
> > then clearly the entire problem must belong to IETF.
> 
> The entire problem of signing off on extensions to the protocol does
> belong to the IETF, if you want them to be used outside of some local
> network.  That's for architectural consistency.
> 
> > Consider that the ASON architecture encompasses transport 
> networks where
> > what we call the transport plane (IETF calls the data plane) is not
> > necessarily IP. What if the addresses are NSAP addresses 
> instead of IP
> > addresses? What if some or all of the signaling links employ PNNI
> > as a signaling protocol instead of RSVP-TE or CR-LDP? Does it still
> > all belong to IETF? These are problems that cannot be solved without
> > good cooperation between the standards organizations that 
> are involved.
> 
> The IETF is responsible for defining the mechanisms by which those
> non-IP addresses can be carried in the IP-based protocol.
> 
> > In terms of the existance of a communication channel and 
> procedures for
> > collaborating between IETF and ITU-T, this exists but 
> perhaps, in spite
> > of receiving these liaisons, you have not taken the trouble 
> to become
> > familiar with it. Identical text describing the 
> collaboration process is
> > published as RFC 3356 in IETF and as A.Sup3 in ITU-T. We 
> are following
> > the documented process, and this suggests a different 
> answer than your
> > emails to the question of which side of this communication 
> channel is
> > not holding up their end.
> 
> I agree the communication channels could be used better.  I also think
> that the best way to communicate is probably NOT those channels, but
> rather to bring in parallel technical contributions in each group, to
> make sure they are in sync.  Take the ideas through the 
> procedures that
> participants actually care about.
> 
> swb
>