Thanks for the review! On Aug 13, 2018, at 8:18 PM, Allison Mankin <allison.mankin@xxxxxxxxx> 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
