[DNSOP] Tsvart last call review of draft-ietf-dnsop-terminology-bis-12

Allison Mankin <allison.mankin@gmail.com> Tue, 14 August 2018 03:18 UTC

Return-Path: <allison.mankin@gmail.com>
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 E02E4131107; Mon, 13 Aug 2018 20:18:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Allison Mankin <allison.mankin@gmail.com>
To: tsv-art@ietf.org
Cc: dnsop@ietf.org, draft-ietf-dnsop-terminology-bis.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153421671987.25132.9247055790367030044@ietfa.amsl.com>
Date: Mon, 13 Aug 2018 20:18:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fU656f0mCyO4Er-He4iTB7TrznU>
Subject: [DNSOP] Tsvart last call review of draft-ietf-dnsop-terminology-bis-12
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 14 Aug 2018 03:18:40 -0000

Reviewer: Allison Mankin
Review result: Almost Ready

Overall Comment - there is a lot of illumination in here, but one overall point
and a few smaller ones explain why I rated the draft Almost Ready, rather than Ready.

The overall points is that it should give the reader more guidance.  It is very 
clear early on, but as the topics become more complex, there is increasing use
of terms before they are defined.  Section 2's discussion of ASCII, presentation format
and display format, is very complex, but reads much better if you first go read the
definitions of the format types (and dip into IDNA).  Sections 3 and 4 depend a lot
on the term "owner" and there wasn't enough of a cue that this was a formal term to 
To help the reader use the document better, how about including a readers note at the
end of the Introduction, pointing out that no ordering of the terms could be made to
solve this, but noting the existence of the alphabetical index, a very unusual feature
in IETF documents, I think.

Transport Review Considerations

I know it was discussed whether to include any terms related to DNS Stateful Operations. 
When this is revised again, pay attention to the very first sentence in the Intro, which
will need tweaking for session-signaling.  

In contrast, in the EDNS definition in Section 5, I recommend tweaking the following to 
remove the word "potentially" because there already are multiple Proposed Standards for
options that affect the handling of a DNS query.  
   "and potentially to carry additional options that affect the handling of a DNS query"
Would also suggest using this opportunity to clarify that EDNS is not end-to-end, because 
that is a source of confusion.

Smaller Comments

Section 1

Quoted sentence is not correct, because whatwg is not part
of W3C (cf. https://whatwg.org/faq):
   "For example, the W3C defines "domain" at <https://url.spec.whatwg.org/>."
Fix by not including the example.  If this is really where W3C goes for its
definition of domain, change the sentence to read "the W3C uses <whatwg's spec>
as the source of its definition of domain"

Section 2

Typo: missing words in definition of locally served DNS zone:
   "The context through which a locally served zone [missing words?]
    may be explicit, for example, as defined in [RFC6303], or implicit,"

Section 4

Typo: "it would have be"
   "Note that, because the definition in [RFC2308] is actually for a
    different concept than what was in [RFC1034], it would have be
    better if [RFC2308] had used a different name for that concept."

Section 6
The Abstract and Section 6 use the term "successor" incompatibly.  The Abstract uses
it as a synonym for "obsoletes":
   "This document will be the successor to RFC 7719, and thus will
    obsolete RFC 7719."
Section 6 uses it more in the sense of "updates" (unless I've missed something
and RFC1035 has been obsoleted.  
   "and sends responses using the DNS protocol defined in [RFC1035] and its
    successors."
To my taste, not using the word in the Abstract would be a good fix for this.

Section 9

Discussion of registry introduces "superior," a term not defined or used anywhere else.
Fix this by replacing it with terminology that is defined, such as "superordinate" or
adding "superior" to the section on "superordinate."
    "for some zones, the policies that determine
     what can go in the zone are decided by superior zones and not the
     registry operator."