[DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

"Terry Manderson" <terry.manderson@icann.org> Wed, 06 July 2016 04:25 UTC

Return-Path: <terry.manderson@icann.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31D12D596; Tue, 5 Jul 2016 21:25:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Terry Manderson <terry.manderson@icann.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160706042557.22326.91200.idtracker@ietfa.amsl.com>
Date: Tue, 05 Jul 2016 21:25:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Vj0LdSZUVVZjPdpdCCUaEYoXIt4>
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org, dnsop-chairs@ietf.org
Subject: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 06 Jul 2016 04:25:57 -0000

Terry Manderson has entered the following ballot position for
draft-ietf-dnsop-dnssec-roadblock-avoidance-04: Discuss

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-dnssec-roadblock-avoidance/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be  a very easy DISCUSS to resolve.

In section 4, the second "Note", I urge you to reconsider using the term
"crap-ware", and words "stupid", "crap".. these make this document look
and sound very poor for an IETF published document. Knowing the
intelligence of the authors I can't see how this was thought of as
passable and made it through WGLC irrespective of how we collectively
view these devices.

Perhaps such words like "protocol naive" are better placed.


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

small nits and comments:

Abstract: s/outline potential/outlines potential/

s1.1 
  second bullet, perhaps you could just say "not DNSSEC aware" to be
parsimonious with words
  third bullet '"middle-boxes" actively'?
  fourth bullet "Network components" ?

  para after the bullets: "s/perform these test/perform these tests/ and
I don't mean this to sound snide, but what is a regular Validating
Resolver? as opposed to something else? (irregular?)
  last para of s1.1. "not uncommon to get results that are not
consistent" suggest "not uncommon to get results that are inconsistent"

s1.2 is https://github.com/ogud/DNSSEC_ALG_Check going to be a fully
stable URL?

s1.3 May I suggest moving the 'Notation' section above the background to
better arm the reader?
     By saying "actual validating resolver" I presume you mean a
standalone daemon listening on port 53?

s2 "This document specifies two sets of tests to perform a comprehensive
   one and a fast one." I think you missed a comma.  And is normative
language really needed in the following sentence?

s3, you might like to use a RFC4786 reference for anycast in the first
'Note'

s3.1 second para "SHOULD have the recursive flag", suggest "SHOULD have
the Recursion Desired (RD) flag set"

s3.1.1, please use the example domain for such examples, ie example.com,
and once you have used it do you really need to repeat it for each
'existing' text until you get to the non-existent tests and so on up to
3.1.14. 

And on s3.1.14 Will "alltypes.res.dnssecready.org"  be a stable query
point?

s 3.3 Some formatting might help with the DNS query examples here.