Inline On Thu, 9 Aug 2007, Andrew Sullivan wrote:
> First, the WG has already a work item on the topic of reverse > mappings, and has a candidate draft to deal with the topic. Since the > WG has spent a fair amount of time on that document, all the editorial > work that it has undergone would be wasted, and would have to be > re-done on the -anderson- draft. There is no waste. Those efforts culminated in my draft, and your draft. If it weren't for those discussions, I wouldn't have written my draft. If your draft is true and accurate, it can still go forward. (I don't think it is, but I'm just one person, though I don't think I'm alone in opposing your (Sullivan's) draft). I think Sullivan's document has moved off the topic of reverse status, and has essentially gone back to the ~2000 topic in the in-addr-required draft, advocating a specific kind of reverse mapping use. By contrast, my (Anderson's) draft is looking to document just the status: what we know for sure. I'm not advocating. Particularly, I'm not advocating that in-addr is required. I'm stating that in-addr isn't required; its just useful in some cases, and those cases depend on the purpose of the site creating the records. Kevin Darcy has an interesting use of PTR records at DaimlerChrysler. My draft just states the true status that no RFC states he has to use a certain kind of scheme. Darcy, and anyone, can invent whatever scheme they find useful. > Supposing there were no existing WG draft, however, there are some > additional matters in the -anderson- draft that would need to be > addressed before I could contemplate offering support for it. To > begin with, the language is strangely charged in a number of cases. > For example, there is this passage from section 1: > > Facts have been obscured by advocacy and false assumptions. > Consequently, myths have developed regarding the notion of proper > use of reverse DNS records, and what reverse mapping information > reasonably means outside of the organization providing the data. "Strangely charged" seems to assert there has been no controversy over these topics. 7 years of discussion on the DNSOP WG; renamed drafts because the title was too controversial, etc represent a lot of controversy. Outside the IETF, there is also a lot of controversy about the "proper" use of reverse mapping. It is a given that the topic has been controversial. > There are also several places in the document where a statement is > introduced by "Myth:" or "Fact:". The style makes for an arresting > initial effect, but I'm not convinced that the message is any clearer > for it. It also seems to manufacture controversy where none exists: > some of the "Myths" are propositions that I've never heard anyone > assert. Then you have no dispute with the fact that those myth propositions are wrong. In fact I've heard each of those myths in various forms and contexts. However, the important feature is that the myths are false. It doesn't matter that you've never heard them. I've never heard of internet hunting either, but 33 states have banned the practice. One doesn't have to wait until someone actually does something wrong, before saying that it is wrong. > In such cases, at least more evidence is needed. Generally speaking, > I think the document would need to be much more neutral in its > treatment of the topic than it currently is in order to be a draft of > the Working Group. You seem to have a strange sense of 'neutral'. Neutral like the 'in-addr-required' drafts? Facts are always neutral. Advocacy is not neutral. > In the same way, I think there is altogether too much > damn-the-torpedos certainty in the document. The text, on my reading, > describes issues in black and white where, in my view, there are many > shades of gray. Lets remember the myth the cited fact is exposing as false: Myth: Hosts with matching forward and reverse mappings are more trustworthy. No one, including Andrew Sullivan, has ever provided any scientific justification for this claim. A paper and software by Wietse Venema was previously cited as the source of this claim. However, Dr. Venema has stated that he did not intend to make such a claim in his paper on TCP wrappers, and that his paper and software should not be interpreted as originating this claim. So the fact (quoted below) is correct. > For instance, we have this: > > Fact: There is no justification for this conclusion. When pressed > for a reason, advocates say that one is entitled to make decisions > without justification because they have "incomplete information". > There is nothing about imcomplete information that justifies > irrational or capricous decision making. Every scientific experiment > and every court case involves conclusions and decisions based on > incomplete information. There are legitimate methods of making > decisions with incomplete information. No scientific or judicial > method involves an entitlement to act irrationally or capriciously. > Legitimate methods do not depend on false assumptions, particularly > those with security and trust implications. > > Bombastic assertions about scientific and judicial reasoning do not an > argument make. Actually, assertions about scientific and judicial reasoning are exactly what make up a valid argument. Correct assertions about scientific and judicial reasoning do have weight. Incorrect assertions about reasoning are discredited. Bombast (the term means pretentious and wordy) has no bearing on correctness and validity > Repeating that a course of action is irrational doesn't prove that it > is. Well, of course repetition has no bearing on anything. But the onus is on you (the author of the original claim, and person disputing my assertion of lack of rational basis for the original claim) to prove the original claim rational. The original claim has been argued extensively, and no one has ever given a rational basis. The failure to do so is a fact that can be cited. You do agree that decisions that aren't based on reason and rational bases are, by definition, unsound? A course of action is rational when there are valid, true, reasons that support that course, and it is irrational when there are no reasons; when the assumed-true statements are known to be false. This is not bombastic, and in it is indeed a valid argument criticizing those who claim they need no reasons for their views. But, importantly, the fact stated in my draft is fact, and is true. You need to show some facts that make your original claim rational. Otherwise, it is irrational. > On similar ground, I think that the RFC 2119 words should be taken out > of the document. Even if you think that such words belong in BCPs -- > and I'm not convinced -- it's unclear that they belong in a document > on this topic, where there are so many areas of disagreement among > competent operators. (Hmm. You asserted there was no controversy above) This is a repeat of a prior criticism that I think was adequately addressed. As I responded, then: I've found other BCPs that contain those terms, and the RFC editor has not commented or ruled that BCPs cannot have such terms. I sent a list of such RFCs previously to the DNSOP list. http://www1.ietf.org/mail-archive/web/dnsop/current/msg05387.html In fact, you continue to repeat the criticism even after there has been a demonstration that your claim that the don't belong in a BCP is incorrect. The second assertion, that RFC2119 terms don't belong where there is controversy, is also incorrect. I have only used these terms in the Security Considerations section. I don't think there is credible controvery over these recommendations: 4. Security Considerations DNS PTR records are entirely optional, and MUST NOT be assumed to exist. Software MUST NOT fail or incur delay as a result of the non- existance of PTR records. Unauthenticated DNS MUST NOT be relied on for security or trust decisions. Even when DNSSEC is used to verify the authenticity of DNS records, matching reverse and forward records do not imply either improved security or trustworthiness over sites that either do not have reverse DNS or that do not have matching foward/reverse DNS. DNS records MUST NOT be used in logs instead of IP addresses. Logging only the PTR resource records instead of the IP address is vulnerable to attack, since attackers may control the name, and may also use long names that will either become truncated by the logging system, or require upto 255 bytes to store. Logging both IP address and DNS PTR records may be helpful but one must also consider that the 255 byte per record space requirement does not become a DOS attack on the logging system. Wherever these recommendations have not been followed, security vulnerabilities have been found. The only cases were these recommendations wouldn't apply are the cases where security considerations aren't a concern. So they are appropriately qualified, and are always true. > It is also not plain to me exactly what the document is about: is it > about the reverse mapping feature of DNS, or about how to achieve an > end similar to what reverse mapping was intended to do? I believe all > the discussion of RFC1788 should be removed, because it's distracting > in the context. Alternatively, the whole document should be rewritten > as "ICMP Domain Name Messages Considered Beneficial", and turned into > an argument for that protocol. The purpose the draft is to give a status report on the facts as we know them at present: on how to find the reverse mapping of a host, and what reverse mapping data means to various parties. That is why RFC1788 et al are relevant: they provide means to find the reverse mapping of a host. David Hankin said something about RFC1788 being an old experiment. It is true, that 1788 is pretty old. However RFC4620 is pretty new, and is along the same lines only for IPv6. It is good to let people know about RFC1788, as well. My draft discredits those who assert myths about reverse DNS, and informs those who want to know what's out there for reverse mapping. I'll have to review 'bombastic'. Bombastic means pretentious or wordy. If you have some examples of pretentious words or unnecessary wordiness, I'd appreciate the suggested rewording. I don't agree the cited example was bombastic or unnecessarilly wordy, but if you have a specific rewrite in mind, I'll consider it. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
