At Sun, 4 Oct 2015 11:49:22 -0400, Dave Lawrence <t...@dd.org> wrote:
> > 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. I interpret this as the answer to my question is "we expect newer implementations are developed based on this specification". And we're going to publish it even if we know there are several technical flaws. Our mileage may vary about how "minor" they are, and I myself wouldn't say they are super critical, but if they are really super minor we should have been able to clean them up in this draft quickly, so they should be at least somewhat non-trivial. To be clear, I'm not necessarily opposed to that decision; the IETF is notorious about its very long timeframe, and it may just not make sense to go through all the overhead if we see some immediate needs for a relatively solid reference if not complete. But I believe it's irresponsible to obscure the intent as a means of avoiding possible pushbacks and getting it through faster (you probably didn't intended that, but for an external observer it could look that way). I believe because the new developers should be able to act based on "informed consent". I'm not sure if this view is shared by others - this is more or less a matter of opinion so if I'm a clear minority I won't be able to persuade many others just by keeping the discussion. So in that case I'll simply shut up. But... > 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? as you're at least suggesting some additional text (thanks for that, but that does not fully address my points), I'd offer mine: revise the following part of the last paragraph of Section 1: While they interoperate for the primary goal, they have varying behaviour around poorly specified edge cases. Known incompatibilities will be described. The authors believe that it is better to document this system, even if not everyone agrees with the concept or the details of the original specification, rather than leave it undocumented and proprietary. as something like this: This document describes the protocol that is currently used by those early adopters in the hope that new implementations can be as interoperable as those currently deployed. However, the existing implementations vary behaviour around poorly specified edge cases, and several technical issues that can cause interoperability problems have been identified through the review process of the document. Some of those issues are described in this document but are not necessarily resolved. The authors believe that it is better to document this system, even if not everyone agrees with the concept or the details of the original specification, rather than leave it undocumented and proprietary, so that more implementations will work with moderate interoperability sooner than later. A revised proposal to improve upon the identified flaws in this protocol will be forthcoming to the IETF. (note: it includes a revised "The authors believe..." sentence, but obviously I can't speak for the authors. This is just based on my guess of what the authors intended). > > - 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: Hmm, I guess I'm now (more) confused...the sentence before this one is: [...] If the Recursive Resolver will not forward the FAMILY and ADDRESS data from the incoming ECS option, it SHOULD return a REFUSED response. so I thought the "ECS-aware resolver" is a resolver that receives a response from the Recursive Resolver. And my question was whether it's really "the common convention" that a Recursive Resolver returns a REFUSED when it encounters a lame delegation. I don't know if this suggests the need for revising the text, but if only to educate me some more explanations on exactly what kind of situation is intended might help. > > - 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. This (and other links referenced in the message) will probably help: http://www.ietf.org/mail-archive/web/dnsop/current/msg13428.html and this one is related to my "high level question". Especially if we envision that more implementations based on this document will be developed and deployed but we are not willing to resolve technical issues identified so far, I think the current text is a bit irresponsible. I'd at least explain the following: - a mixture of more/less specific prefixes can lead to interoperability problems - what the current practice does for these today (e.g., simply avoid having such a configuration, or it has been just lucky not to have this setup, etc) - (assuming that's the intent) this point will be clarified more explicitly in the expected revised specification > > - 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. I don't think I can offer any specific text unless my question is answered...perhaps I can suggest something if at least it clarifies specifically what "perform Network Address Translation (NAT) as described in [RFC2663]" means. Anyway, if it's only me who are confused, I wouldn't be opposed to it if my question is just ignored. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
