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 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.
>> [...]
>
> 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.
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 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.
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 ...
>> [...]
>>
>> (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 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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
