On Wed, Sep 16, 2015 at 9:05 AM, Suzanne Woolf <suzworldwide@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