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.