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. > --- vvvvv > | 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, [...] > --- vvvvv > | 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 > vvvvvvv ^^ > | 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 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. ok. > (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. > --- vvvvvvvvvvvvv v > | [...] See Section 2 of [RFC1996] for more information about > stealth servers. ok. > (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 AAAA RRs, > | are more likely to speak EDNS which can use a larger UDP response > size limit, and partly because the resource records (A and AAAA) 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 AAAA RRs, > | are more likely to speak EDNS, which can use a larger UDP response > ^ > size limit, and partly because the resource records (A and AAAA) are > in different RRsets and are therefore divisible from each other. ok. though the construct "xxx, which yyy, which zzz" is itself rather awkward. > (4.3) 6th (last) paragraph > > Again, s/which/that/ : > > | Name server names which are at or below the zone they serve are more > sensitive to referral response truncation, and glue records for them > should be considered "more important" than other glue records, in the > assembly of referral responses. > --- vvvv > | Name server names that are at or below the zone they serve are more > sensitive to referral response truncation, and glue records for them > should be considered "more important" than other glue records, in the > assembly of referral responses. ok. > (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 od 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. -- "But I'm not done complaining." --Dagon, 2012 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
