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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]