Re: [DNSOP] [Ext] Tsvart last call review of draft-ietf-dnsop-terminology-bis-12
Paul Hoffman <paul.hoffman@icann.org> Tue, 14 August 2018 15:31 UTC
Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF0F130DD6; Tue, 14 Aug 2018 08:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwYRbP7fSYuC; Tue, 14 Aug 2018 08:31:09 -0700 (PDT)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB14130DD1; Tue, 14 Aug 2018 08:31:09 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 14 Aug 2018 08:31:07 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Tue, 14 Aug 2018 08:31:07 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Allison Mankin <allison.mankin@gmail.com>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "draft-ietf-dnsop-terminology-bis.all@ietf.org" <draft-ietf-dnsop-terminology-bis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
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: <9D525D8F-5D93-4266-B4BA-9541DCA3389C@icann.org>
References: <153421671987.25132.9247055790367030044@ietfa.amsl.com>
In-Reply-To: <153421671987.25132.9247055790367030044@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5D47BA3F4B3792409CBC95277CA57635@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2i5CHjbjcCEFj37siKPeHJxtapI>
Subject: Re: [DNSOP] [Ext] Tsvart last call review of draft-ietf-dnsop-terminology-bis-12
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
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 15:31:11 -0000
Thanks for the review! On Aug 13, 2018, at 8:18 PM, Allison Mankin <allison.mankin@gmail.com> 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. Agree. > 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 <hhttps://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" 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," Fixed. > > 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." Fixed. > > 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. Agree. > 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
- [DNSOP] Tsvart last call review of draft-ietf-dns… Allison Mankin
- Re: [DNSOP] [Ext] Tsvart last call review of draf… Paul Hoffman