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

Donald Eastlake <> Tue, 11 November 2014 04:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 64C5E1A8848; Mon, 10 Nov 2014 20:56:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jg0wDHfGfzuj; Mon, 10 Nov 2014 20:56:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 693841AD54C; Mon, 10 Nov 2014 20:56:27 -0800 (PST)
Received: by with SMTP id uy5so6862745obc.40 for <multiple recipients>; Mon, 10 Nov 2014 20:56:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XTbALmrz43P/kkg64N/3SoUFoBbBWMA1wWBa/Y+89Qs=; b=J/U6hAlfotLJqmmBApGMifFgmFwlJ7ghZ12JL7S7HljZ7JiPTuH0aS8iUxSvofWrlz S89X6vEySQzUjxjDbk6vVfca4PFWH6HV5noIe8OeTzcGYy0DZ/mRPQKrN5L7YcScKLZL ufcs6uH+7ytIT6+WblvDdWt+fY5447jFvQMO5J1OOjereeJ/2AhIUPwe60x8XslMsbW9 Jwrkg3gvaGXFP9oMAWlcCMmJO8WMt70M+NKl/H4Y6hCxKrNLYu4X7VhVevBuVCe9C1jn 96kceI1QBchJZkUjI3JFGV9lB0KZs2xBVfxxmz2J8wqlivsiuVRmlLfoIvaY+Hu0rZOM SVtQ==
X-Received: by with SMTP id d8mr30893898obo.2.1415681786533; Mon, 10 Nov 2014 20:56:26 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 10 Nov 2014 20:56:06 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Donald Eastlake <>
Date: Mon, 10 Nov 2014 23:56:06 -0500
Message-ID: <>
To: Barry Leiba <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Nov 2014 04:56:28 -0000

Hi Barry,

On Mon, Nov 10, 2014 at 11:28 PM, Barry Leiba <> wrote:
>> 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.
> I can live with that.  Shall I make the changes, with that modification?

OK. with that I'm satisfied.

>>      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.
> And that's why this version of BCP 26 is much stronger than the RFC
> 5226 version with respect to guidance for the designated expert.  And
> I know that several of us on the IESG now are pushing that, strongly
> asking for DE guidance (often to the puzzlement of the document
> authors, who aren't sure what we're looking for).  I think the reason
> guidance is often lacking is exactly because it's obvious to the
> people writing the document what the DE should be considering, and the
> problems happen much later.

I'm not so sure it's obvious. While there might be people they would
trust, it is really a significant amount of work to try to come up
with reasonably complete guidance - there is really no limit to the
contingencies that could be covered.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> All that said, the current IESG is not the future IESG, and there may
> come a time when we again have an IESG that doesn't push on this point
> at all.  Which is why it's good to have the strong push for DE
> guidance baked into BCP 26.
> Barry