IANA Considerations for RSVP

[Bob Braden <[e-mail]>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[e-mail] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]


There is a growing unease about IANA assignments of RSVP parameters --
object numbers, CTypes, message types, and error numbers -- for new
uses of RSVP.  Many of these IANA requests, but not all, originate
outside the IETF in other standards bodies.  Many of the people from
outside the IETF were not part of the RSVP working group and so did not
absorb the technical rationale behind RSVP; in fact, they are sometimes
barely clued into IETF procedures at all.

As a sample, here is a part of a recent message from Kireeti Kompella,
co-chair of the CCAMP working group:

	"The problem I am trying to address is that folks are changing the
	RSVP spec with *Informational* documents that bypass much of the
	checks we have.  For example, the "GMPLS RSVP-TE for ASON"
	draft-lin-ccamp-gmpls-ason-rsvpte-04.txt defines new objects for
	the purpose of "call and connection separation".  I don't see any
	reason for such separation; even in the ITU (where this comes from),
	there is not a clear consensus that this is needed.  However, this
	document breezed through the IETF "process".

	Furthermore, it is an *Informational* document.  If this really was
	useful, and someone were to extend this, their document would have to
	be Informational by normative reference transitivity.  The worst part
	of this is that the base protocols (RSVP, RSVP-TE and RSVP-TE for
	GMPLS) were IETF protocols -- and then this piece has been usurped by
	the ITU (where the standards track documents will be defined).

	What I would like to see is the bulk of each space (messages, objects,
	class types, etc) being Standards Action, with some space for FCFS
	and Private Use."

This raises a bunch of technical and procedural questions; I will address
some of the latter below.

Several points should be made.

1. I volunteered several years ago to serve as the "designated expert" for
	RSVP registrations (RFC 2434), so every RSVP reservation request
	is referred to me.
		(Given the amount of recent aggrevation, this may not
		have been too wise a move for me.)

2. Just before the RSVP WG went dormant, its cochairs put together an
	IANA Considerations document and published it as an I-D.  I
	believe that it went through a formal WG last call; at least,
	the WG was given an opporunity to comment on, or object to,
	it.  It did not become an RFC, but it is available on the RSVP
	web site.  (I recently moved it to a more prominent spot in
	www.isi.edu/rsvp/pub.html).

	As the designated expert, I follow the rules in that draft.
	
3. The IANA Considerations draft should be published as an RFC,
	perhaps after updating.  Here are some issues that might affect
	this update.

	(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.

	(B) What policies should be imposed?

		The document currently divides the assignment space into
		two subspaces, for "IETF Consensus" and "FCFS".  RFC
		2434 lists various other possibilities; do we need any?

		Precisely what do we mean by IETF consensus?  Does this
		require a standards-track document?  (We thought it did.)

		We assumed that non-IETF requests would necessarily go to
		FCFS, but is it really FCFS + expert opinion?  In other
		words, how much oversight should we try to exert for
		non-IETF RSVP extensions?  I have seen some highly
		questionable extensions.  They tend to be micro-engineering,
		with no sense of a larger design.

	(C) What are the appropriate documentation requirements?

		Must there be an Internet Draft? An RFC?  We have
		tended towards the RFC, but the result is less than
		satisfactory.  These extensions are typically
		documented in some 373- page document published (or
		more often hidden) by the other standards body.  The
		I-D/RFC that is written for registration presents only
		a superficial summary of the data structures to be
		defined, with no context of explanation,  and a
		reference to the real 373 page document.

Bob Braden
Former co-chair of the RSVP WG
Current designated expert for RSVP assignments by IANA



----- End Included Message -----