Re: IANA Considerations for RSVP

[Eric Gray <ewgray@GraIyMage.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]


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

--
Eric Gray

David Charlap wrote:

> 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