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