On Wed, Sep 16, 2015 at 9:05 AM, Suzanne Woolf <suzworldw...@gmail.com> wrote:
> This begins the working group last call for > draft-ietf-dnsop-edns-client-subnet, "Client Subnet in DNS Queries.” The > document has gotten significant feedback and the editors have worked hard to > document current use of the client-subnet EDNS option. > > We’re seeking consensus to advance it to the IESG with an intended status of > Informational. If you support it, please say so. If you don’t, please say > why. I'm not necessarily opposed to advancing it, but I have one high level question. It would be nicer if it can be clarified before advancing it: are we expecting newer implementations are developed based on this specification, or is this document literally for describing the current practice for the record (and newer implementations should rather wait for more complete specification in the assumed revised publication)? This point wasn't clear to me, and I hope it's more clearly stated in the final version of the document. Also, if the intent is the latter, I wonder we might rather avoid using RFC2119 keywords (but that's not a strong opinion). Some more specific comments on the draft text follow, most of which I think are minor and non-blocking: - Section 4: the term "Forwarder" is used without a definition. I think it's often confusing (different people tend to use it for different meanings), so it would be better to give its definition for the purpose of this document. - Section 6 o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost significant bits of ADDRESS to be used for the lookup. I think it'll be more accurate if it says: "representing the number of leftmost significant bits". Same for SCOPE PREFIX-LENGTH. - Section 7.1.1 An ECS-aware resolver MUST retry the query without ECS to distinguish the response from a lame delegation, which is the common convention for a REFUSED status. Is this true? To me it's a rather unusual choice to indicate a lame delegation. For example, if I remember it correctly ISC BIND 9 returns SERVFAIL if all supposed-to-be-authoritative servers are lame. - Section 7.2.1 If the Authoritative Nameserver operator configures a more specific (longer prefix length) Tailored Response within a configured less specific (shorter prefix length) Tailored Response, then implementations can either: Just checking: is this an attempt to address the suboptimal scenario I raised in my review of a previous version of draft? - Section 7.4, first paragraph: The prohibition against tying ECS data to records from the Authority and Additional section left an unfortunate ambiguity in the original specification, primarily with regard to negative answers. The expectation of the original authors was that ECS would only really be used for address records, the use case that was driving the definition of the protocol. The second sentence sounds a bit awkward to me, since the issue of negative answers should basically be irrelevant to whether the query is for "address records". Perhaps it's intended to explain the background on the issue with delegation cases? - Section 10 Special awareness of ECS in devices that perform Network Address Translation (NAT) as described in [RFC2663] is not required; queries can be passed through as-is. The client's network address SHOULD NOT be added, and existing ECS options, if present, SHOULD NOT be modified by NAT devices. I'm not sure if I fully understand the second sentence. Does it assume this NAT device acts as something like DNS-ALG? If so, I think it's better to say so more explicitly (RFC2663 is quite broad). - Section 10 In other cases, Recursive Resolvers sited behind a NAT device SHOULD NOT originate ECS options with their external IP address, and instead Does this assume that the operator of the recursive resolver knows it's behind a NAT and configures that way? If so, I'd suggest stating that explicitly. In its current form it could read as if the recursive server implementation somehow automatically detects that it's behind a NAT (it might be possible but not very trivial), and therefore sounds a bit awkward to me. - Section 12.1 Additionally, Recursive Resolvers SHOULD be configured to never send the option when querying root, top-level, and effective top-level domain servers. I suspect the meaning of term "effective top-level domain" is not very clear (I actually have almost no idea about what it is - something like "co.jp"?). If there's a reference I'd add it. Otherwise, I'd explain what it intends to mean more specifically. - Section 15: s/Internet Software Consortium/Infoblox/ (please keep my current employer happier:-) ... Tatuya Jinmei from Internet Software Consortium; -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop