RE: IANA Considerations for RSVP

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

Hi Kireeti,


-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Thursday, January 23, 2003 1:53 PM
To: Lin, Zhi-Wei (Zhi)
Cc: David Charlap; Bob Braden; rsvp@ISI.EDU; ccamp@ops.ietf.org;
mpls@UU.NET; iana@ISI.EDU; sob@harvard.edu; mankin@psg.com;
bwijnen@lucent.com
Subject: RE: IANA Considerations for RSVP


Hi Zhi,

On Thu, 23 Jan 2003, Lin, Zhi-Wei (Zhi) wrote:

> Hi David,
>
> This seems like an unfair characterization. All requests are submitted
> by individuals. In terms of changing these protocols...

I beg to differ.  The publication request of the original RSVP-TE spec was
made *by the MPLS WG*.  The publication request of the GMPLS RSVP spec was
makde *by the CCAMP WG*.  Furthermore, the issue is not who submits the
document; it is the degree of scrutiny it gets.  *Standards Track* docs
go through a much stricter review than informational ones.

<zhi>Right. the set of ASON documents are all targeted for informational RFC, though and not standards track. It was recommended that such document should be submitted to assist IANA with codepoint assignment, and that's what was done...

In terms of degree of scrutiny, please see Steve's email on the history of trying to get feedback...this was really "like pulling teeth"...</zhi>


> The GMPLS RSVP-TE, which is done in IETF, makes major modifications to
> RFC3209 and RFC2205 version of RSVP. The rest of the changes been
> requested are three new objects, new error codes to support these
> objects. This can hardly be characterized as forcibly changing RSVP or
> major change in direction...

Do you consider deprecating ResvErr and ResvTear not "forcibly changing
RSVP or major change in direction"?

<zhi>I don't understand...where do you see that these are deprecated??? What is said in my document is that these messages we don't create because all teardowns are explicit. But when these are received, then we will take appropriate actions (see document).

Do you consider that if we don't transmit a message then this is in violation of the protocol? We're transmitting all messages in accordance with RFC2205/3209/GMPLS-RSVP-TE...There are approximately 20 message types, but GMPLS RSVP-TE only use a sub-set that's important to its function (e.g., DREQ and DREP are not mandatory for GMPLS RSVP-TE)...
</zhi>


Kireeti.