[Fwd: Re: IANA Considerations for RSVP]

[Jonathan Lang <[e-mail]>]

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 <[e-mail]>
Reply-To: [e-mail]
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail], 
[e-mail], [e-mail]
References: <[e-mail]>

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