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

Barry Leiba <barryleiba@computer.org> Wed, 05 November 2014 18:32 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 614DC1A9121; Wed, 5 Nov 2014 10:32:10 -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 tLuQ7exOCrRM; Wed, 5 Nov 2014 10:32:09 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CFB11A9150; Wed, 5 Nov 2014 10:31:47 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id s18so1247410lam.13 for <multiple recipients>; Wed, 05 Nov 2014 10:31:46 -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; bh=GyWfzHJxjZCubRJ7bhC+mMAOSa9ZyAJbzeFmOJCM9bE=; b=rCJTn1ZiyzknruW8mNKhm+Q2LDS2mDiRh5DYvbtQNk1cwc2779rfOLCDRIobykPfqM eiktd1WUkj5isaCVxRHk5D/9VwLmBR6SPR5E3v/LplqgQv+8/Y1hNzKKJQSvJ9LnkTgd 4KkC06wCZepZG5vXFpmmwsiJC52qm0MvFeeS3IDlIsDTBGw+Bm0qzQuF/xZ0SB1GYMQv uWhtzys5Zd+1H8+7PTAdTfIPAPhF2vj97tObpbwN7EIaRsfkrkPLL277Zr/vjZDb7fcu VExifknLhrP9OKAx2DXfV1dNqaL0yXZG6CT8V0/RLJb0EZomd6QDz9XmCCYhCUGtAUF5 RwVA==
MIME-Version: 1.0
X-Received: by 10.112.57.227 with SMTP id l3mr69490027lbq.68.1415212305981; Wed, 05 Nov 2014 10:31:45 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.152.8.103 with HTTP; Wed, 5 Nov 2014 10:31:45 -0800 (PST)
In-Reply-To: <CAC4RtVC8ZXDQ8HVHMZZfbenh5XXkyPNhZrChkyKdgw-Nhop38g@mail.gmail.com>
References: <CAF4+nEFW5+v+crk-VQtZku3COZ8JY_wqQwXj13VeT6or9_=ZMg@mail.gmail.com> <CAC4RtVC8ZXDQ8HVHMZZfbenh5XXkyPNhZrChkyKdgw-Nhop38g@mail.gmail.com>
Date: Wed, 5 Nov 2014 13:31:45 -0500
X-Google-Sender-Auth: JIJrziixGPU5LRM4bPo8BBsBndY
Message-ID: <CALaySJLFBNgn=9wjDcMEpu_HCo1W7fFUGFrXqmLhoeBdNghjDQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Donald Eastlake <d3e3e3@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/uGAmQLW-C_DRCpKBgRwWyp_jaSs
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" <draft-leiba-cotton-iana-5226bis.all@tools.ietf.org>, "secdir@ietf.org" <secdir@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: Wed, 05 Nov 2014 18:32:10 -0000

Following up on a thing or two:

>> However, it is not clear to me that there is adequate defense against
>> denial of service attacks on IANA.
> ...
>> think Section 3.3 should clearly provide that IANA can go to the IESG
>> for anything that the IANA considers abuse of registration procedures.
>
> That seems like a reasonable addition; I will do that.

Here's what I added to the end of the section:

NEW
   IANA always has the discretion to ask the IESG for advice or
   intervention when they feel it is needed, such as in cases where
   policies or procedures are unclear to them, where they encounter
   issues or questions they are unable to resolve, or where registration
   requests or patterns of requests appear to be unusual or abusive.


>> In Section 2.3, we find
>>    "In particular, when a registry policy that requires involvement of
>>    Working Groups, directorates, or other bodies ..."
>> but in the IETF, Working Groups are transient entities. Registry
>> policy involvement of a WG not allowed and I have my doubts about
>> allowing "directorates". Use of a mailing list is OK because mailing
>> lists can be permanent.
>
> That text was a recent addition.  Do you have a specific suggestion
> for alternative text that gets the same point across?

I thought about it a bit more.  How about this?:

OLD
   In particular, when a registry policy that requires involvement of
   Working Groups, directorates, or other bodies to be actively involved
   and to support the effort, requests frequently run into concerns that
   "it's not worth doing a Standards-Track RFC for something this
   trivial," when, in fact, that requirement was created by the Working
   Group in the first place, by placing the bar that high.

NEW
   In particular, working groups will sometimes write in policies such
   as Standards Action when they develop documents.  Later, someone
   will come to the working group (or to the relevant community, if the
   working group has since closed) with a simple request to register a
   new item, and will be met with a feeling that it's not worth doing a
   Standards-Track RFC for something so trivial.  In such cases, it was
   a mistake for the working group to have set the bar that high.


>> And, at the very end of Section 2.3, it seems to imply that
>> "Specification Required" implies "significant community involvement"
>> which I think is wrong. My understanding is that there needs to be an
>> expert to judge that the specification cited in the assignment request
>> is adequate for interoperability.
>
> That paragraph does not say what I meant it to say.  It's possible
> that the parenthesized bit at the end is stray, but I'll have to go
> back to the earlier versions and see where that came from.  It needs
> fixing; thanks for pointing it out.

There was a missing word, but I re-worded the stuff in parentheses a
little more):

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 (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 Specification Required, in terms of
   the well-known policies).

Barry