--On Tuesday, 05 July, 2005 15:09 -0400 Theodore Ts'o
<tytso@xxxxxxx> wrote:
>...
> People seem to be forgetting that the 'E' in IETF standards
> "Engineering", and that infinitely expandable registries in
> order to obviate the need for responsible registration of code
> points may not necessarily be the highest priority
> consideration, outranking all others....
Ok, Ted. Assume we agree (we probably do). Then what we need
is criteria that
(i) Will only allocate codes "responsibly".
(ii) Will not define "responsibly" in a way that _requires_ the
IETF to drop everything and perform an in-depth technical
evaluation, doing so in an open and transparent way, each time a
new allocation request come in. (That is, I believe, part of
the problem the IESG is, quite properly, trying to avoid.)
(iii) Will not define "responsibly", and how we determine it, in
such a way that the decision as to whether to allocate or not
can be determined, in private, by a small group of people who
may or may not, as a group, be expert in the area for which the
allocation is requested.
(iv) Will not permit the gatekeeper function for the
registration process to take on aspects (or even the appearance)
of a "not invented here" or "we wouldn't want conflicts with our
work" model.
Now, that is probably not impossible, but it is hard. Note that
no one, as far as I know, has advocated giving a code to any
lame request that comes along. Several of us have argued for
strong criteria about clarify of application. Borrowing from a
long and continuing discussion I've had with with RFC Editor, I
think it would be quite reasonable to require that anyone asking
for a new code have done a search and evaluation of alternatives
that are already out there and that the application contain a
critical review of those alternatives and point out why, in that
context, their proposed additional alternative is better... and
that such a review and explanation be able to pass at least a
laugh test among experts.
One can make a fairly high threshold out of such things. But
going further may be an engineering task that is more difficult
than designing code spaces that can be expanded --not
"infinitely" but sufficiently to meet any foreseeable need.
My suggestion is only that we need at least one of:
* Fairly open registration processes
* A moderately objective and open review process that
concentrates on quality of definition as outlined above,
and only secondarily on quality of protocol options.
* A protocol proposal review process that involves real
interaction with the community, with collectively open
minds on the part of the IETF experts, and that will
cumulate in registration, but presumably registration of
a more informed and better-developed protocol or
protocol option. In that model, there might be an
escape for "you don't get the code because you refused
to let your experts talk, in good faith, with our
experts" but, if we ever apply it, we had better apply
it carefully and after open discussion and public
attempts to engage.
I have trouble believing those options are unreasonable.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf