Last Call Review of draft-ietf-dnsop-edns-client-subnet-04
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
Reviewer: Russ Housley
Review Date: 2015-12-11
IETF LC End Date: 2015-12-21
IESG Telechat date: unknown
Summary: Almost Ready
In Section 6, the figure includes a line that begins with "7:". This
is incorrect. It should begin with "8:".
Section 7.2.1 ends with: "Implementations SHOULD document their chosen
behavior." I have no objection to such documentation, but some advice
about where someone might find it would be useful. I do not think you
are asking each implementation to write an Informational RFC. Further,
the use of "SHOULD" in this sentence has nothing to do with the normal
RFC 2119 usage, which applies to the action taken by an implementation.
Section 7.5 says:
Intermediate Nameservers supporting ECS MUST forward options with
SOURCE PREFIX-LENGTH set to 0 (that is, completely anonymized). Such
options MUST NOT be replaced with more accurate address information.
An Intermediate Nameserver MAY also forward ECS options with actual
address information. This information MAY match the source IP
address of the incoming query, and MAY have more or fewer address
bits than the Nameserver would normally include in a locally
originated ECS option.
These two paragraphs appear to contradict each other. I cannot figure
out what an Intermediate Nameservers that supports forwarding of ECS
options ought to do with regard to source address information.
Please divide the references into normative and informative. The URIs
should be informative references. URIs must be stable references, and
I do not think that  qualifies.
The last paragraph of the Introduction provides information that is
useful to someone doing a review. However, it is not clear to me that
this information belongs in the Informational RFC. I think that it
would be sufficient to say:
At least a dozen different client and server implementations have been
written based on earlier versions of this specification. The protocol
is in active production use today. While the implementations
interoperate, there is varying behaviour around edge cases that were
poorly specified. Known incompatibilities are described in this
document, and the authors believe that it is better to describe the
system as it is working today, even if not everyone agrees with the
details of the original specification . The alternative is an
undocumented and proprietary system.
If you accept this approach, then you might also look for "original
draft" elsewhere in the document ans make a compatible change.
In Section 6, I think it would be useful to say that the SCOPE
PREFIX-LENGTH in a response MUST be less than or equal to the SOURCE
In Section 7.1.1, can you add a sentence or reference to explain "lame
delegation"? I recognize that this type of error results when a name
server is designated as the authoritative server for a domain name and
that server does not have authoritative data.
Section 7.4 says: "Several other implementations, however, do not
support being able to mix positive and negative answers, and thus
interoperability is a problem." Then, the next paragraph says that
this topic will be revisited in a future specification. Is there any
advice that the authors can share as a step toward interoperability
that would be useful for implementers until the future specification
Other Editorial Comments:
There are many places in the document where is says: "This draft ...".
These should be changed to "This document" or "This specification" in
preparation for publication as an Informational RFC.
In Section 4, some of the terms being defined are followed by a colon,
and others are not. Please be consistent. I prefer the inclusion of
In Section 7.5, it says:
It is important that any Intermediate Nameserver that forwards ECS
options received from their clients MUST fully implement the caching
behaviour described in Section 7.3.
To me, "It is important that" and "MUST" are redundant.
In Section 11.3, it says:
o Recursive Resolvers MUST never send an ECS option with a SOURCE
PREFIX-LENGTH providing more bits in the ADDRESS than they are
willing to cache responses for.
I think it would be netter to reword this as a MUST NOT statement.