Re: [DNSOP] Expiration impending: <draft-jabley-dnssec-trust-anchor-11.txt>

"Paul Hoffman" <paul.hoffman@vpnc.org> Mon, 05 October 2015 13:08 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889851A1A86 for <dnsop@ietfa.amsl.com>; Mon, 5 Oct 2015 06:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 Wh072lzRM_an for <dnsop@ietfa.amsl.com>; Mon, 5 Oct 2015 06:08:37 -0700 (PDT)
Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE32C1A1A62 for <dnsop@ietf.org>; Mon, 5 Oct 2015 06:08:37 -0700 (PDT)
Received: from [10.47.60.19] ([216.46.0.94]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t95D8ZT9023258 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2015 06:08:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host [216.46.0.94] claimed to be [10.47.60.19]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Jakob Schlyter <jakob@kirei.se>
Date: Mon, 05 Oct 2015 09:08:38 -0400
Message-ID: <D1C15986-603E-4932-B551-0497638D9849@vpnc.org>
In-Reply-To: <C4FA9FA6-76E3-4FF3-862B-C5C0DF75C761@kirei.se>
References: <20150928114202.823.19868.idtracker@ietfa.amsl.com> <0E4AA958-7740-4602-A3CF-D2E481DBC15E@hopcount.ca> <20150928155325.GA63874@gaon.net> <20150929095301.32c3e6a3@casual> <13F1D87F-1C07-40EB-86B0-564C4109C9B0@virtualized.org> <1973252D-924F-4EF1-A38F-5EC01AD331F6@gmail.com> <FDD04DCC-59C5-41F5-8CAF-1EF31CD65A34@virtualized.org> <63E1E01E-C172-4A0F-B434-F796546BB657@gmail.com> <C4FA9FA6-76E3-4FF3-862B-C5C0DF75C761@kirei.se>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/uiWyUan-qHDIAM7zEOGPk_Ja7Lo>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] Expiration impending: <draft-jabley-dnssec-trust-anchor-11.txt>
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2015 13:08:38 -0000

On 5 Oct 2015, at 8:50, Jakob Schlyter wrote:

> On 4 okt. 2015, at 20:27, Suzanne Woolf <suzworldwide@gmail.com> 
> wrote:
>
>> On Oct 4, 2015, at 2:00 PM, David Conrad <drc@virtualized.org> wrote:
>>
>>> I've since been told that the draft doesn't actually document 
>>> current practice (don't know the details), so this probably needs to 
>>> be fixed.
>>
>> What "needs to be fixed"? That the draft doesn't document current 
>> practice? Given that's the stated goal, I'd appreciate clarification 
>> from the authors on what they think needs to be done before it meets 
>> that goal, and whether they're willing to work on it.
>
> As far as I'm aware, the document does document current practice.

It does not. It describes a mixture of some of the current practice and 
some aspirational hopes for how things might be done. Further, it is 
incomplete in many aspects.

> At least, what it describes was true back in 2010 when I wrote the 
> code and as far as I know nothing as changed (i.e., the published 
> files has not changed).

The document goes well beyond describing the files, and this is where it 
fails. Further, the files are not the only way that the trust anchor is 
published, so the document is fairly incomplete.

>>>> Well, as a technicality, I don't see that this draft was ever 
>>>> adopted by the WG.
>>>
>>> Perhaps that might be a good next step?
>>
>> Might be. I was attempting to suggest a shorter path to publication 
>> might be possible, given the extensive record of discussion on the 
>> document over several years-- we've been known to do a combined 
>> adoption/WGLC on a document not expected to need much work in the WG.
>
> I'm not sure what adoption would give us as the document aims to 
> document current practice, and nothing - except clarifications - is up 
> for discussion.

If it is not up for discussion, then the document should not be 
progressed in the IETF at all. Instead, the description of the ICANN's 
publication methodology should be published by ICANN.

This WG should instead consider a very different document: how the IETF 
thinks that the DNSSEC trust anchors should be published in order to 
help DNS operators. Joe Abley has an expired (?) draft on this topic. A 
discussion of what ICANN and others should do for publication seems 
quite relevant to the aims of this WG.

--Paul Hoffman