Re: [DNSOP] I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-03.txt
Moin! As pointed out several times throughout the draft DNSSEC deployment would make reverse mappings more reliable. So wouldn't it be a good idea to put a paragraph in the draft to encourage LIRs and providers to sign there reverse zones? Key management for reverse zone probably isn't as political as for the root zone, and AFAIK RIPE already does this. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: [EMAIL PROTECTED] http://www.colt.net/ Data | Voice | Managed Services * COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 * Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-03.txt
On Tue, Jun 05, 2007 at 10:28:23AM +0200, Ralf Weber wrote: Moin! As pointed out several times throughout the draft DNSSEC deployment would make reverse mappings more reliable. So wouldn't it be a good idea to put a paragraph in the draft to encourage LIRs and providers to sign there reverse zones? Key management for reverse zone probably isn't as political as for the root zone, and AFAIK RIPE already does this. Would adding a note in the Security Considerations section to the following effect address this issue for you: To the extent that the DNS Security Extensions make DNS results more reliable, deployment of the DNS Security Extensions in the reverse tree will also make the reverse mappings more reliable ? A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, 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
Re: [DNSOP] Proposed text for reverse-mapping-considerations draft
Hi Dean, On Mon, Jun 04, 2007 at 07:22:08PM -0400, Dean Anderson wrote: but if others disagree with me, I will cheerfully include your suggestions. It seems others disagree. On the point in question, I have received not a single indication of agreement with your proposed text. Until I do, I consider this topic (and, therefore, this thread) closed. I'm a little concerned about some of the rest of the claims you make, however, so I want to reply to them below. I don't think a great deal of to and fro on what appear to be mostly irrelevant topics serve the working group, so you may consider this my last posting on this topic unless someone comes up with some suggested changes to the text. Your failure to address concerns is up to you. Obviously, the draft CAN be modified to address my concerns: Indeed, I wrote that modification in draft-anderson-reverse-dns-status. I believe you suggested that your draft should be considered entirely alternate text. That is not a modification of the text, it is a wholesale replacement; and a replacement that engages (as I already noted in my comments to you) a somewhat different set of topics than the reverse-mapping-considerations draft. That makes me believe that your real claim is simply that the existing text is entirely wrong, which entails that it cannot be repaired and has to be replaced. Therefore, you are not engaged with _this_ text, but with some other one. based on extended and repeated experiences, that your goal is to mislead people about specific uses of reverse DNS, while simultaneously trying to convince critics of the draft that their concerns have been addressed and that discredited claims have been removed. To be clear: that is not my goal. I'm also not entirely sure what motivation has to do with the result, which is supposed to be a text that stands on its own. If I didn't know better, I would imagine you to be attempting to impugn my character instead of addressing the text. Again and again the presence of discredited claims has been shown; and again and again you make trivial, gratuitous changes and report all fixed!. I do not believe the changes to the draft that have been made in the last year (I was only appointed to help edit this draft in July 2006, I think the archive will show) have been trivial or gratuitous; I believe the changes in fact alter the meaning of the draft. They may not completely alter the draft to say what everybody (you, for instance) wants, but that is not the same thing as the changes being trivial or gratuitous. I (and others) have just said that claims of improved trust You have repeated this charge several times, and I keep pointing out that the draft does not in fact anywhere make the claims you seem to be saying it does. Your continued insistence on this point makes me very suspicious of any claim you might make to have read and understood the actual text. It is hard to take seriously objections that appear to be based on mis- or non-reading of the text. The group has repeatedly rejected the claims in the draft that you just edited once it is detailed how the draft supports discredited claims. I am not sure what your evidence is for this claim (especially since we have seen precisely one response so far to the -03 draft, and a number of responses this year suggesting broad agreement with the -02 draft). If you wish to press that claim, I would urge you to point me to the mailing list messages that support your view. discredited claims you keep trying to work in [while simultaneously, these last few years anyway, saying you aren't]. The remark in brackets there makes me suspect you have me confused with someone else. I think it is probably worth making the discussion a little less personal, so I actually don't care who you think I am. But it doesn't serve anyone to muddle the discussion with claims about what I have been doing for the last few years in respect of this draft. You would fail the MIT freshman advanced placement essay, which tests incoming students for their ability to summarize 8 articles and report the important points in the articles without attempting to persuade anyone of a point of view. I am pleased to congratulate you on your appointment to the entry and placement committee at MIT! Best regards, Andrew -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, 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
[DNSOP] draft-ietf-dnsop-respsize-07
Dear colleagues, It has taken me longer than I expected, but I have reviewed draft-ietf-dnsop-respsize-07. I note that in section 2.2.3, we have this: A zone's name servers should be reachable by all IP transport protocols (e.g., IPv4 and IPv6) in common use. I have read differing opinions on whether it is better to have protocol-dedicated servers (on the grounds that it makes troubleshooting in a world of poorly implemented dual stacks easier) or to have all-protocol name servers. I think therefore that the reasoning for the above claim should be spelled out in more detail. Other than that, I think this is a good and useful draft, and should be advanced. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, 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
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
[EMAIL PROTECTED] (Thierry Moreau) writes: This question is serious, to the extent that the DNSOP activities are worth the effort devoted to it by participants. So let me re-prhase the question (actually the question had two facets): Is this proposed wg activity open (i.e. The IETF has basic requirements for open and fair participation and for thorough consideration of technical alternatives. from RFC2418 section 3)? Is this proposed wg activity already limited by the message archived at http://www1.ietf.org/mail-archive/web/dnsop/current/msg05460.html ? i'm not a wgchair or anything, so this is just my opinion. anyone who is going to submit proposals for dns technology should not include encumbered IPR. if i can't implement an RFC in BSDL F/OSS, then it's a bad RFC. if folks can't fetch, compile, build, install, derive from, and make money from the BSDL F/OSS that results from implementing an RFC, then it's a bad RFC. if i see a bad I-D then i will object to it becoming a bad RFC. i think this means that the answer to t-m's questions amount to no even though asullivan's answer (it depends) is probably more accurate. t-m has in the past said that he wants IETF to standardize encumbered IPR so that he can make money from license fees paid by people who deploy it. i think that's offensive screwheadedness and i am opposed to it. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
Paul Vixie (vixie) writes: though asullivan's answer (it depends) is probably more accurate. t-m has in the past said that he wants IETF to standardize encumbered IPR so that he can make money from license fees paid by people who deploy it. i think that's offensive screwheadedness and i am opposed to it. Nah, they'll just go the way of other encumbered RFCs: they'll be labelled as such, ignored, worked around, and something better will be designed and standardized upon. Waste of IETF resources and time though. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Proposed text for reverse-mapping-considerations draft
I urge people to support my draft (draft-anderson-reverse-dns-status). My draft encourages Reverse DNS, improves understanding of Reverse DNS, informs about discredited practices, and recommends good practices. My draft accomplishes the purpose charted by the WG much better than the Sullivan draft and doesn't have any of the drawbacks of Sullivan's draft. Inline On Tue, 5 Jun 2007, Andrew Sullivan wrote: I believe you suggested that your draft should be considered entirely alternate text. That is not a modification of the text, it is a wholesale replacement; and a replacement that engages (as I already noted in my comments to you) a somewhat different set of topics than the reverse-mapping-considerations draft. I (Anderson) copied some text from Sullivan's draft, and rewrote those parts that were wrong, and I included some information about Reverse DNS that was informative. So my draft really just has an entirely different editor. My draft engages in the topic that the working group decided to work on: Encouraging Reverse DNS. I agree Sullivan's draft has a slightly different set of topics that deviates from the topic of Encouraging DNS IN-ADDR as charted by the WG. based on extended and repeated experiences, that your goal is to mislead people about specific uses of reverse DNS, while simultaneously trying to convince critics of the draft that their concerns have been addressed and that discredited claims have been removed. To be clear: that is not my goal. That leaves a lack of writing skills as the cause of the problems. But there is a element of willfulness over the repeated experiences that can't be entirely ignored. But I do agree we are not here to teach writing skills; Just to diagnose the problem that prevents effective writing of the draft and correct that problem. Once we conclude there is a problem, we don't need to further investigate the root causes of the problem. I'm also not entirely sure what motivation has to do with the result, which is supposed to be a text that stands on its own. If I didn't know better, I would imagine you to be attempting to impugn my character instead of addressing the text. I'm disputing Sullivan's abilities and disposition to correctly report facts, statements, and opinions of others. Those abilities are relevant and requisite skills for the task of editing this draft. The group has repeatedly rejected the claims in the draft that you just edited once it is detailed how the draft supports discredited claims. I am not sure what your evidence is for this claim (especially since we have seen precisely one response so far to the -03 draft, and a number of responses this year suggesting broad agreement with the -02 draft). If you wish to press that claim, I would urge you to point me to the mailing list messages that support your view. I think Mr. Sullivan well knows the history of this draft from its previous incarnation as the draft-ietf-dnsop-inaddr-required, and Sullivan knows that the version number was reset when the draft was renamed and re-submitted under the new name. Sullivan knows that the name was changed to address concerns about the implication of the name, even after explicit calls to 'require in-addr' were supposedly removed from the draft. Sullivan knows that the WG didn't support that the notion that inaddr was required, nor did it support any other discredited notions. So Mr. Sullivan knows the past claims that were very explicitly rejected. This is yet another example of a failure to report accurately. Indeed, The history of the in-addr draft dates back to 2000: Robert Elz stated it best (7 years ago and still relevant): 8/13/2000 http://www1.ietf.org/mail-archive/web/dnsop/current/msg00544.html Sorry people, this draft is a total waste of time. I'm an absolute supporter of properly running in-addr.arpa domains, and if someone wanted to write an RFC to explain to people what they're useful for, and why the data needs to be maintained, that would be fine. For 7 years, we've had the same argument, as advocates try to mislead people about the contents of the draft, and people (such as myself, Elz, and a host of others) have picked up each new draft to find essentially the same set of discredited claims. So, I finally wrote a draft that says the right things. BTW, these same 'broad statements of support' for the purposes of Sullivan's draft, (similar to Elz's quoted above) can also be considered to support the statements in my draft as well: People support status and encouragement of Reverse DNS. People don't support the claims that either depend on false assumptions, discredited practices, or require in-addr.arpa. Indeed, a serious problem is that people don't understand that they have been misled about the contents of Sullivan's draft; instead people, (rather like Elz in 2000, support honest information; to the extent they have been misled, people think Sullivan et al
