Subject: [Rsvp] IANA Considerations for RSVP

From: Bob Braden <[email-masked]>
Date: Wed, 22 Jan 2003 21:40:12 GMT

Hardy friends who have stuck it out on the RSVP mailing list:

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

_______________________________________________
Rsvp mailing list
[email-masked]
http://mailman.isi.edu/mailman/listinfo/rsvp

---

From: David Charlap <[email-masked]>
Date: Thu, 23 Jan 2003 10:55:50 -0500

> barely clued into IETF procedures at all.

I've noticed the same thing.  It seems that many non-IETF groups want to 
use RSVP, and all believe that they must create extensions to the 
protocol for their features, often without first bothering to check if 
there are already obects defined by IETF standards that already serve 
their purposes.  And even in those cases where new objects may be 
required, the proposed objects are often defined as having semantics 
that differ greatly from the way RSVP usually operates.

In other words, these groups seem to want to forcibly change RSVP into a 
protocol that more closely resembles some other protocol that they're 
more intimately familiar with.

Personally, I don't like this.  These groups should step back and decide 
if RSVP is really what they need.  If they require a different protocol, 
then they should use a different protocol - they should not glom onto 
RSVP just because it's popular in MPLS and then try to change it into 
what they really want.  This is especially true in those situations 
where their proposed changes would produce a fundamentally incompatible 
protocol.

Unfortunately, I don't know what can be done about this.  These groups 
seem hell-bent on hacking up RSVP without first learning it's design 
philosophy.  If they don't get assignments from IANA, they'll probably 
just make their own assignments without any coordinating facility, and 
we'll wind up with several mutually incompatible protocols that all want 
to call themselves "RSVP".

-- David

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 23 Jan 2003 10:37:30 -0800 (PST)

Hi David,

> that differ greatly from the way RSVP usually operates.

Glad to hear you say that!

> more intimately familiar with.

No comment :)

> Unfortunately, I don't know what can be done about this.

It's not that hard.  As Bob said, redo the IANA Considerations
(and not just for RSVP) to require *well* documented specs that
go through tighter screening in the appropriate WGs.

Kireeti.

---

From: David Charlap <[email-masked]>
Date: Thu, 23 Jan 2003 15:17:58 -0500

Eric Gray wrote:
> 
>     The intent to build a new protocol, rather than bastardize an existing
> one has gotten a very large number of people burned in recent times. I
> can't say as I blame external organizations - who, in almost every case,
> have mostly only seen the flames from prior efforts coloring the sky -
> from opting to modify an existing protocol.
> 
>     We shouldn't chastise people for making what they feel are the best
> choices based on the evidence in front of them.  We should instead try
> to determine what they are missing, or otherwise help them to modify
> those choices.  :-)

You miss my point.

I'm not saying that groups should always build new protocols. 
Sometimes, there are perfectly good reasons to extend an existing 
protocol (like GMPLS extended RSVP-TE).

But when this is done, it should be done in conjunction with those 
responsible for the original protocol.

A third-party (like IEEE, ITU, ATM Forum, ISO, etc.) should never grab 
an IETF protocol and make changes to it without involving the 
appropriate IETF group.  (And I am not accusing any organization - these 
are just examples of the third parties I'm referring to.  I am not 
talking about different groups within the IETF.)

This goes the other way around as well.  Just as IEEE would object to 
the IETF unilaterally defining an extension to FireWire (IEEE-1392) 
protocol, the IETF should similarly object to some outside organization 
unilaterally defining an extension to IP, or RSVP, etc.

Now, I am not saying that every single third-party extension has done 
this.  I am well aware of the fact that some groups do work with the 
IETF on their extensions.  This is good.  This is the way it should be. 
  But there are other groups that do not.  If your (now speaking to 
everybody reading this message) group's extension was developed in 
conjungtion with the IETF, then my criticism is not directed at you, and 
you should not take offense at my opinion.

-- David

---

From: Eric Gray <[email-masked]>
Date: Thu, 23 Jan 2003 12:27:38 -0500

David,

--
Eric Gray