Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12

"Paul Hoffman" <paul.hoffman@vpnc.org> Tue, 10 July 2018 16:35 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49590131185 for <dnsop@ietfa.amsl.com>; Tue, 10 Jul 2018 09:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 aYyGTOox9869 for <dnsop@ietfa.amsl.com>; Tue, 10 Jul 2018 09:35:02 -0700 (PDT)
Received: from mail.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 335B9131156 for <dnsop@ietf.org>; Tue, 10 Jul 2018 09:35:02 -0700 (PDT)
Received: from [10.47.60.44] ([65.119.211.164]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w6AGYpXN054361 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dnsop@ietf.org>; Tue, 10 Jul 2018 09:34:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host [65.119.211.164] claimed to be [10.47.60.44]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: dnsop@ietf.org
Date: Tue, 10 Jul 2018 12:34:59 -0400
X-Mailer: MailMate (1.11.2r5507)
Message-ID: <CA9772AF-6055-48F5-BFEC-8FF549A0C50A@vpnc.org>
In-Reply-To: <6121b7c4-247b-7fca-ac03-c6c2196d12dd@nthpermutation.com>
References: <153092238624.5315.17258755138091784954.idtracker@ietfa.amsl.com> <f233b9ed-a356-5124-e052-ce4833e25e43@nthpermutation.com> <468b0483-4e16-3042-a8e2-c6348126842b@nthpermutation.com> <CADyWQ+HKq1NoqMFDmGOuHK-9hDK=r28aUOsM=T=Lb=OvUCpVUA@mail.gmail.com> <6121b7c4-247b-7fca-ac03-c6c2196d12dd@nthpermutation.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oRWV0W3XXg-D4iQoD2eSu9sP2eA>
Subject: Re: [DNSOP] Working Group Last Call for for draft-ietf-dnsop-rfc5011-security-considerations-12; was Publication has been requested for draft-ietf-dnsop-rfc5011-security-considerations-12
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 10 Jul 2018 16:35:13 -0000

On 10 Jul 2018, at 11:35, Michael StJohns wrote:

> And as you may have guessed I object to the publication of this 
> document on the basis of quality for all the reasons previously 
> stated.  This version of the document is actually in worse shape than 
> the one that failed last call back in October.

Documents go to WG Last Call to determine consensus and fix errors; this 
document appears to have done both, so there was no failure.

> I strongly object to the publication of this document as a Standards 
> Track document. The appropriate status  - if published - is 
> Informational with or without a BCP tag on it. 

There is no such thing as a "BCP tag". An RFC that is a BCP is treated 
as a standard. See Section 5 of RFC 2026.

> The document does not provide any implementable protocol, and by that 
> I mean that the only protocol elements in this document must be 
> executed by humans.  There is no on-the-wire elements, nor any 
> process that can be implemented by a DNS resolver or server.  This is 
> solely and only an operational practices document,

True.

> and AFAICT, none of these have ever ended up as Standards Track.

Not true. Plenty of WGs, including this one, put operational documents 
on standards track.

>    Or to put it more bluntly - humans are not protocol elements that 
> can be standardized. 

True, but not relevant to the issue at hand.

> Finally, this purports to update RFC7538 which is Informational.

That's a good point. The WG draft that led to RFC 7538 was marked as 
Informational for its entire lifetime, so the WG must have thought it 
was OK to treat key rollover timing considerations as Informational.

--Paul Hoffman