Re: IANA Considerations for RSVP

[Kireeti Kompella <kireeti@juniper.net>]

Hi Bob,

On Wed, 22 Jan 2003, Bob Braden wrote:

> There is a growing unease about IANA assignments of RSVP parameters --
> object numbers, CTypes, message types, and error numbers -- for new
> uses of RSVP.

To come back to your email, I should say that I am happy that someone
else is also concerned about this.

> 3. The IANA Considerations draft should be published as an RFC,
> 	perhaps after updating.

Scant hours from the cut-off, I just submitted an ID (rsvp-change) that is
basically new IANA Considerations for RSVP.  This is intended to get the
discussion rolling.  I would suggest to folks who intend to take part in
such a discussion to read Bob and Lixia's document at
http://www.isi.edu/rsvp/DOCUMENTS/IANAconsider.txt .

> 	(A) How to handle requests for RSVP assignments for
> 		extensions developed outside IETF?
>
> 	    Here is my suggestion:
>
> 		For all assignments of numbers for extensions defined
> 		in non-IETF standards bodies, the IANA should use
> 		assignment names (e.g., object names) that are prefixed
> 		with the name of the responsible standards body.  For
> 		example, the "SPIFFY_SESSION" object would become
> 		"ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION",
> 		etc., object.

Not addressed in the rsvp-change ID, but should be.

> 	(B) What policies should be imposed?

The rsvp-change ID suggests three sets of spaces: Standards Action
(a standards track RFC is needed); Expert Review (used as the moral
equivalent of Experimental code points); and Private Use (no
registration).

> 	(C) What are the appropriate documentation requirements?

A lengthy discussion on the IETF mailing list still hasn't enlightened
me as to what "IETF Consensus" means.  Thus, the suggestion in the
rsvp-change ID is to use the "Standards Action" designation for code
points whose specification one cares about.

Kireeti.