Jinmei writes: > 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.
Yes, your interpretation of the answer is correct. But it's an Informational draft, describing existing practice. We don't really have a lot of latitude to fix even the minor issues here, in my opinion, without making the draft even bigger and more complex and describing something that existing implementations are not doing. > as you're at least suggesting some additional text (thanks for that, > but that does not fully address my points), I'd offer mine: > > 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. This seems basically fine with me, and I'll consult with the other authors and the chairs. > > > 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. ... > > Hmm, I guess I'm now (more) confused... 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. Ahhh I see your overall point now, because you're absolutely right that in that context of a recursive to its client, REFUSED is not used for signaling lame delegations. I'll see what I can do to shift some things around to make it clearer that the overloaded meaning of the REFUSED response needs to be resolved for the recursive<->authoritative interaction. > > > 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 I didn't write the text you're referring to, but yes I believe it was an attempt to address it, and I think it's sufficient because we're really not getting into the details about how authorities come up with answers, which is why this was kind of a hand-wavy, "you should be aware of this issue and figure out some way to deal with it in your own situation". > - a mixture of more/less specific prefixes can lead to > interoperability problems This depends on how you define interoperability problems. The protocol itself will work. I think making implementers of authoritative ECS systems aware that the order in which the CIDRs are filled matters is sufficient warning to have them figure out how to manage the issue. Recursives, on the other hand, can't really do anything other than cache what the authority tells them, no matter what the draft says. > > > Special awareness of ECS in devices that perform Network Address > > > Translation (NAT) [...] > > > > I'm really not sure how to meaningfully change this. [...] > > I don't think I can offer any specific text [...] > Anyway, if it's only me who are confused, I wouldn't be opposed to > it if my question is just ignored. For the record, I'm explicitly not ignoring this, but I'm personally still at a loss for what to do about it and am still inclined to leave the NAT section as-is. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
