Hi Dean, Thanks for your response. I'm still unclear about a few things, so I'm replying here.
On Mon, Jan 08, 2007 at 11:01:06AM -0500, Dean Anderson wrote: > > The phrase "best if the reverse tree works" implies that somehow > the reverse tree doesn't work. [. . .] The reverse tree works no > matter what. It works if there are no records. It works of the > records that are there don't meet the spam/security forward/reverse > test. Your implication that it somehow doesn't work is wrong and > misleading. Perhaps I should re-phrase that as "best if the reverse tree contains usable data." Some people apparently find that their decision making is better if the reverse tree and the forward tree both contain data for a given host. Sometimes, those people find it useful to compare the data and try to match it, and to make additional decisions on that basis. I don't know whether that decision on their part is a good idea in their circumstances, because I'm not familiar with all of their circumstances (and I claim that nobody except the admin in question could be). So, absent other overriding considerations, it is best on the whole if such data is available. But I think it's clear that the draft _does_ suggest other considerations might be overriding. Do you think it doesn't? > changed. All you have done is reword your document with ambiguous > statements, terms and phrases that have double meanings. I think gratuitious _ad hominems_ unsupported by any quotations can probably be omitted from our conversation, no? Thanks very much. > This is a fault, not a benefit. Standards documents should be clear, But as I've already pointed out, this is not a standards document. Therefore, it is not allowed to have prescriptive language. This is per the normal RFC process in the IETF, as far as I know. I'm sure the Chairs will correct me if I am mistaken. > > > Reverse records are entirely optional. Matching reverse with > > > forward is entirely optional. > > > > Would you be able to point to the text in the draft that says > > otherwise, please? > > Certainly. > > At the same time, some sites have attempted to use reverse mappings > as a part of a security- or abuse-prevention policy. Note that this part of the text does not in fact say that they _should_ use such data; just that they do. Moreover, since such policies are developed at the site level, I can't imagine how anyone could legitimately say that the local admins at that site are wrong. They may decide that draconian measures are useful to them, or that they are so devoted to reverse mapping that they refuse to allow anyone who doesn't provide it to connect. Or, for that matter, that they just are too lazy to revisit old decisions. The point of this doc is not to say whether they are correct or mistaken, but to outline what _considerations_ one needs to take into account. [RFC enumeration elided] > None of these RFCs utilize PTR records, and so cannot benefit from > "accurate reverse mapping data". All of them involve DNSSEC or require > DNSSEC to be secure. That the protocols do not use PTR records does not entail that no admin could find such data useful. Since at least one person has suggested that, combined with DNSSEC, reverse data reflecting the forward zone could be useful, it seems false to me that these cannot so benefit. I'm willing to add a reference to DNSSEC, and to change the language to "reverse data in accordance with the forward data" instead of "accurate reverse mapping data", if that will address your concern about the potentially loaded term "accurate". > that matching forward and reverse improve security somehow. Then you > include examples of "missing" reverse data and imply that this is a > problem to be fixed. Thus, you impute (incorrectly) that PTR records are The draft does not imply that it is a problem to be fixed. It suggests that reverse data that is not there, or does not match, may create some side effects of which some are not aware. There is a difference between that and "a problem to be fixed", and I think the draft is pretty careful to stay on one side of that line. If you have counter-examples, please let me know. > _You_ already have. Section 3.1 "Examples of effects of missing reverse > mapping" is entire devoted to "bad things": No, it is not. It is a listing of the effect when a site that has decided to rely on the reverse tree is unable to find a reverse mapping entry where it is expected (by the site in question). That does not entail "bad things". It does entail "these are effects you should be aware of if you elect not to maintain reverse mapping", which is a different claim. I think the document is clear about this, but you apparently haven't understood it, so if you can tell me how it is unclear on this topic, I'd be much relieved. > The examples you included in Section 3.1 are examples of > _mis-application_ of reverse DNS. Yet your positively phrased > description encourages these behaviors, rather than illuminates the > false assumptions on which they depend. These are neither positively nor negatively phrased descriptions. I think you will find, if you read a little farther, that the draft also says that such applications are probably not serving the purpose many admins think they are. The point is merely to say, "Here is something that people do, so if you do not provide reverse mapping, their attempts will fail." > This is a specific example of wrong assumptions about PTR records. Your > draft is about PTR record usage. Let's please stick to the text of the draft, and not some random other thing. Only the text of the draft is what will count in the long run. > 1) The complete absense of any text specifically saying this behavior is > bad. This assertion is false, as I have already pointed out. That you keep repeating it makes me think that you haven't actually read the entire text. > 2) The biased tone that indicates the cause is "inaccurate reverse > data". This phrase is prejudicially negative. It makes it seem that one > should maintain "accurate reverse mapping data", which though undefined > in your document, appears to mean matching forward and reverse. I suggested, above, a modified turn of phrase that might address this issue. Does it? > The "right" answer is determined fully by the intent of the > administrator and the form of the protocol. There are only two issues: > 1) did the administrator mean to enter that data? (only the > administrator can answer that) > 2) was the response properly formed per the DNS protocol? (this is the > only issue of correctness that the client can determine.) Those are the two things I meant, yes. > Neither of these imply your claim that the PTR records must meet the > spam/security forward/reverse match test. Perhaps you could provide a > reference for that claim. I haven't ever made such a claim. I don't know why you think I have, but I haven't. > If true, then this document should not be considered by the working > group. I think you are mistaken about how the RFC process works. I defer to the Chairs, however, on this matter. > However, my understanding is that this document is intended to > become a BCP. I've been led to believe the intended status is informational, actually. > Where do you propose placing this text? I don't propse to put it anywhere, precisely because I don't think the text is true, as I noted already. > Indeed. Lets note in the draft that sites _can_ choose to do what they > want, and other sites must not (MUST NOT) depend on them doing something > in particular. There's nothing in the document that says otherwise, as far as I can tell. > My language is clear and specific, and it resolves the ambiguity in your > descriptions. But you haven't pointed out any actual ambiguity, as far as I can tell. I'll ask the group, though: is there anyone who agrees with Dean's diagnosis of ambiguity? > RFC 2119 language is not about enforcement. Its about stating the > necessary requirements. In which case, I claim your proposal is a fatuous requirement. Given the existence of the reverse tree, it seems perfectly legitimate to me for some sites to try to use it for various purposes. One of those is logging. > So you dispute my assertion of a message, and then agree that the draft > does say that message. Nice. You are in the wrong line of business. Where I come from "a possibly useful feature of the Internet is lost, and various people might decide they don't want to talk to you" is not equivalent to "bad things happen". At least, not if you take into consideration that the feature and communication might be lost. An informed decision to lose a feature is not a bad thing. > That behavior is not a position the IETF should support or encourage. Your view is noted. I simply disagree with you about that. > There is also something disquieting about your statement: People who > willfully act on assumptions they know to be false are at least > irrational. Bosh. I won't bore the list with a recitation of the number of thought experiments which proceed on such grounds, just to get started. Similarly, every time you use Newtonian physics to solve a problem, you're willfully acting on such assumptions. And simplifying assumptions are often useful, even if they cause you problems in some marginal areas. > Your draft omits information that explains how certain assumptions about > PTR records are wrong Aside from the charged word "accurate", do you have any other examples? I don't see any you've provided. 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
