--On Friday, 24 June, 2005 18:07 -0400 Sam Hartman
<hartmans-ietf@xxxxxxx> wrote:
> John> I would be happy to see it done that way.
>
> John> But I must have missed where in the IESG email it
> was John> suggested to Dr. Roberts that he proceed this
> way.
>
>
> We didn't. We let him know that if he wants to move forward
> he would need to move forward this way. If he does submit an
> internet draft I'm sure we will treat it in a fair manner.
> That would probably mean asking the IPV6 working group and the
> NSIS working group what they think.
>
> However, we did not ask him to go down that route. We think
> we have a good understanding of how the IETF would react to
> this proposal if it were brought to the IETF for review.
>...
Sam, I think we are in danger of asking the wrong questions here
and, in the process, causing serious damage to the Internet (and
to the IETF, which is somewhat less of a concern). The problem
has little or nothing to do with the specific technical merits
of the Roberts proposal.
Historically, we maintain registries of various protocol
parameters, not to endorse them, but to prevent conflicts in the
meaning/ interpretation of such things. A protocol can be
dangerous or harmful to the Internet and hence something that
should not be recommended. If such recommendations are
sensible, sensible people will follow them. If they are not
sensible, or we don't do a good enough job of explaining the
problems or getting the word out, or some people are just not
sensible, those people will do what they like: until we can have
the protocol police arrest those who do things on the Internet
of which the IETF does not approve, there is no stopping them.
All of that has to do with protocols, not parameter
registrations. The key purpose of a parameter registration or
allocation is simply to avoid conflicts between different
options/ approaches, whether individual ones of them are good
ideas or not. Our registration models were generally based on
the assumption that, if someone was going to use a particular
protocol variation, the only questions were whether they used it
with a parameter that IANA assigned and registered or, if not,
whether they would make up their own or use someone else's
(which, in the long run, amounted to the same thing), creating a
degree of hazard that differed with the particular base protocol.
Now, if the IESG decides to direct IANA to attach notes to some
parameter registrations that say, more or less "the IESG thinks
there is IETF consensus that the protocol that is bound to this
parameter emits a bad odor and is a Seriously Bad Idea and that
you shouldn't use it, please see RFC NNNN for details", I
personally think that would be a fine idea. But it is hugely
different from saying "no registration unless we think your idea
is a good one".
In the old days, when IANA was asked to evaluate a registration
request, there were basically only two issues on which a
registration could (and would) be rejected or returned for
clarification:
(1) the description of the protocol that goes with a
parameter was insufficiently clear that a system
receiving the parameter value would be able to figure
out what it had gotten.
(2) we had developed enough scarcity in the particular
parameter space that it was useful to ask questions
about whether the requested value was really necessary
or whether the need could be met in some other way.
Again, "necessary" didn't really translate as "good",
although I can remember cases --and people closer to the
IANA can probably remember far more-- in which an effort
was made to educate the applicant about why he, she, or
they should do something else.
I've copied Joyce Reynolds explicitly on this note in the hope
that she will be able to comment on whether my recollection of
the historical patterns is correct.
With the changes in the community in the last decade, and with
Jon's death and IANA's necessarily assuming less of an
evaluation function, we've shifted much of that evaluation
function to the IESG or people appointed by it. That seemed
sensible to me when the trend started and still does. But the
community has generally not consented to changing the criteria
about registration: registration is about avoiding
interoperability problems, not about good or evil. It was, and
remains, entirely reasonable to "bounce" a protocol parameter
specification on the grounds that one could figure out what it
meant and my recollection is that a number of parameter
applications were bounced for lack of clarity (including one or
two of mine). But that doesn't seem to be at issue here.
And, for a number of protocol registries, the scarcity problem
is a real issue. The IESG has, for example, directed IANA to be
much more aggressive about resisting public port registrations
than was the case 15 or 20 years ago. But resisting public port
registrations doesn't prevent anyone from launching a new
protocol, they are just pushed out into user space.
However, if the IESG believes that it is necessary to resist
parameter registrations involving IPv6 --which, again,
historically, was the only basis for rejecting a registration
other than lack of clarity or redundancy-- I suggest that we are
in serious trouble. Parameter space scarcity is a scaling
problem: we can slow the rate at which we run out entirely, but
we can't prevent running out. So, if, at this stage of IPv6
deployment, the IESG believes that it needs to restrict
registrations to options that the IESG thinks are "good" (or
that the IETF concludes or will conclude are "good"), then I
suggest that we need a WG, on an emergency priority basis,
looking at how to make those parameter spaces a _lot_ bigger.
But if, instead, we are simply binding allocation of protocol
parameters to the IESG's, or even the IETF's, notions of
goodness, I think we are going to get ourselves into a lot of
trouble, possibly to the point of making ourselves irrelevant
and encouraging chaos on the Internet. I may misunderstand
your note, but it seems to me that the reasoning you describe
heads us in exactly that direction.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf