You won't get your silence, Spencer, but thanks for trying!
I've now scanned the document, and I have found a number of points I
disagree with; most of them have to do with the crispness of the criteria
proposed.
I think the debate we're having is a good one - it's one of those conflicts
that's been lying like an undetonated land mine in our back yard for the
longest time. Now that we've finished dancing on the "IASA" land mine, we
may have the energy (and the amount of hospital supplies) needed for
dancing on the "using the IANA functions for control" one......
My opinion, in short:
1) I think the idea of describing *why* we are requiring registration is a
good one. I also think that this dimension is nearly orthogonal to the
dimension of *who* decides on a registration, which is what 2434 describes.
2) Objection to the history description: We have a LONG tradition (reaching
back at least to 1991, when I joined the IETF) of trying to use control
over registration as a means of guiding protocol developments. The
"experimental/standard" arcs of the OID tree in SMI, the very restrictive
requirements for new MIME top level types, the insistence that new charset
registrations be of charsets that already exist, and the requirements for
SMTP extensions are all living examples. So claiming that this is a "new"
development strikes me as strange - it would be better to say either that
this a practice of the last 15 years that should end, or that this is a
long-running conflict that ought to be resolved. (Others will have to speak
to the "before 1991" timeframe)
3) Documentation quality: "Documented" is a slippery word. I would suggest
that here too, a specific set of criteria be established, for example:
- the identity of the assignee and value requested/assigned is documented;
what it's used for is not. Example is the "private use OID space".
- some indication of the purpose of the thing is also given, but nothing
that would permit interoperability. Example: Port numbers.
- documentation sufficient to build interoperable implementations exists. I
fervently hope that all "standards action" assignments are in this category!
4) Scaling is good. But I think it the advice here ought to be much more
specific. We should be saying things like "Mitigation efforts need to start
NOW if there's less than 5 years' life in an existing namespace".
We know that standards take 2 years, and that changes to established
standards take a long time to get out.
(I'm also quite skeptical of all these MUSTs requiring action to avert
disasters - we know for certain that the AS number namespace is headed for
a crisis within finite time unless things change, we've got a WG that is
charged with doing something about it, but despite this, the mitigation
efforts (4-byte AS numbers) seem to have stalled. Different topic.)
5) I am quite unhappy with section 5.
A blanket redefinition of "IESG approval" as "documentation (satisfying an
IESG review) required" is, to my mind, wrong. People have written this
sentence into IANA considerations thinking that the IESG would make a
technical judgment on the parameter registration request. Changing the
meaning for all cases without asking the owning WG of each individual case
is, to my mind, a retrofit that goes too far.
The other part of section 5 is to require a Last Call for all rejections
done by the IESG; this is, to my mind, reasonable on its own - however, the
idea that the IESG can then take a solid IETF consensus that this
registration should be rejected because the technology is abhorrent,
harmful, damaging, immoral or something else that is important to the IETF
at the time, and then saying "yes" because the IESG was unable to find an
argument matching this document's criteria strikes me as "somewhat strange".
But this too is a change; if the people writing the IANA considerations
section had desired public review of requests, they would presumably have
used "IETF consensus" as the registration criteria; to me, the choice of
"IESG review" indicates that the writers of the IANA considerations section
thought that the IESG was able to come to a correct decision *without*
having to ask for an IETF consensus.
My suggestion for a change would be a bit shorter:
As an experiment, the IESG will send out Last Calls for all requests
requiring IESG approval that it wants to reject from <date> to <1 year
later>. At the end of that time, it will evaluate the result, and
either abandon the practice, modify the practice or make it a standard
procedure.
Summary: I think the document offers very good advice for future registry
management.
I think that a blanket retrofitting of a new meaning on the "IESG approval"
IANA considerations is a thoroughly bad idea.
--On 30. juni 2005 23:11 -0500 Spencer Dawkins <spencer@xxxxxxxxxxxxx>
wrote:
If I may plead for a moment of silence ...
There is an Internet Draft that is intended to give the community a
chance to provide comments on what the IETF vision of option registration
might be - or, might not be.
If we could discuss this draft, and say things like "I agree", "I
disagree", "goes too far", "doesn't go far enough", it seems to me that
we might actually be able to come closer to closure in this thread (and
its predecessors), one way or the other.
That URL, again, is
http://www.ietf.org/internet-drafts/draft-klensin-iana-reg-policy-00.txt.
And I apologize for having nothing whatsoever to say about spamops,
killfiles, or steering.
Thanks,
Spencer
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf