[Gen-art] Gen-art LC review: draft-ietf-dnsop-maintain-ds-03

Robert Sparks <rjsparks@nostrum.com> Fri, 08 July 2016 20:33 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 07D3412D872; Fri, 8 Jul 2016 13:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id t5HyrwgSMa-1; Fri, 8 Jul 2016 13:33:01 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B47512D894; Fri, 8 Jul 2016 13:32:52 -0700 (PDT)
Received: from unnumerable.local ([]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u68KWnHt069615 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 8 Jul 2016 15:32:51 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [] claimed to be unnumerable.local
To: General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, dnsop@ietf.org, draft-ietf-dnsop-maintain-ds.all@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <0371ee99-778c-5ded-0c31-3c6d8d6b55c7@nostrum.com>
Date: Fri, 08 Jul 2016 15:32:49 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/aB3FHnsjjCwXR3QyXioZt-PBkoY>
Subject: [Gen-art] Gen-art LC review: draft-ietf-dnsop-maintain-ds-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2016 20:33:04 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-dnsop-maintain-ds-03
Reviewer: Robert Sparks
Review Date: 8 Jul 2016
IETF LC End Date: 11 Jul 2016
IESG Telechat date: Not yet scheduled for a telechat

Summary: Ready, but with nits and perhaps a process problem

Potential process problem:

This document intends to move RFC7344 from Informational to PS in place
(without republishing RFC7344. The intent to do so is buried at the end
of the document (the abstract doesn't mention it). The Last Call for the
document does not make it clear that _this_ document is elevating RFC7344.
(It at least mentions it, which is good, but the writeup about the elevation
can be read to say "we're considering this elevation somewhere else, keep it
in mind while evaluating this document").

There is no hint from the subject line that this is a call to bring RFC7344
onto the standards track. Unless there is some other communication effort
that I've missed on a quick search, I think it is very likely that most
of the IETF community outside the dnsop working group missed this intent.
I strongly encourge a last call focusing _specifically_ on moving RFC7344
to the standards track without republication.

My personal feedback on elevating RFC7344 without republishing is that it's
not the right thing to do. At the very least "Category: Informational"
appears in the document itself, and that will not change. If the IESG
decides to proceed with this as currently formulated, count me in the
deep rough.


In 1.2, "that decision SHOULD be fully under the child domain's control"...
Why is that a 2119 SHOULD? I think this is commentary on that it would be
a bad idea for someone else to unilaterally decide to turn of DNSSEC for
a child domain? Why not just say that (it would be even better to expand
on _why_ it's a bad idea. If you really think this is the right way to say
what you mean, and you keep 2119, please talk about when it would be ok to
not follow that SHOULD.

In 1.3, consider pointing to Appendix A of RFC7344 to better define RRR.

In the Security Considerations, you have "Users SHOULD" and "all options
SHOULD be considered". These are not meaningul uses of 2119 - please use
prose to say what you really mean. If you want to keep them, please talk
about when it would be ok to not follow the SHOULD. I think you're trying
to say "Completing the rollover via an unsigned state is dangerous and 
only be used as a last resort" or something similarly strong.

Consider pointing back to the 5 scenarios you spell out in section 1.2 
in the
security considerations section. The asserted existance of operational and
aoftware limitations that necessitate turning off DNSSEC to facilitate a 
of operator is certainly a major security consideration.

Consider doing more to the DNS Security Algorithms Number registry than
the current instructions indicate. Simply adding a reference to this 
to the row for number 0 does not convey that this "reserved" number is 
being _used_ in a protocol, and that when it is it's an algorithm number 
is not a number for an algorithm. I don't know how to say that cleanly, but
the registry should say more than simply "reserved" if this document is 

Typo-nit: s/digiest/digest/