[DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-no-response-issue-18: (with COMMENT)

Murray Kucherawy via Datatracker <noreply@ietf.org> Mon, 30 March 2020 18:02 UTC

Return-Path: <noreply@ietf.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 B6D103A0D94; Mon, 30 Mar 2020 11:02:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-no-response-issue@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.123.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <158559137512.6168.9284398515954229939@ietfa.amsl.com>
Date: Mon, 30 Mar 2020 11:02:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ab_5oJq1Ylg1GVnKdiDKZ5xusyo>
Subject: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-no-response-issue-18: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 30 Mar 2020 18:03:01 -0000

Murray Kucherawy has entered the following ballot position for
draft-ietf-dnsop-no-response-issue-18: No Objection

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-no-response-issue/



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

General:
Nits:
* I tripped almost every time on saying "set FOO bit to 1" and similar because
I'm used to "set" implying one and "not set" or "clear" implying zero.  In
other places the prose does go with simply saying "FOO bit is set".  Maybe
that's just me though; we'll see how my colleagues feel.

Section 1:
* Suggest including a reference to RFC4732 in the discussion of amplification
attacks.

Section 2:
* In the discussion of abandoned transition to the SPF type, suggest a
reference to RFC6686.

Nits:
* "Widespread non-response to EDNS queries has lead to  ..." -- s/lead/led/
* "Widespread non-response to EDNS options, requires ..." -- remove comma
* "... requires recursive servers to have to decide ..." -- s/to have//
* "... being present, leads to ..." -- remove comma

Section 3.1.2:
A nit:
* "The exception to this are ..." -- either s/exception/exceptions/ or
s/are/is/.

Section 3.1.5:
A nit:
* "While firewalls should not block TCP connection attempts if they do they
should ..." -- suggest: "While firewalls should not block TCP connection
attempts, those that do should ..."

Section 3.2.2:
More nits:
* "... version 0 queries but ... version numbers that are higher than zero." --
why the digit in one place but prose in the other?

Section 4:
* Paragraphs 3, 4, and 5 could be common factored very easily since most of the
text is identical.

Section 5:
* I've never heard of a "scrubbing service".  Is there a reference RFC, or
could we include a short definition? * "One needs to take care when choosing a
scrubbing service." -- This is vague.  What, apart from the prior sentence
(whose implications I don't understand), should an operator be looking for?

Section 8:
Nit:
* "Testing is divided into two sections." -- a list follows, so s/./:/

Section 9:
* The final paragraph suggests disconnection of broken nameservers.  This can
have serious non-technical implications as well.  That might be worth
mentioning.

Nit:
* "Name server operators ..." -- s/Name server/Nameserver/, to be consistent
with the rest of the document