Re: [secdir] review of draft-arkko-pana-iana-02

Jari Arkko <jari.arkko@piuha.net> Wed, 24 February 2010 07:24 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9E628C214; Tue, 23 Feb 2010 23:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.423
X-Spam-Level:
X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g7S72DnMRQC; Tue, 23 Feb 2010 23:24:34 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E2BBF28C0D6; Tue, 23 Feb 2010 23:24:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 05B862D292; Wed, 24 Feb 2010 09:26:39 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wonMWkG4e9h; Wed, 24 Feb 2010 09:26:38 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 744542D287; Wed, 24 Feb 2010 09:26:38 +0200 (EET)
Message-ID: <4B84D4AC.7050603@piuha.net>
Date: Wed, 24 Feb 2010 09:26:36 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Dan Harkins <dharkins@lounge.org>
References: <566430fae4cc2ff8eab69b2df47c3a0b.squirrel@www.trepanning.net>
In-Reply-To: <566430fae4cc2ff8eab69b2df47c3a0b.squirrel@www.trepanning.net>
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-arkko-pana-iana.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] review of draft-arkko-pana-iana-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 24 Feb 2010 07:24:35 -0000

Dan,

> This draft changes the IANA rules for allocation of protocol fields
> to include "IESG approval". It really has no security considerations
> and this draft shouldn't warrant much attention from the ADs.
>   

OK. Thanks for your review.

> That said, however, I did find the rationale for relaxing the rules a
> bit unconvincing. When RFC 5191 was approved the reasons in the rationale
> applied but "IESG approval" was not included. Perhaps it was an oversight
> and the WG didn't really want such rigid rules. Or maybe deployment
> experience has caused a change of heart. Why now? And why add "IESG
> review"? Why not "First Come First Served" or "Expert Review"? What is
> it about "IESG review" that makes it appropriate to add now? The
> rationale in section 2 could use a bit more explanation. And it seems
> strange, to me at least, that a non-WG draft is relaxing rules the WG
> set up intentionally for its protocol.
>
>   "IESG approval" is supposed to be rare (according to RFC 5226) so maybe
> it would be possible to partition the ranges, leaving the lion's share
> the way it was-- "IETF review"-- and giving a reasonable chunk to "IESG
> approval" for the rare cases that this route is going to be used? If this
> was considered and rejected it might be good to mention that in section 2.
>   

Oversight: As far as I am concerned, not including IESG Approval *is* an 
oversight on all strict IANA allocation rules. If we are not ready to 
say FCFS for various reasons (and there are often good reasons) then at 
least we should provide an ability for someone to decide whether the 
strict rule is absolutely required in all cases. In the IETF the way to 
allow that judgment call to happen is to add "or IESG Approval" to the 
IANA rule.

Why now? Because we have a document (pana-preauth) on IESG review, and 
it cannot be approved since it would need one of the flag bits that is 
Standards Action only per the existing PANA rules. But no one in the 
working or the IESG actually thinks we should block the document.

Non-wg draft: We would have brought this through the working group, but 
I happened to close the working group a while ago, thinking that we were 
done. However, the document has been brought up for review on the PANA 
mailing list.

I hope this helps shed some light on the background, or at least my 
thoughts on it.

Jari