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: a...@tr-sys.de |
+------------------------+--------------------------------------------+
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
