Thank you, Jinmei, for your thoughtful feedback.
Jinmei writes:
> 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.
While I appreciate your overall point, I think in practical terms we
can't really expect the parenthetical above, that "newer
implementations should rather wait". Even if I had that draft pushed
out right this very minute, realistically it'll be a year for it to
get through IETF review, and additionally have somewhat less incentive
for rapid adoption than the original draft did.
Anyone that wants to interoperate with the companies currently using
ECS in any "Internet-speed" timeframe is going to have to support this
method, which even with the minor flaws that has, is still basically
pretty good for addressing the original goals that motivated it.
That said, I can add this remark to the end of the introduction:
"A revised proposal to improve upon the minor flaws in this protocol
will be forthcoming to the IETF."
Is that reasonable enough to address your concern?
> Some more specific comments on the draft text follow, most of which I
> think are minor and non-blocking:
Thank you, I have incorporated most of these into our github version,
to be -05.
> - 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.
This was one of the most interesting comments to me, because it
actually revealed a source of terminology confusion in the DNS for
which the document was at odds with other RFC usage. The confusion is
not unlike that of "CNAME", as far as source and target are concerned.
A Forwarder in the RFC sense has been the target of forwarded queries,
while elsewhere (such as Microsoft Technet notes, and this document)
expect it to be a server that does the forwarding to another recursive.
(I suppose that would make the target a "Forwardee".)
I have added this definition, and changed occurrences of "Forwarder"
to "Forwarding Resolver":
Forwarding Resolver A nameserver that does not do iterative
resolution itself, but instead passes that responsibility to
another Recursive Resolver, called a "Forwarder" in [RFC2308]
section 1.
> 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.
Added "number of" to both.
> - 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.
Right, a recursive would return servfail for its client, but it is
true for authorities, including BIND 9.9.7-P2 running at ISC:
$ dig whatever.whatever @ord.sns-pb.isc.org | grep status
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 12817
> - 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?
I'd have to dig up the history, honestly.
> - 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?
It was trying to describe that the main thing that was trying to be
accomplished originally was just to enable positive tailored responses
to address queries. I've changed the second sentence to incorporate
this so it now reads,
"The expectation of the original authors was that ECS would only
really be used for address requests and the positive result in
the response's answer section, the use case that was driving the
definition of the protocol."
> - 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).
I'm really not sure how to meaningfully change this. The second
sentence seems fairly clear to me in saying "look, just don't even
muck with ECS". Please let me know if you have specific text to make
it better.
> - 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.
No, I agree with you that it is unreasonable to expect a resolver to
know it is behind a NAT, and the section was attempting to exonerate
them from that. I changed "Recursive Resolvers sited behind a NAT"
here to "if a Recursive Resolvers knows it is sited behind a NAT".
> - 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.
New text for that sentence:
Additionally, Recursive Resolvers SHOULD be configured to never send
the option when querying root, top-level, and effective top-level
(ie, "public suffix") [6: https://publicsuffix.org/] domain servers.
I know there is ongoing discussion in the IETF dbound group about
these delegation-centric domains and terminology around them, and if
someone thinks that better text or an alternative link is needed here
I'd be happy to substitute it.
> - Section 15: s/Internet Software Consortium/Infoblox/ (please keep my
> current employer happier:-)
>
> ... Tatuya Jinmei from Internet Software Consortium;
Done.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
