Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-08
Donald Eastlake <d3e3e3@gmail.com> Tue, 11 November 2014 04:19 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C901AD3CA; Mon, 10 Nov 2014 20:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhYGqgG9iLKN; Mon, 10 Nov 2014 20:19:30 -0800 (PST)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D3F1AD3A4; Mon, 10 Nov 2014 20:19:30 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id va2so6844785obc.14 for <multiple recipients>; Mon, 10 Nov 2014 20:19:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jZzhUzdj9D6kVYDb5osN0A2L7F1ZCL7LmCXHMGJuQw8=; b=dBeTXUUSBKfiLflK6iiSmeEguyx8ARsBcHjeE6CS+AXko88o76PeJ8LBZ+2Rs52vi6 u+OvNSJlm1f+edsU+H7f96o020WkpgGUXK1mu8K7mZzRxB7t2UFXFwmrJQ+ChpfdafXQ 7jdfmhHDJ3DSNiM4yYExx7hFHwYOMZrxhw/Wq75rIxhui5bcMdPcnP1Fg4gZYM6Ag1ij hLxRKPGCOy33IW3OxWRWEpLbTBLYYE4xfjP/Cst5sFsDv2I9yYh4gHFOykZTCvW3DZYj DFKc64jnw4b0kmrIYmFLALSp/WFz0LZ8JYIqeuEfQCUjY+wUrDRu9RsfhunlGsHw0zfB XyFg==
X-Received: by 10.60.155.34 with SMTP id vt2mr30489520oeb.34.1415679569822; Mon, 10 Nov 2014 20:19:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.145.4 with HTTP; Mon, 10 Nov 2014 20:19:09 -0800 (PST)
In-Reply-To: <CALaySJKaBk7gX6CG0Pz7ZHbad+en6gDFPDZtuqd-AqOv_mkSUg@mail.gmail.com>
References: <CAF4+nEFW5+v+crk-VQtZku3COZ8JY_wqQwXj13VeT6or9_=ZMg@mail.gmail.com> <CAC4RtVC8ZXDQ8HVHMZZfbenh5XXkyPNhZrChkyKdgw-Nhop38g@mail.gmail.com> <CALaySJLFBNgn=9wjDcMEpu_HCo1W7fFUGFrXqmLhoeBdNghjDQ@mail.gmail.com> <CAF4+nEH8c4SWtTG4tuqx5+e90OobMfRoHYZ6qpsoT5us3kH5Kg@mail.gmail.com> <CALaySJKaBk7gX6CG0Pz7ZHbad+en6gDFPDZtuqd-AqOv_mkSUg@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 10 Nov 2014 23:19:09 -0500
Message-ID: <CAF4+nEF5TK2HkRaLs7_f163LgUjFGtZe5xgDe+rqThHp3FR=VQ@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vqLL0P_Rgt5r3Y3vEYN0k4x8Lec
Cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" <draft-leiba-cotton-iana-5226bis.all@tools.ietf.org>
Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 04:19:32 -0000
Hi Barry, On Mon, Nov 10, 2014 at 9:57 PM, Barry Leiba <barryleiba@computer.org> wrote: >> Sorry for delay in response > > 's OK. Delays Я Us. > > I think the only thing we're still stuck on is the Specification > Required vs Expert Review thing. I've had a chat with Thomas and > Harald. I have this to propose, so let me know, ASAP, what you think: > > -- Section 2.3 -- > > OLD > Therefore, working groups and other document developers should use > care in selecting appropriate registration policies when their > documents create registries. They should select the least strict > policy that suits a registry's needs, and look for specific > justification for policies that require significant community > involvement (those stricter than Specification Required, in terms of > the well-known policies). > NEW > Therefore, working groups and other document developers should use > care in selecting appropriate registration policies when their > documents create registries. They should select the least strict > policy that suits a registry's needs, and look for specific > justification for policies that require significant community > involvement (those stricter than Expert Review or Specification > Required, in terms of the well-known policies). > END That's fine. > -- Section 2.3.1 -- > > OLD > The well-known policies from "First Come First Served" to "Standards > Action" specify a range of policies in increasing order of strictness > (using the numbering from the full list in Section 4): > > 4. First Come First Served > No review, minimal documentation. > > 5. Expert Review > Expert review with sufficient documentation for review. > > 6. Specification Required > Expert review with significant, stable public documentation. > NEW > The well-known policies from "First Come First Served" to "Standards > Action" specify a range of policies in increasing order of strictness > (using the numbering from the full list in Section 4): > > 4. First Come First Served > No review, minimal documentation. > > 5/6. Expert Review / Specification Required > Expert review with sufficient documentation for review. / > Expert review with significant, stable public documentation. > END > > OLD > The description in Section 4.10 of "IESG Approval" suggests that the > IESG "can (and should) reject a request if another path for > registration is available that is more appropriate and there is no > compelling reason not to use that path." The IESG should give > similar consideration to any registration policy more stringent than > Specification Required, asking for justification and ensuring that > more relaxed policies have been considered, and the strict policy is > the right one. > NEW > The description in Section 4.10 of "IESG Approval" suggests that the > IESG "can (and should) reject a request if another path for > registration is available that is more appropriate and there is no > compelling reason not to use that path." The IESG should give > similar consideration to any registration policy more stringent than > Expert Review or Specification Required, asking for justification > and ensuring that more relaxed policies have been considered, and > the strict policy is the right one. > END > > That makes the two policies of equal or unspecified strictness order. > > WFY? I'm OK with an unspecified strictness order. But I think "Expert review with significant, stable public documentation." is highly misleading. In the absence of express additional criterion, Specification Required constrains the expert to only judging whether or not the documentation is sufficient. It should say "Significant stable public documentation sufficient for interoperability." or something like that. For the Specification Required case, the expert has a very limited remit and should be invisible to applicants. They either get back a code point or a statement that their specification was insufficient and needs more detail (or, I suppose, a statement that the code points are exhausted). I've also thought some more about this, trying to figure out why we are at such complete disagreement. Don't know that I came to any conclusion. Have you ever been in the position of seeking a code point assignment when you believed the relevant expert was both unconstrained by any specific guidelines and actively hostile to your effort? I have and I can tell you I would have loved for the criterion to be a simple Specification Required. So this may color my thinking. One possibility is that IESG members have the significant burden of having to appoint experts and somehow that makes all experts vaguely equivalent in the eyes of the IESG. So somehow you don't think that an expert authorized to use any reasonable judgement (by an unqualified "Expert Review" IANA Considerations, for example) is much different from an expert that is only authorized to determine if documentation is sufficient for interoperation (i.e., Specification Required) and think of them as about the same, even though I think it is like night and day. Another possibility is that these days most Specification Required IANA Considerations have additional instructions requiring experts to make judgements on matters other than whether the documentation is sufficient for interoperability. (In my opinion, since I think the ability of the Expert to apply reasonable judgement is the most important characteristic, that makes them really Expert Review.) Really, there are lots of unqualified Expert Review IANA Considerations. For example, look at www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml almost all the registries on that page are Expert Review with no additional guidance of which I am aware. > Barry Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com
- [secdir] SECDIR review of draft-leiba-cotton-iana… Donald Eastlake
- Re: [secdir] SECDIR review of draft-leiba-cotton-… Barry Leiba
- Re: [secdir] SECDIR review of draft-leiba-cotton-… Barry Leiba
- Re: [secdir] SECDIR review of draft-leiba-cotton-… Donald Eastlake
- Re: [secdir] SECDIR review of draft-leiba-cotton-… Barry Leiba
- Re: [secdir] SECDIR review of draft-leiba-cotton-… Donald Eastlake
- Re: [secdir] SECDIR review of draft-leiba-cotton-… Barry Leiba
- Re: [secdir] SECDIR review of draft-leiba-cotton-… Donald Eastlake