Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-08

Barry Leiba <barryleiba@computer.org> Tue, 11 November 2014 02:58 UTC

Return-Path: <barryleiba@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 890791A887C; Mon, 10 Nov 2014 18:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 SpLlIgmYyTuS; Mon, 10 Nov 2014 18:58:00 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1D71AD4C8; Mon, 10 Nov 2014 18:58:00 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id gm9so8661347lab.5 for <multiple recipients>; Mon, 10 Nov 2014 18:57:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RNJ48VQdNZ44fi4ZomFM5HV/0T8OzaUPXg7WBIgBiIM=; b=T+gD/8+qW0QcGtYVClNwOtQW35L68wXOywPfyM4AwW+P5R7buKK5lLNJKxs+7AsZg6 l6oeU8JzXqEm9Q/qLgqawBzciWI87xpDEFjDsh2UDqYBK2oCaXBcDNRRiisPYLgragMZ 7cenBhmxQBQVpRMt4DqIQBvlin3T2Gbas45JC4jp5nq/U/iA+stu4nXBtIymK7wWULQe 04Aihl2BTU+bAAV083ORH54Cwn34ogzPwXdpaNnuuCg3gE6u985rfKw7Zmm/rs42biPG BDaKVe08cdSQRUho+eVS3nrnOFx9MVQkcu28M+GPFMxtUA9GMOZj9+bkgIUUqi/fDQik nrkQ==
MIME-Version: 1.0
X-Received: by 10.112.199.40 with SMTP id jh8mr33765221lbc.5.1415674678354; Mon, 10 Nov 2014 18:57:58 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.152.163.227 with HTTP; Mon, 10 Nov 2014 18:57:58 -0800 (PST)
In-Reply-To: <CAF4+nEH8c4SWtTG4tuqx5+e90OobMfRoHYZ6qpsoT5us3kH5Kg@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>
Date: Mon, 10 Nov 2014 16:57:58 -1000
X-Google-Sender-Auth: DoeRlXwQMCsQdHAo1rUUU5cs6Dw
Message-ID: <CALaySJKaBk7gX6CG0Pz7ZHbad+en6gDFPDZtuqd-AqOv_mkSUg@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Donald Eastlake <d3e3e3@gmail.com>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/9IvH-IhzGTWDnhseZMDi3JSVnoE
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 02:58:01 -0000

> 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

-- 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?

Barry