At Wed, 30 Sep 2015 16:32:07 -0400, "Joe Abley" <jab...@hopcount.ca> wrote:
> > 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, > > I know of at least one significant implementation based on the current > specification that is proceeding right now. So that's a vague, > unsubstantiated data point for you :-) > > There is significant customer demand in the enterprise DNS market for > features that require edns-client-subnet, and a significant resolver > population that supports it today. I think it's unreasonable to expect > either that commercial operators will be willing to publish their > internal product plans to dnsop or that silence from that community > implies that no work is being done. Perhaps I was not clear enough about my intent, since this point is irrelevant to it; it's totally up to the developer/operator whether to implement/deploy a specification even if it's explicitly discouraged. That's their business and that's fine for me. I didn't try to know such attempts by my question above. My point is: - If, while knowing developers/operators do whatever they want anyway, we basically intend this document to just describe the current practice than a specification for newer implementation, IMO we should more explicitly state so and even discourage the attempt of implementing it for now. Especially as we expect a revised document will be written (soon?), and because the current document simply diimsses some known issues with the excuse of "this is just describing what's currently implemented". Again, some may still ignore the warning and go for it anyway, but, IMO, it's more responsible for us to at least explicitly discourage it to avoid having more incomplete/immature/less interoperable implementations. - On the other hand, we actually expect more implementations will come based on this publication, at least some of the glitches should be fixed before the official publication. The (mis)use of REFUSED RCODE would be one such point. Some privacy related considerations might be another. Behavior with less/more specific prefixes might be yet another. Some of these issues might still be considered "out of scope for now", but in its current state I think this document dismisses those too casually. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
