[Fwd: Re: IANA Considerations for RSVP]

[Jonathan Lang <jplang@ieee.org>]

I accidentally omitted Bob, CCAMP, and rsvp list from my original 
response.  Apologize in advance if you receive multiple copies.

Thanks,
Jonathan

-------- Original Message --------
Subject: Re: IANA Considerations for RSVP
Date: Thu, 23 Jan 2003 08:33:14 -0800
From: Jonathan Lang <jplang@ieee.org>
Reply-To: jplang@ieee.org
To: jplang@ieee.org
CC: mpls@UU.NET, kireeti@juniper.net, iana@ISI.EDU, sob@harvard.edu, 
mankin@psg.com, bwijnen@lucent.com
References: <200301222140.VAA00937@gra.isi.edu>

Bob,

Bob Braden wrote:

>Hardy friends who have stuck it out on the RSVP mailing list:
>
><snip>
>	3. The IANA Considerations draft should be published as an RFC,
>	perhaps after updating.  Here are some issues that might affect
>	this update.
>
I concur.  There needs to be an IANA Considerations draft published as
an RFC.

>
>	(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.
>
This is fine, but I'm not sure it's enough.  For example, the following
text came from an email posted on the ietf discussion list by Zhi, the
editor of "draft-lin-ccamp-gmpls-ason-rsvpte-04.txt", in response to a
debate about this very issue.

<zhi>Last time I checked, the IETF didn't change the protocols, 
individuals did through contributions.  The extensions requested for 
Call/Connection control were submitted by an individual.  The fact the 
ITU weighed in requesting approval of the changes is a separate issue.</zhi>

So if this was an individual contribution, then it wouldn't be tagged
"ITU-T_SPIFFY_SESSION"?

>
>	(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.
>
I would prefer that the majority of the assignments require
standards-track documents.  A few assignments could be left for "IETF
Consensus", which I don't think requires standards track ID.  And then a
few assignements for "experimental".

Thanks,
Jonathan

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