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

Paul Hoffman <> Tue, 14 August 2018 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FF0F130DD6; Tue, 14 Aug 2018 08:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dwYRbP7fSYuC; Tue, 14 Aug 2018 08:31:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CB14130DD1; Tue, 14 Aug 2018 08:31:09 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 14 Aug 2018 08:31:07 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1367.000; Tue, 14 Aug 2018 08:31:07 -0700
From: Paul Hoffman <>
To: Allison Mankin <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Ext] Tsvart last call review of draft-ietf-dnsop-terminology-bis-12
Thread-Index: AQHUM32BdIM7j9ezRE2h9QFQug/qZKS/1gAA
Date: Tue, 14 Aug 2018 15:31:07 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Tsvart last call review of draft-ietf-dnsop-terminology-bis-12
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Aug 2018 15:31:11 -0000

Thanks for the review!

On Aug 13, 2018, at 8:18 PM, Allison Mankin <> wrote:
> 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.

Will do.

> 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.  

Yep, that will complicate things for future versions of this document, or any document talking about the DNS.

> 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.
>   "For example, the W3C defines "domain" at <h>."
> 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"

We'll sidestep this ongoing political tussle by saying that WHATWG defines the example there.

> 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."

No need for us to define yet a new term here; "superordinate" seems good.

--Paul Hoffman