At Wed, 4 May 2016 11:43:16 -0400, Ted Lemon <mel...@fugue.com> wrote:
> Jinmei-san, with all due respect, I think that you are missing the mark > here. First off, I didn't intend to be opposed to providing reverse mappings per se. If my comments read that way, that was because of my poor writing ability (I'm also aware that my points are subtle, so it's not actually that surprising). My main concern was about the attempt of using it (especially with checking a reverse-forward match) for purposes like access control/host validation, about this draft discussing how to provide reverse mappings (and, again, largely focusing on ensuring the reverse-forward match) along with describing those purposes, and yet about us (at least you, me, and some others in this WG according to this thread) considering those purposes to be a "terrible idea". I fully understand this document does not provide normative requirements. But in the way it's currently organized, I'm afraid it will simply promote a vicious circle: more people will think they need to provide reverse mapping (and in particular ensure the reverse-forward match) in the face of the existence of the "terrible idea"; then people employing such ideas will have even less reason to stop the terrible practice, the terrible practice will proliferate even more widely; then even more people will see the need for providing reverse mapping (and reverse-forward match) for this reason... To me, just not including normative text isn't enough to stop it. Cynics might say the terrible practice won't go away whatever we say in an RFC. That might be true, but I'd still like to give it a try instead of simply giving it up completely. [...] > Nevertheless, operators have to deal with support calls when there is no > PTR mapping, and end users have to deal with the inaccessibility of > services operated by people who still believe in and rely upon the RFC 1912 > recommendations. I personally think it's a terrible idea to use PTR > records for host validation, yet I still want PTR records set up according > to RFC 1912 because I care more about being able to access services that do > PTR lookups than I do about purity. I see the point, and it made me realize that this is another incident of a common pattern: people who employ terrible practices are different from people suffering from those practices, and we have a dilemma of whether to help the latter or to even promote the bad practices as a result. So, do we share a view something like this? While a reverse mapping is generally useful for informational purposes, some people use it even more aggressively, such as for access control or host validation based on the existence of a reverse mapping, and often also on matching between the reverse and forward mapping. It is believed that those practices are not very effective at best, especially for their side effect of punishing otherwise-legitimate users and their service providers. Although an ideal solution to this is to encourage stopping those harmful practices possibly with replacing them with more effective ones, the sad operational reality is that it's less likely that the operators employing those practices will listen anytime soon. Until then, the victim end users and their service providers will pay the cost of the practices, and the only realistic intermediate remedy is to provide required reverse mappings and often ensure the revers-forward match. This document shows possible options on how to do this for those latter types of operators. If so, I believe we're not on so different pages, and it's probably just a matter of how to present it. If we even have a fundamental disagreement here, perhaps we have to disagree, and see how the wg concludes in the end. And, finally, about this: > The point is that the mere fact that you do not think this is useful isn't > a reason not to publish it. The working group already got consensus that > this work was useful when we adopted it; the question now is, are there > _mistakes_ in the document that need to be corrected prior to publication, > or that would mean that despite the working group consensus to adopt the > document, it is no longer a good idea to publish it. I do not think the > concerns you have raised are the sort of concerns that would motivate such > a reconsideration. I thought a WG last call is a good chance of raising any substantial concerns even if it was against some original consensus at around the adoption time (when it's often the case where people can't anticipate all possible issues). So, in general, I don't think I have no right to raise an issue like this (even if and) simply because the wg had a different consensus before. Whether a specific comment/opinion is substantial enough is a different question. I respect your view is that it's not, but after all this kind of matter is generally subjective. I still believe it's important, but as I'm aware that's also just another subjective opinion, I'll see what others think. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
