On Fri, May 6, 2016 at 12:34 PM, 神明達哉 <jin...@wide.ad.jp> wrote:
> 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... > > I think this is a legitimate concern, although I feel that the document, particularly with the change Lee agreed to, does a good job of avoiding that. However, as you say, communication is hard, so perhaps I am being overly optimistic. 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? > Exactly. > 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. > The problem with this text when it was proposed before (it was proposed before!) is that not everybody agrees on it either. So last time we had this discussion (which we have had more than once already, not counting this time), we decided to just be neutral, rather than either saying "this is a bad idea" or "this is a great idea." I think the document is still useful, because honestly I do not think it is going to make much difference as far as host name checking goes. I think if we want host name checking to die, we should talk to authors of open source software that support this feature into taking it out. I think, for example, that openssh does this. Maybe we should talk to them. > 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. You can certainly argue that any objection can be raised at any time. However, as a practical matter, if we don't set the "do not publish" bar fairly high, it becomes impossible to ever publish anything, because for any discussion that did not achieve unanimous consensus, it can always be reopened. I am not the one calling consensus here (indeed, at present there is no context within the IETF in which I could or would call consensus). But if I were, I would encourage the authors to try to make the language as neutral as possible (as I have done, as an individual participant), but would not try to say "if the authors won't say this is a bad idea, then we shouldn't publish the document." I supported adoption of the document, even though there was no consensus to say that hostname/ptr validation is a bad idea, because I think that making operators aware of what their options are is more important than trying to fix the hostname/ptr validation problem. I very much agree with you that we should formally deprecate hostname/ptr validation, but to make that part of this draft effectively means that we don't publish this draft, I think. So this is actually a really good example of the principle that I expressed earlier about last call consensus.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
