[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Thu, 09 July 2015 12:16 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 238A21AD2EE; Thu, 9 Jul 2015 05:16:42 -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
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 DqBaJgpFvkW3; Thu, 9 Jul 2015 05:16:40 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CF31A89C7; Thu, 9 Jul 2015 05:16:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150709121640.32189.20892.idtracker@ietfa.amsl.com>
Date: Thu, 09 Jul 2015 05:16:40 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/nX4M6623m_aDjF7Daz_xfaBiGy8>
Cc: tjw.ietf@gmail.com, draft-ietf-dnsop-negative-trust-anchors.ad@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-negative-trust-anchors@ietf.org, draft-ietf-dnsop-negative-trust-anchors.shepherd@ietf.org
Subject: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 09 Jul 2015 12:16:42 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-negative-trust-anchors-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


In an ideal world, my YES ballot for would really be "YES,
sadly I suppose we need this kind of thing but wouldn't life be
much better if DNSSEC was much easier to deploy, ah well, too
late now I guess:-(" 

- section 1.1: Where is the definition? I see you telling me
what an NTA isn't, but not what it is. I think what you want to
say is that an NTA is a domain name or a pair (a domain name
and a sub-domain of that) represented in a resolver
implementation-specific manner so that DNSSEC validation is
turned off from the higher domain name down (to the subdomain
if we have a pair). Is that right?

- 1.1: RFC5914 is a little misleading as a reference as that
was done for X.509 stuff and is nothing to do with DNSSEC.
Maybe it'd be worth pointing that out just in case some reader
somewhere goes and gets confused.

- section 2: what do you mean happens "once per quarter"?

- section 2: "immediately restores" - well that depends on the
screw-up doesn't it? Or are you saying (where?) that an NTA
must only be put in place when the screw-up is specifically and
only about and because of DNSSEC and where ignoring DNSSEC will
result in things "working"? For example, DNSSEC could fail
because all my nameservers are entirely offline due to a f/w
mis-configuration that blocks loads of port 53, but putting in
place an NTA won't help then. (As it happens, I'm right now
gettting a f/w to re-unblock 53 so I can serve some DNSSEC
records so this issue is one that's close to the bone for me:-)

- Section 6: 1st 2 sentences repeat repeat dnssec-failed.org
too too many times.

- random question: why not have an "I'm just testing" RR that I
could put in alongside my ZSK DNSKEY as I start to play with
DNSSEC? Or maybe that exists already.