[DNSOP] an editorial review of draft-ietf-dnsop-respsize-13
It has been pointed out that the DNS Referral Response Size Issues I-D should not be left going to final expiry, and I have performed a new review of the last version, draft-ietf-dnsop-respsize-13. I only found a small number of remaining editorial nits -- either formerly overlooked or newly introduced. You might want to take the opportunity of the notes below to refresh the draft. (1) Section 1 (1.1) 1st paragraph a) The object of the first sentence lacks an article; the should be supplied. b) In a few places, the draft uses very terse forms of precise citations, which better should be expanded a bit for readability; the first occurrence of this is here as well: (see [RFC1035] 4.2.1)should say (see [RFC1035], Section 4.2.1) or even better (see Section 4.2.1 of [RFC1035]) . Chosing the latter form, the corrections will accumulate to: | The original DNS standard limited UDP message size to 512 octets (see | [RFC1035] 4.2.1). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. --- v | The original DNS standard limited the UDP message size to 512 octets | (see Section 4.2.1 of [RFC1035]). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. (1.2) 2nd paragraph Again, please expand the reference (see [RFC2671] 2.3, 4.5) in the same way as above. (1.3) 4th paragraph Again, a definite article is missing, and also whitespace is missing in front of a citation -- both in the first sentence. Please adjust: | While more than twelve years passed since the publication of EDNS0 vv ^ | document[RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. --- | While more than twelve years passed since the publication of the vvv | EDNS0 document [RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. (2) Section 2.3 (2.1) 2nd paragraph When used as a noun, DNS should be written with the definite article: | While DNS distinguishes between necessary and optional resource records, [...] --- v | While the DNS distinguishes between necessary and optional resource records, [...] (2.2) last paragraph There are two grammar flaws in the text. a) s/independent to/independent of/ b) I assume that ... the DNS server _might_ just see ... is the needed verb that you had in mind. So please correct: | The glue record order should be independent to the version of IP used v^^ | in the query because the DNS server just see a query from an intermediate server rather than the query from the original client. --- | The glue record order should be independent of the version of IP used vvv ^^ | in the query because the DNS server might just see a query from an intermediate server rather than the query from the original client. (3) Section 3, last paragraph According to the RFC Editor explanations of the most frequent flaws in grammar and style (see RFC Editor educational presentation material from all recent IETF meetings), which is inappropriate in Technical English and should be replaced by that here: We're assuming a medium query name size of 64 since that is the typical size seen in trace data at the time of this writing. If | Internationalized Domain Name (IDN) or any other technology which ^^ results in larger query names be deployed significantly in advance of EDNS, then new measurements and new estimates will have to be made. --- We're assuming a medium query name size of 64 since that is the typical size seen in trace data at the time of this writing. If | Internationalized Domain Name (IDN) or any other technology that results in larger query names be deployed significantly in advance of EDNS, then new measurements and new estimates will have to be made. (4) Section 4 (4.1) 2nd paragraph, last sentence Similar to the above case in Section 1, the text here contains a too terse detailed citation that should be expanded: | [...] See [RFC1996] 2 for more information about stealth servers. ---
Re: [DNSOP] an editorial review of draft-ietf-dnsop-respsize-13
On 4/25/2012 4:58 PM, Alfred � wrote: It has been pointed out that the DNS Referral Response Size Issues I-D should not be left going to final expiry, and I have performed a new review of the last version, draft-ietf-dnsop-respsize-13. I only found a small number of remaining editorial nits -- either formerly overlooked or newly introduced. You might want to take the opportunity of the notes below to refresh the draft. thanks. see below. (1) Section 1 (1.1) 1st paragraph a) The object of the first sentence lacks an article; the should be supplied. ok. b) In a few places, the draft uses very terse forms of precise citations, which better should be expanded a bit for readability; the first occurrence of this is here as well: (see [RFC1035] 4.2.1)should say (see [RFC1035], Section 4.2.1) or even better (see Section 4.2.1 of [RFC1035]) . i don't agree. we'll make the change, since we're not going to stand on minutiae, but for the record this is your personal style preference not an objective style guide reference. i would actually prefer [RFC1035 4.2.1] since terseness is to me virtuous. again: you're over reaching here, but, we'll make the change for you anyway. Chosing the latter form, the corrections will accumulate to: | The original DNS standard limited UDP message size to 512 octets (see | [RFC1035] 4.2.1). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. --- v | The original DNS standard limited the UDP message size to 512 octets | (see Section 4.2.1 of [RFC1035]). Even though this limitation was due to the required minimum IP reassembly limit for IPv4, it became a hard DNS protocol limit and is not implicitly relaxed by changes in a network layer protocol, for example to IPv6. (1.2) 2nd paragraph Again, please expand the reference (see [RFC2671] 2.3, 4.5) in the same way as above. (1.3) 4th paragraph Again, a definite article is missing, and also whitespace is missing in front of a citation -- both in the first sentence. Please adjust: | While more than twelve years passed since the publication of EDNS0 vv ^ | document[RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. --- | While more than twelve years passed since the publication of the vvv | EDNS0 document [RFC2671], approximately 65% of the clients support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. that's all fine. this, though: (2) Section 2.3 (2.1) 2nd paragraph When used as a noun, DNS should be written with the definite article: | While DNS distinguishes between necessary and optional resource records, [...] --- v | While the DNS distinguishes between necessary and optional resource records, [...] The Domain Name System as abbreviated to the acronym DNS is a proper noun. we do not write The IP even though we would write The Internet Protocol. similarly for TCP, UDP, NFS, and so on. (2.2) last paragraph There are two grammar flaws in the text. a) s/independent to/independent of/ b) I assume that ... the DNS server _might_ just see ... is the needed verb that you had in mind. So please correct: | The glue record order should be independent to the version of IP used v^^ | in the query because the DNS server just see a query from an intermediate server rather than the query from the original client. --- | The glue record order should be independent of the version of IP used vvv ^^ | in the query because the DNS server might just see a query from an intermediate server rather than the query from the original client. ok. (3) Section 3, last paragraph According to the RFC Editor explanations of the most frequent flaws in grammar and style (see RFC Editor educational presentation material from all recent IETF meetings), which is inappropriate in Technical English and should be replaced by that here: We're assuming a medium query name size of 64 since that is the typical size seen in trace data at the time of this writing. If | Internationalized Domain Name (IDN) or any other technology which ^^ results in larger query names be deployed significantly in advance
Re: [DNSOP] an editorial review of draft-ietf-dnsop-respsize-13
Paul, thanks for your expedite response to my review comments. Please see a few inline follow-up remarks below. I have deleted all parts that don't need further elaboration. (1) Section 1 (1.1) 1st paragraph [...] b) In a few places, the draft uses very terse forms of precise citations, which better should be expanded a bit for readability; the first occurrence of this is here as well: (see [RFC1035] 4.2.1)should say (see [RFC1035], Section 4.2.1) or even better (see Section 4.2.1 of [RFC1035]) . i don't agree. we'll make the change, since we're not going to stand on minutiae, but for the record this is your personal style preference not an objective style guide reference. i would actually prefer [RFC1035 4.2.1] since terseness is to me virtuous. again: you're over reaching here, but, we'll make the change for you anyway. I have observed various instances of the RFC Editor changing RFC , Section yy to Section yy of RFC , and accommodating the preferred style helps to minimize changes of a document at the RFC Editor and thereby to speed up RFC Editor processing of a draft (and less changes for the authors to review in AUTH48), so if an opportunity exists, I try to accommodate RFC Editor preferences in advance and suggest doing so to others. [...] this, though: (2) Section 2.3 (2.1) 2nd paragraph When used as a noun, DNS should be written with the definite article: | While DNS distinguishes between necessary and optional resource records, [...] --- v | While the DNS distinguishes between necessary and optional resource records, [...] The Domain Name System as abbreviated to the acronym DNS is a proper noun. we do not write The IP even though we would write The Internet Protocol. similarly for TCP, UDP, NFS, and so on. I indeed found and observed that a few *P acronyms have attained that kind of personality during long usage (e.g. IP, TCP), but that System (as the trailing 'S' in the acronyms under consideration) has not found similar assimilation -- the nouns DNS, NFS, AFS, UMTS, etc. are (still?) usually spelled out in spoken language, at least by people with not so much focus on a specific technology. Further, perhaps non-native speakers of English generally prefer to spell out acronyms -- in particular those in a foreign language -- much more frequently than you may be used to do. But, agreed, opinions may vary. [...] (4) Section 4 [...] (4.2) 5th paragraph Here, a comma is missing in front of the (correct) bare which: More than one address record across protocol families is less likely to lead to or encounter truncation, partly because multiprotocol clients, which are required to handle larger RRsets such as RRs, | are more likely to speak EDNS which can use a larger UDP response size limit, and partly because the resource records (A and ) are in different RRsets and are therefore divisible from each other. --- More than one address record across protocol families is less likely to lead to or encounter truncation, partly because multiprotocol clients, which are required to handle larger RRsets such as RRs, | are more likely to speak EDNS, which can use a larger UDP response ^ size limit, and partly because the resource records (A and ) are in different RRsets and are therefore divisible from each other. ok. though the construct xxx, which yyy, which zzz is itself rather awkward. o.k. -- how about this to make it less awkward: ... multiprotocol clients, which are required to handle larger RRsets such as RRs, | are more likely to speak EDNS in order to be able to use larger UDP | response sizes, and partly because ... [...] (5) Final remark: Depending on the timeline of progress of the drafts, you might want to prepare for a _selective_ reference update from RFC 2671 to RFC 2671bis; this needs some care: - the first ref. to [RFC2671], in the 2nd para of Section 1 should be updated to RFC 2671bis, but - the second ref. to [RFC2671], in the 4th para of Section 1 (see above) should better be left bound to the original document and then changed to clarify the context: | While more than twelve years passed since the publication of the | original EDNS0 document [RFC2671], approximately 65% of the clients ^ support it as observed at a root name server and this fraction has not changed in recent few years. The long tail of EDNS deployment may eventually be measured in decades. Hence, [RFC2671bis] needs to be added to the Informative References without deleting the ref. [RFC2671]. we depend upon the rfc editor to make such last minute changes since they depend on the order of publication of rfc's. Well, rfc2671bis is in the IESG and it seems likely that the IESG Comments and the
