[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IANA Considerations for RSVP
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
> (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
> (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.