Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08

Mark Nottingham <mnot@mnot.net> Mon, 18 February 2019 02:16 UTC

Return-Path: <mnot@mnot.net>
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 5DCB31295EC; Sun, 17 Feb 2019 18:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=czo0HOCI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xypUnxw0
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 2D25Uhd717SV; Sun, 17 Feb 2019 18:16:41 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6AA130EAB; Sun, 17 Feb 2019 18:16:41 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 6981A16C2; Sun, 17 Feb 2019 21:16:40 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 17 Feb 2019 21:16:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=l +HzuSJZ1bREpsNv4Z4evrAaQJT+IXLCYtNvyv9zOlQ=; b=czo0HOCIPL2s2Hn/a Z3yS1VRcd8owiacn5GPJ/esktR+Mo++h+Q73NDPiixF495JjtxcW/NxwuNk+2fjp /P/b4XStyEeOynEvAO423ID67XB1ewh7yUPZdLiCY1EqMfW3DQY4y31wwvlWb41G BhheL9auBYyGtUd/zEtBG7ZEWjEoqLbvIXm+LkK9Mip4eRP5jLgE9byXFhuuO6XR 5isb6pqzP8uDxAGSo2y0pSky2F0QK+rwfKXd0KHDFGySDj8xvJ1yMp078bJUBEcS JCHO038bo4WoWky/5qgPLyliTomNglNx/ZhHB25lm/mhQ2zuxuhpmdgCyMXiSZf3 Dp6DA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=l+HzuSJZ1bREpsNv4Z4evrAaQJT+IXLCYtNvyv9zO lQ=; b=xypUnxw08rrtVz0Kok2Mhits4fFGNvmUAWWMVYPeZT+GlpM8m3UClW3Og Jcgj2ik4ZCR+jzfx8hJAjqxaElj/cbwNPLj7fWnNUWFxy/rGoLC+pSnGtjVG/Jpp YfGa2/WiuxIv5aZpT9+/swJSi/pZ9y8GUG/D2FaqtKU/FXkBtb9yjUhFKUYswVK5 OCN3fCrz9uSHUaXVQxK7v6aMpc2NJL3+NF2QTNHQS1/sRODfLdGtLV+hhc+mLL4p 3I/8Dc5EZXzUcSo3JLnEs3I84Mybt0lGVhNvZwIhlu+wijkrc/McSnMlUnNhW4ji ierjlmGfoOqRG0c+fLYT/HxYGSLfw==
X-ME-Sender: <xms:hhVqXHvuqwFmVtLh58RYVEb34APExei9vQB0Q-jkdd9vrj-T4KNvGg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrudduvddggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghm uceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpmh hnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpe dt
X-ME-Proxy: <xmx:hxVqXEbLH_texIawiN_Ror1Xcm3QaqQJebm3Y0EsYIeFCw0OD6T8yw> <xmx:hxVqXA4NlFjQw81S02SfuwQT76plDO1d7pCMX2LL-0nsxMmJs8XeDw> <xmx:hxVqXMn7UQrVyAcqzW0JhnEf4MwuhFaXuM24QbzO2-MyCd-7fIICOg> <xmx:iBVqXF6W_yMcxoNFaCqNu8SARvBCWRNrfib5JhqQVPffHfxP773i6Q>
Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id B73AE10316; Sun, 17 Feb 2019 21:16:36 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CALaySJK7y+v2XSFg5xh0=uk03J-wjPsWpTMRFMTYZcxY59+5Fw@mail.gmail.com>
Date: Mon, 18 Feb 2019 13:16:31 +1100
Cc: IETF <ietf@ietf.org>, IETF SecDir <secdir@ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, draft-nottingham-rfc5785bis.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE45E283-0DC6-45BD-B4B5-3AA17A057896@mnot.net>
References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <B1723A6E-2CA3-40D4-8C61-2BF41C3C3FB2@mnot.net> <CAHbuEH5ucn6E9iyOi9TaJRNxE+n7V7=qYT3LTtYqvXrq4BvSfQ@mail.gmail.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> <CALaySJK7y+v2XSFg5xh0=uk03J-wjPsWpTMRFMTYZcxY59+5Fw@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/2OmJXAbgb9uaJmygnZZMq9dXID4>
Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 18 Feb 2019 02:16:45 -0000


> On 16 Feb 2019, at 1:59 am, Barry Leiba <barryleiba@computer.org> wrote:
> 
> 
> > What would be helpful here would be some text in the document that asks IANA to add the instructions to the registry.  I'm hoping that more clearly states my question/request.  
> 
> Based on previous interactions with them, my understanding is that they do *not* want this level of specificity in the defining documents. Also, your text priorities the mailing list as the submission mechanism, when the preferred mechanism is likely to be an issue queue (as we've done for 8288).
> 
> What I think Kathleen is asking isn’t to have the document specify the registration details, but to make sure the registry header does.  The document says to use the instructions in the registry, but there are no instructions in the registry.  Either the document has to bootstrap that by giving an initial set of instruction to put there, or the registry has to have registration instructions that we can sanity-check now.  It doesn’t.
> 
> If the document says to see the registry for registration instructions, there had better be instructions there, no?

Yes, but if we put the instructions in the RFC, people are likely to follow them -- even when they have been changed down the line. Also, it creates confusion as to whether it's necessary to update the RFC if they change.

The text we're discussing is sourced from RC8288:
  https://tools.ietf.org/html/rfc8288#section-4.2
... which didn't have any such discussion around it. If we're going to continue this, I'd like to hear from IANA itself about what level of instruction it'd like. As I've said, the last time around (8288), I got feedback from them that such a level of detail in the RFC was counterproductive, and that we could trust folks -- and our process -- to do the right thing.

Regards,


--
Mark Nottingham   https://www.mnot.net/