Hi Dean, On Sun, Feb 18, 2007 at 01:11:15AM -0500, Dean Anderson wrote:
> On January 8, 2007, I posted a list of examples of published > informational RFCs that include this language. That demonstrates that > RFC2119 language is allowed in informational RFC's. In my view, it is not completely relevant what has been tolerated historically. The only question in my opinion is what RFC 2119 says it is intended to do. Since it says that it is intended to be used for standards, and since this draft does not propose any standard for the Internet community, I can't see how RFC 2119 language ought to be used. > Security vulnerabilities are included as harms that 2119 is talking > about. You haven't refuted the statements I proposed putting in the > Security Considerations section. I didn't see anything to refute. I said so, I think, especially in <http://www1.ietf.org/mail-archive/web/dnsop/current/msg00056.html>. I know that I asked why you thought your formulation was better than what is in the draft, and you said that the draft is ambiguous. I asked the community whether they agreed, which is how we got this thread. For what it's worth, I think you have used the word "ambiguous" to mean "does not say something I agree with". It is probably true that the draft does not say unequivocally, "You should do _X_." I think that is correct: I don't believe that there is one right answer for all cases with respect to reverse mappings. I think that there are cases where adding more PTRs will do more harm than good. That said, in most cases I think it is possibly useful for other users on the Internet if people maintain matching reverse mappings for their hosts; and, to the extent interoperation is aided by possibly useful things, we should therefore come down mildly in favour of such things. > > That is, you might think it a foolish thing to draw any conclusions > > from reverse tree data; that does not mean that others, with different > > experiences or situations, would in their cases reach the same > > conclusion. > > Indeed, logic does mean that other rational persons would reach the same > logical conclusions. Mathematical logic doesn't change due to > experience or situation which are irrelevant to the assertions. [. . .] > This is exactly the distinction between rational and irrational. I'm afraid that you have fallen into equating "rational" and "logical". They are not the same thing, as we can see by considering the difference between deductive and inductive reasoning. The current discussion cannot be resolved exclusively with deductive reasoning, because we are discussing individual administrators' decisions about how to respond to traffic arriving at their networks, on the basis of an admittedly poor metric. That poor metric's results are to be evaluated in light of other evidence; I think the draft already says as much. (I have made some edits that will appear in the -02 draft -- to be uploaded as soon as Daniel and I have agreed on the final words -- to strengthen that message, because of the feedback the group has provided, but -02 will not say anything substantively different than it already says, I think. These edits are in addition to the changes I already committed to.) It is not irrational to make decisions on the basis of imperfect evidence. Nearly every empirical conclusion works the same way. (Try using mathematical logic against Berkelian idealism. For that matter, we have plenty of reason to believe that the data Kepler was working with was not terribly good; he was nevertheless right.) And in our world, where different people are trying to solve different problems on the basis of the same poor evidence, I think it not at all surprising that rational people reach different conclusions even in light of the same evidence. You seem to believe that using the reverse tree in decision making in some of these cases is always wrong. Other users with relevant experience &c. have reached a different conclusion, presumably on the basis of their experience and the evidence at their disposal. This difference is why the draft generally tries to argue both that people should provide reverse mappings all else being equal, and also that people shouldn't put too much stock in the non-existence or non-matching of the reverse data. I hope this makes it clearer to you why the draft takes the approach it does. Best regards, A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
