Re: [secdir] Secdir review of draft-housley-ltans-oids-00

Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 15 July 2013 18:33 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000FE1F0D3E; Mon, 15 Jul 2013 11:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmMpFV+vSQw5; Mon, 15 Jul 2013 11:33:52 -0700 (PDT)
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 46AE721E8115; Mon, 15 Jul 2013 11:33:36 -0700 (PDT)
Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r6FIXW45020921 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 14:33:32 -0400 (EDT)
Message-ID: <1373913212.23365.299.camel@minbar.fac.cs.cmu.edu>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Tero Kivinen <kivinen@iki.fi>
Date: Mon, 15 Jul 2013 14:33:32 -0400
In-Reply-To: <23706_1373665231_r6CLeT1d025396_20960.30655.526275.938616@fireball.kivinen.iki.fi>
References: <23706_1373665231_r6CLeT1d025396_20960.30655.526275.938616@fireball.kivinen.iki.fi>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.3-0ubuntu6
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Cc: draft-housley-ltans-oids.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, jhutz@cmu.edu
Subject: Re: [secdir] Secdir review of draft-housley-ltans-oids-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 15 Jul 2013 18:33:59 -0000

On Sat, 2013-07-13 at 00:40 +0300, Tero Kivinen wrote:


> One odd thing is that all registries are marked as "Expert Review or
> IESG Approval", but which one of those is used? Is this supposed to
> mean that if IESG appoints a designed expert for these, then he does
> checks the updates, but if not, then IESG approval is needed? Or is it
> mean to say that even when there is designated expert, the IESG and
> ignore him and do the approval themselves (in which case I Would ask
> what is the point of having the designated expert)?


It means that either the "Expert Review" or "IESG Approval" methods can
be used.  Over the years, we've seen a number of cases where it turns
out to be desirable to assign a number under circumstances not foreseen
by the authors of the document that originally set up a registry, and
under which none of the policies attached to that registry can be
applied.  As defined in RFC5226, the "IESG Approval" policy is intended
to be an escape valve that allows the IESG to handle these exceptions,
rather than failing an allocation due to a policy bug when it clearly
should have been accepted.  Of course, in such a case one can always
publish an IETF consensus document to change the policy, but often that
introduces an unacceptable level of delay.

As Russ notes, when the defined policy is "Expert Review", the IESG can
likely handle exceptions by designating an expert, so perhaps the escape
valve is not necessary.  However, I don't think it's harmful.


However, I do note that this document uses the "Expert Review" policy
several times, but fails to specify the required level of documentation
or the review criteria to be used by the Designated Expert.  Without
this information, I don't think it's possible to make any meaningful
comment on the IANA registration policies.

-- Jeff