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

Re: IANA Considerations for RSVP

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