[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.
- [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop… Stephen Farrell
- Re: [DNSOP] Stephen Farrell's Yes on draft-ietf-d… Paul Ebersman