Subject: [DNSOP] an editorial review of draft-ietf-dnsop-respsize-13

From: Alfred Hönes <[email-masked]>
Date: Wed, 25 Apr 2012 18:58:28 +0200 (MESZ)

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.
---                                 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.

(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, [...]

(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.

(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.
---               vvvvvvvvvvvvv         v
|      [...]  See Section 2 of [RFC1996] for more information about
   stealth servers.

(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.

(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.

(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].

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: paul vixie <[email-masked]>
Date: Wed, 25 Apr 2012 17:13:34 +0000

> the opportunity of the notes below to refresh the draft.

thanks.

see below.

> a) The object of the first sentence lacks an article; "the" should be

ok.

>    "(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.

>    in recent few years.  The long tail of EDNS deployment may eventually

that's all fine.

> |  While the DNS distinguishes between necessary and optional resource

"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.

>    intermediate server rather than the query from the original client.

ok.

>    EDNS, then new measurements and new estimates will have to be made.

ok.

> |      [...]  See Section 2 of [RFC1996] for more information about

ok.

>    in different RRsets and are therefore divisible from each other.

ok. though the construct "xxx, which yyy, which zzz" is itself rather
awkward.

>    assembly of referral responses.

ok.

> 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

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 25 Apr 2012 20:07:51 +0200 (MESZ)

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.

>> [...]

I have observed various instances of the RFC Editor changing
"RFC xxxx, Section yy" to "Section yy of RFC xxxx", 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.

>> [...]

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.

>> [...]
>> [...]

o.k. -- how about this to make it less awkward:
                                                      ... multiprotocol
   clients, which are required to handle larger RRsets such as AAAA RRs,
|  are more likely to speak EDNS in order to be able to use larger UDP
|  response sizes, and partly because ...

>> [...]
>> - the first ref. to [RFC2671], in the 2nd para of Section 1 should be

Well, rfc2671bis is in the IESG and it seems likely that the IESG
Comments and the single Discuss could be addressed and resolved
in a single additional draft iteration, but the subject draft has
not even be forwarded to the IESG with a publication request ...
So I guess it's *very* unlikely that the respsize draft catches up
so quickly that it surpasses the rfc2671 draft -- and even that could
be addressed via clustering in the Queue (leading to coordinated
publication).

So, upon revising the draft now, you could still add a reference
to the rfc2671bis I-D, which later indeed would be fixed up by the
RFC Editor to point to the published RFC 2671bis.  At least, this
should reduce the chances that the argument in the draft gets
messed up later by a mechanical switch of the (single) ref. to
RFC 2671 to its successor.

Kind regards,
  Alfred.