draft-klensin-iana-reg-policy (Re: S stands for Steering)
Harald Tveit Alvestrand <harald@alvestrand.no> Fri, 01 July 2005 10:27 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoIjk-0006SP-2C; Fri, 01 Jul 2005 06:27:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoIjh-0006Ql-2N for ietf@megatron.ietf.org; Fri, 01 Jul 2005 06:27:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28240 for <ietf@ietf.org>; Fri, 1 Jul 2005 06:27:02 -0400 (EDT)
Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoJ9d-0005th-Cw for ietf@ietf.org; Fri, 01 Jul 2005 06:53:54 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9481C61B49; Fri, 1 Jul 2005 12:27:02 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19800-07; Fri, 1 Jul 2005 12:26:58 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EA7A761AFD; Fri, 1 Jul 2005 12:26:57 +0200 (CEST)
Date: Fri, 01 Jul 2005 11:32:41 +0200
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: Spencer Dawkins <spencer@mcsr-labs.org>, ietf@ietf.org
Message-ID: <D07251C5026B6872A94D3256@B50854F0A9192E8EC6CDA126>
In-Reply-To: <07a201c57df2$f3699df0$0200a8c0@DFNJGL21>
References: <42C49B85.8050308@zurich.ibm.com> <20050629205127.CBD713F3F61@newdev.harvard.edu> <p0620070ebee8c42a0174@[10.0.0.171]> <fcf2cf5df5f126faf867b444ca01379c@ohiou.edu> <526CE8D0D8C36EF3B2392826@scan.jck.com><tsl8y0ra6d5.fsf_-_@cz.mit.edu> <42C469F8.600@dcrocker.net> <10673.1120190140@munnari.OZ.AU> <07a201c57df2$f3699df0$0200a8c0@DFNJGL21>
X-Mailer: Mulberry/4.0.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Content-Transfer-Encoding: 7bit
Cc:
Subject: draft-klensin-iana-reg-policy (Re: S stands for Steering)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
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@mcsr-labs.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@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… JFC (Jefsey) Morfin
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Scott Bradner
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Margaret Wasserman
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Scott Bradner
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Brian E Carpenter
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Hans Kruse
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… John C Klensin
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… John C Klensin
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… JFC (Jefsey) Morfin
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Brian E Carpenter
- Re: S stands for Steering [Re: Should the IESG ru… Joel M. Halpern
- Should the IESG manage or not? Sam Hartman
- Should the IESG rule or not? Dave Crocker
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… grenville armitage
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Jeffrey Hutzelman
- Re: Should the IESG manage or not? John C Klensin
- Re: Should the IESG manage or not? Jeffrey Hutzelman
- S stands for Steering [Re: Should the IESG rule o… Brian E Carpenter
- Re: S stands for Steering [Re: Should the IESG ru… Robert Elz
- Re: S stands for Steering [Re: Should the IESG ru… Spencer Dawkins
- Re: Should the IESG manage or not? Robert Elz
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Robert Elz
- Re: S stands for Steering [Re: Should the IESG ru… Dave Crocker
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Robert Elz
- draft-klensin-iana-reg-policy (Re: S stands for S… Harald Tveit Alvestrand
- Re: Should the IESG manage or not? Robert Elz
- Re: draft-klensin-iana-reg-policy (Re: S stands f… Robert Elz
- Re: Should the IESG manage or not? Masataka Ohta
- Re: draft-klensin-iana-reg-policy (Re: S stands f… Keith McCloghrie
- Re: draft-klensin-iana-reg-policy (Re: S stands f… Harald Tveit Alvestrand
- Re: Should the IESG manage or not? Sam Hartman
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Margaret Wasserman
- Re: draft-klensin-iana-reg-policy (Re: S stands f… Robert Elz
- Re: Should the IESG manage or not? Keith Moore
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Robert Elz
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Margaret Wasserman
- Re: draft-klensin-iana-reg-policy (Re: S stands f… David Hopwood
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Theodore Ts'o
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Pete Resnick
- Re: S stands for Steering [Re: Should the IESG ru… Theodore Ts'o
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… grenville armitage
- Re: draft-klensin-iana-reg-policy (Re: S stands f… David Hopwood
- Re: draft-klensin-iana-reg-policy (Re: S stands f… Spencer Dawkins
- Re: draft-klensin-iana-reg-policy (Re: S stands f… Ned Freed
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Robert Elz
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Keith Moore
- RE: RFC 2434 term "IESG approval" (Re: IANA Actio… Nicholas Staff
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… grenville armitage
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Brian E Carpenter
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Brian E Carpenter
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Brian E Carpenter
- Re: S stands for Steering [Re: Should the IESG ru… Brian E Carpenter
- Re: S stands for Steering [Re: Should the IESG ru… Bill Manning
- Re: draft-klensin-iana-reg-policy (Re: S stands f… Jeffrey Hutzelman
- Re: S stands for Steering [Re: Should the IESG ru… John C Klensin
- Re: S stands for Steering [Re: Should the IESG ru… Brian E Carpenter
- Re: RFC 2434 term "IESG approval" (Re: IANA Actio… Brian E Carpenter
- Re: S stands for Steering [Re: Should the IESG ru… bmanning