[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IANA Considerations for RSVP



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