I have reviewed draft-ietf-dnsext-rfc2671bis-edns0-08
and would like to submit a few LC comments.
Summary:
=======
The draft is almost ready for publication as a
(Full) Internet Standard RFC.
(Note: Shouldn't the Last Call template now be aligned with the
RFC 6410 maturity level designations and use "Internet Standard"
in place of "Full Standard" -- both in the headline and in the body?)
The technical content is sound and stable and supported by consensus
in the DNS community, including all major DNS implementers; it is also
well aligned with other recent documents / documents in the pipeline.
AFAICT, the document fulfills the criteria posed in Section 2.2 of
RFC 6410 for "Internet Standard".
I only found a few minor textual issues (see below) and a couple of
editorial nits (being communicated to a smaller distribution list)
that all could be easily addressed during final processing stages.
Minor textual issues:
====================
a) Section 3, last line
I suspect that "... generalized use of TCP for DNS transport."
is not what the authors had in mind, it likely should be
"... general use of TCP for DNS transport."
(or s/general/more frequent/)
b) Section 6.1.2 -- procedural clarification
I suggest to slightly amend the very last sentence of s6.1.2 :
OLD:
[...]. For example, an
option specification might say that if a responder sees option XYZ,
it MUST include option XYZ in its response.
NEW:
[...]. For example, an
option specification might say that if a responder sees and
understands option XYZ, it MUST include option XYZ in its response.
(or add "and supports" in place of "and understands")
c) Section 6.2.2 -- terminological clarification
Since EDNS is -- at least in principle -- designed to be a versioned
family of DNS protocol extensions based on the OPT RR, and such
versions are expected to be upward compatible, the second mention
of "ENDS0" in that paragraph should better say "EDNS" (without the
version '0', see below) or (less preferably) "EDNS(0)".
OLD:
If a requestor detects that the remote end does not support EDNS0, it
MAY issue queries without an OPT record. It MAY cache this knowledge
for a brief time in order to avoid fallback delays in the future.
However, if DNSSEC or any future option using EDNS is required, no
| fallback should be performed as they are only signaled through EDNS0.
If an implementation detects that some servers for the zone support
EDNS(0) while others would force the use of TCP to fetch all data,
preference SHOULD be given to those support EDNS(0).
NEW:
If a requestor detects that the remote end does not support EDNS0, it
MAY issue queries without an OPT record. It MAY cache this knowledge
for a brief time in order to avoid fallback delays in the future.
However, if DNSSEC or any future option using EDNS is required, no
| fallback should be performed as they are only signaled through EDNS.
If an implementation detects that some servers for the zone support
EDNS(0) while others would force the use of TCP to fetch all data,
preference SHOULD be given to those support EDNS(0).
d) Section 7 -- terminology and additional Reference
I suggest to capitalize the RFC 5226 term used here and add a ref. to
RFC 5226.
Further in terminology: with regard to IANA, "allocation" usually
indicates handing out a block of codepoints -- for instance for
assigment of code points contained within that block to specific
purposes by the entity that seeks the allocation (e.g.: IP addresses)
-- whereas "assignment" refers to the assignment of specific code
points; therfore, I suggest to switch the terms used.
OLD:
7. OPT Option Code Allocation Procedure
Allocations are assigned by expert review.
Assignment of Option Codes should be liberal, but duplicate
functionality is to be avoided.
NEW:
|7. OPT Option Code Assignment Procedure
| OPT Option Codes are assigned by Expert Review [RFC5226].
Assignment of Option Codes should be liberal, but duplicate
functionality is to be avoided.
e) Section 10 (IANA Considerations)
Because the two sentences contained in it are related to two different
namespaces managed by IANA, for uniformity of the presentation in this
section, I suggest to split the last paragraph of that section into
two:
OLD:
IETF Standards Action is required to create new entries in the EDNS
Version Number registry. Expert Review is required for allocation of
an EDNS Option Code.
NEW:
IETF Standards Action is required to create new entries in the EDNS
| Version Number registry.
|
Expert Review is required for allocation of an EDNS Option Code.
Kind regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| 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: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+