On Tue, 6 Mar 2007, Andrew Sullivan wrote: > > I don't understand what is in section 3.1 of -anderson- that is not in > -reverse-mapping- -02. In particular, I don't see what any of > > Myth: "Registries require IP users to populate reverse mapping." > > Fact: Registries generally encourage, but do not require, customers > to use reverse mapping. > > Fact: Registries may remove reverse mapping delegations on their own > initiative if the delegated nameservers are lame. > > say that is different from what is in the reverse-mapping draft. The > -02 draft is, in my view, pretty clear that the RIRs do not -- indeed, > cannot -- require reverse mapping, that some of them encourage it, and > that they have their own policies.
We've had this discussion before over the years. What is stated about RIRs continues to change. Reverse mapping only works if all the intermediate delegations are correctly maintained. As a result, RIRs find they cannot enforce policies requiring reverse mappings, because they sometimes do not have any relationship with the intermediate party on whom some end-point reverse mapping depends. The text from your -02 document, above, now implies that registries desire in the future to, or have previously tried to, enforce reverse mapping policies, but found an obstacle to the enforcement in the intermediate parties. That implication is untrue. My text describes what the registries have done, and could do, without false implications. > > 3.3, > > I think you've been guilty here of the same charge you levelled at the > -01 reverse-mapping draft -- of using charged language to try to make > a point. The "fact" subsection in 3.3 is actually a conclusion, and > one for which there is presented inadequate argument. The fact subsection of 3.3 contains the evidence to support its conclusion within its body. The conclusion in 3.3 is that you have failed to offer proof of your claims. That is a valid statement, and the section describes the actual statements that were made. Obviously, if you could prove that your claims, you could prove, by evidence, that 3.3 is false. Your lack of evidence is itself the necessary evidence that the 3.3 conclusion (which is that there is no evidence supporting your view) is true. You have merely claimed there is inadquate argument in 3.3, but again, you haven't offered any evidence for your claim. > Moreover, you have failed to make the distinction, made in the -02 > reverse-mapping draft as an outcome of your previous objections, > between "matching" and "existing" reverse data. My affirmative arguments don't depend on the distinction. It was your statements that were shown false by using the distinction. But I note the strains on your -02 draft attempting to try to make true statements by using the distinction. Rather than follow the same rathole again, as I did in previous years, I just wrote an alternative draft. I am reminded of the court arguments reported recently regarding Intelligent Design. The Intelligent Design advocates claimed in their documents that scientists had no evolutionary evidence for the immune system. In court, a lawyer presented a stack of books and scientific papers describing the evolutionary development of the immune system. Yet, faced with the stack of evidence refuting the claim, the Intelligent Design person on the stand would not admit the claim about the immune system was wrong. Of course, the Jury found otherwise. Intelligent Design wasn't just bad science but a religon; a legal strategy developed to teach Creationism is public schools in 1987 after Creationism was found to be a religious view. I've had exactly the same kind of experiences with zealous anti-spammers. > I think there is some discussion of this > topic in -reverse-mapping- -02 that is relevant to your objections. > I've asked for your feedback on that text, but I haven't received any. I've submitted an alternate draft. That might be considered entirely alternate text. I don't believe you will change the meaning of the draft. > > and 4 of the Anderson draft and corresponding sections of the > > Sullivan/Senie draft. > > I believe I already addressed the issue of RFC 2119 keywords in > -reverse-mapping-. In my view, the use of them in section 4 or any > other section of -anderson- would be just as mistaken: neither > document, as near as I can tell, proposes any standard of any kind for > the Internet community, and therefore RFC 2119 keywords are not > appropriate. I did not receive a response from you in respect of that > argument; if you have one, I would be interested to hear it. 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. On February 18th, 2007, I posted the text I just pasted in regarding the 1/8/07 post. 2/18/07: http://www1.ietf.org/mail-archive/web/dnsop/current/msg00149.html 1/8/07: http://www1.ietf.org/mail-archive/web/dnsop/current/msg00062.html On February 20, 2007, you responded that it was your opinion that RFC2119 only applies to standards. I did not respond to your message, since there seemed to be nothing new to say. As already shown, in contrast with your opinion, there is no text in RFC2119 that precludes its use from information documents. There are plenty of informational documents that do cite RFC2119. Further, RFC2119 affirmatively states that its defined terms are particularly relevent to security considerations. Informational RFCs can have security considerations. The notion that informational RFCs are not technically 'standards' appears, by all available evidence, to be irrelvent to RFC2119 purposes. You don't seem to have proven you case, despite your contrary opinion. You have certainly received responses. However, I am not an authority, either. But, absent an authoritative response by the chairs or the RFC Editor or someone in authority, the available evidence supports my view. However, my draft is submitted on a BCP track, which is a kind of standard. > > problems with that draft are not new, but have been repeated in various > > forms, often just by trivial word changes, since the original > > What would qualify as non-trivial word changes in your opinion? This seemingly simple question is actually an astonishingly hard question to answer. It is truly very difficult to pin down people who don't want to be pinned down. That's why lawyers make so much money. I think the simplest answer, in this particular case, is that you would have to change your mind about some things you believe fervently. > It is my rather strong belief that changing the words one uses changes > the meaning of the sentences in which one has used those words. Hmm. I think it can go either way, depending on the choice of words. Let me give it a try: [limiting to synonyms in the same sentence structure] "It is my preferably mighty credence that altering the terms one employs mutates the meaning of the sentences in which one has employed those terms." This means the same as the original text. So you can change the words without changing the meaning. [synonyms thanks to Rogets and Merriam-Webster]. But indeed, your statement can certainly be true depending on the choice of words. Lets try again: "It is my somewhat healthy faith that converting the communications one applies transmutes the meaning of the sentences in which one has applied those words." This perhaps suggests that maybe, possibly, encoding changes the meaning. So you can change the meaning by changing a few words. [again, just a different set of synonyms in the same sentence structure--so, in some sense, it does represent your statement.] I think one probably needs a more complicated example to make a good analogy to explain what is going on in these drafts over the last years. It will be much easier to write an alternative draft. I should have done that years ago. Hindsight. > I do believe that -reverse-mapping- -01 and -02 are saying > substantially the same thing, but the point of -02 was to clarify the > parts of -01 that did not capture what the group was trying to say; In my view, you obviously aren't listening to anything the group is trying to say, except to assure the group that you are listening, and to assure that your current draft now agrees with their actually quite different views. They have to read the current draft very, very carefully to discover that your draft isn't really much different from the original in-addr-required draft. > and since you were one of the people objecting, it would be nice to > hear your reaction to those attempts, to the extent that we have not > already collectively determined that a given objection cannot be > accommodated. I suggest you re-read my Feb 18 message. > By way of comment, while I think the discussion in -anderson- of RFC > 1788 is interesting, I have the impression that you are trying to do > something other than what -reverse-mapping- is trying to do. My > understanding is that -reverse-mapping- is trying to discuss the > reverse mapping feature of DNS as it exists and is used today on the > Internet. It is undoubtedly true that there are other and possibly > better mechanisms for achieving the goals that the reverse tree was > originally designed to achieve. The current status of reverse dns should include a report on the currently on-going experimental work in progress regarding reverse DNS. > It is entirely possible that a draft intending to move the service > described in RFC 1788 from experimental to the standards track would > be worthwhile. But that is not the point, in my understanding, of the > work that the WG agreed to when taking on -reverse-mapping-, and I > think that it should be separated as a work item. The question of whether RFC1788 and RFC4620 maturity status' should be reviewed or altered is irrelevant to the fact of their current existance. Of course, one of the effects of any status report is widening knowledge of what is going on. That people react to the document as "oh my, I didn't know that' means that it was helpful and accomplished the purpose of reporting. --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
