RE: IANA Considerations for RSVP

["Lin, Zhi-Wei (Zhi)" <zwlin@lucent.com>]

Hi David,

I responded to an earlier message (you probably haven't seen it yet), but I just want to re-iterate some points here, especially the point about not wanting to work together.

I'm not sure whether you've followed the work in CCAMP WG, but I've made the point that the ITU-T has notified and provided status as well as their "draft" documents to IETF consistently and regularly for the last few IEFT CCAMP WG meetings.

As such, your point that you gave below I take it to imply that you either (1) have not followed the recent work in CCAMP, or (2) you choose to selectively ignore the work submitted to CCAMP. 

In either case I don't think this should be blamed on the folks who's (individually) submitted the work to IETF as individuals who are full-fledged members of the IETF community...

Zhi
 

-----Original Message-----
From: David Charlap [mailto:David.Charlap@marconi.com]
Sent: Thursday, January 23, 2003 11:15 AM
To: Brian Hassink
Cc: 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


Brian Hassink wrote:
> Didn't the IETF set the precedent by extending RSVP from an IntServ protocol to an MPLS protocol?

There's a big difference.  MPLS and IntServ are both IETF groups.  (And 
RSVP has/had its own working group anyway).  Also, most of the key RSVP 
people were involved in the development of RSVP-TE.

This is very different from what I'm describing - where people who have 
no prior RSVP experience decide that they can start changing it without 
understing it, and without even notifying the IETF groups that did all 
of the development work.

I'mnot saying that RSVP should never be extended.  I'm saying that those 
groups that are writing extensions should be consulting with those who 
have been developing and maintaining it (in the RSVP and MPLS groups) in 
order to ensure that:
	- Their goal can't be achieved without extending the language
	- That their extension doesn't overlap a similar extension
	  from somebody else.
	- That their extension doesn't significantly change the overall
	  semantics of RSVP.
	- That their extension is sufficiently flexible so that other
	  groups can build off of it instead of re-inventing the wheel
	  with yet another incompatible extension.

Not only isn't this happening, but there appears to be no desire to see 
this happen.

-- David