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...
https://www.ietf.org/mailman/listinfo/dnsop