draft-klensin-iana-reg-policy (Re: S stands for Steering)

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(_at_)mcsr-labs(_dot_)org> 
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 mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf