Date: Fri, 01 Jul 2005 14:11:47 +0800
From: Scott W Brim <sbrim@xxxxxxxxx>
Message-ID: <42C4DEA3.3050709@xxxxxxxxx>
Scot,
| Something like this must have a serious, long-term IETF review.
| We need to take the overall design of the Internet into
| account and not just be administrators.
How do you propose we enforce that? In more common circumstances
the way that happens is that the IETF refuses to publish a proposal,
which is generally effective, as what most people (seem to) want is
an RFC number that can use as a badge on their product.
Here, no-one, as best I can tell, ever wanted an RFC number. There
has been some opinion recently (from what I can tell, I certainly have not
read all of the messages) that they really should want an RFC number.
Nonsense.
While the IETF makes standards for use on the internet, and with the
internet protocols, nothing gives it the exclusive right to make such
standards, or to invent internet protocols.
Anyone can do that. W3C certainly does that. So can anyone else.
When they do it, they don't automatically get an RFC number to bandy about,
which many might see as a disadvantage, but if they don't need that, then
they just go ahead.
Whether anyone, and if there is anyone who they are that, uses the protocol
that's been designed is the ultimate judge of it, not whether or not it has
IETF blessing, or anyone else's blessing, or an RFC number.
The other tool we (pretend to) have is to refuse to allocate numbers in
the parameter registries, where a number is needed to make a protocol
work. We can certainly do that. But what effect do you expect that
will have? That is, what would you do, if you were denied a parameter
registration for your protocol?
Or, to make that query more specific, cisco designed (long ago) a
routing protocol (igrp, now eigrp), which I assume needs a port number,
or an IP protocol number, or a multicast address, or something like that.
What do you think would have happened, had the IETF (or IANA) replied
to a request for that parameter to be allcoated with a response like:
"Sorry, routing protocols are fundamental to the operation of the network,
we will not allocate a parameter for your protocol unless you have it
reviewed in the IETF, and the community agrees that your protocol is
a good one, What's more, we are already doing work defining routing
protocols, we don't believe that yours has any chance of success, so
please go away and don't come back."
Really, what would have happened? Do you really believe that cisco
would simply have dropped igrp and said "oh well, we lost" or something?
I certainly don't, and I cannot think of any reason why they should have,
nor why Dr Roberts' group should in this case.
Allocating a number for yourself is trivial. If you can't get one
assigned, then you self-assign. Anyone would. If you don't care
about the RFC number badge, then denying a paramater registration is
about as effective in actually preventing the protocol being used as
being flogged with (wet) spagetti would be (probably less so)...
Do you, or does anyone, really believe that we're better off with
data on the network, whose purpose we don't understand, for which
we have no idea what it is about, or how to find out more information
about it, than not having such data?
That's what the IANA registry is really all about - it is to make sure
that information about what exists is available, and we can discover
what is there, and manage to avoid conflicting with it. Attempting to
use it as an enforcement tool is highly counter-productive.
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf