Hi Dean, On Tue, Mar 06, 2007 at 11:08:50AM -0500, Dean Anderson wrote:
> The draft can be found in the meantime at > > http://www.av8.net/IETF-watch/Drafts/draft-anderson-reverse-dns-status-00.txt Thanks for the contribution to the discussion. I have read this draft, and I have some questions, and a comment. > draft. Particular attention should be paid to Sections 3.1, 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. Do you mean to suggest that what is missing from the -02 reverse-mapping draft is the discussion of RFC 1788? If so, please see my comment later. > 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. 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. 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. > 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. > 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? 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. 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; 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. 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. 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. Best regards, Andrew -- 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 [email protected] https://www1.ietf.org/mailman/listinfo/dnsop
