I think it would help a lot of people in this thread if we knew what the subject line meant by 'impending publication'. I and others made numerous objections to draft-04 which were not responded to. That draft expired April 26, 2007. I did not continue the conversation because I believed that the paper had been withdrawn. Why is this document now considered to be ready for publication when the authors are aware that there are outstanding objections? I think that the tone of the paper reflects very badly on the IAB: It is not appropriate to second guess or assume the mental processes of designers. The approach proposed in this paper is neither practical nor scalable for reasons that have been stated in the past, both to you personally and on various mailing lists. I made a counter proposal in the form of an ID which has been discussed repeatedly on DNSEXT that addresses the limitation with wildcards and prefix records. This proposal is not addressed in the draft despite the fact that two IDs have been written proposing this approach: http://quimby.gnus.org/internet-drafts/draft-hallambaker-xptr-00.txt I have the following objection to the proposal in the draft: 1) RRs are a finite resource, the mechanism does not scale. Due to Web services we are likely to be adding several thousand new protocols to the Internet each year. The well known ports approach is not scalable in this respect. That was one of the reasons behind the introduction of SRV and NAPTR. 2) Legacy infrastructure support is a real concern Microsoft have demonstrated that their DNS server source code does not provide production quality support for unknown RR types. Their servers have 50% of the market. These are significant concerns for a protocol designer. Yes, I know that you can inject extension RRs to a Windows DNS server using a script and the DNS server will continue to relay them until it reboots. That is a hack, it is not what any competent Windows sysadmin is going to accept in a production environment. The manufacturer has stated that their product is not capable of use in the stated manner. 3) Wildcard support is not a major concern Wildcard support is not actually a concern for most DNS discovery or policy distribution approaches. The only case where it is in fact an issue is email policy statements where it is actually desirable to make a wildcard statement of the form '*.example.com sends no email'. This requirement does not arise in synchronous protocols where the two parties are simultaneously connected. 4) Wildcard support in legacy DNS is no less unsatisfactory under the proposed approach Introducing a new RR does not in fact address the principle concern that people have with new RRs. 5) An alternate solution that has been proposed is not addressed in the draft The 'choices' draft only examines the proposals that lead towards the authors desired conclusion. the XPTR ID and Domain Centric Administration drafts were both published while this ID was being edited. The approach described provides a simple solution to the problem of constructing a midpoint wildcard '_prefix.*.example.com' This solution can be effected without the need to introduce any new RRs by defining semantics for the PTR RR in the forward DNS (it is currently undefined in forward DNS). For tactical reasons of deployment incentives it is preferable to introduce a new record for this purpose, XPTR. The IAB should not publish this document in its current form. The proposal made does not reflect a good architectural approach. It is unscalable, fails to provide properly abstracted layer separation and fails to take account of the legacy infrastructure. The authors have failed to make any effort to respond to objections raised. It is simply not appropriate for a controversial draft that has been expired for almost a year to be pronounce ready for publication as an RFC with no substantive changes. -----Original Message----- From: Patrik Fältström [mailto:patrik@xxxxxxxxxx] Sent: Tue 04/03/2008 10:35 AM To: Hallam-Baker, Phillip Cc: Stephane Bortzmeyer; Mark Andrews; ietf@xxxxxxxx; iab@xxxxxxx Subject: Re: Impending publication: draft-iab-dns-choices-05 On 4 mar 2008, at 16.32, Hallam-Baker, Phillip wrote: > I also found the tone of the original paper insulting. I don't think > that 'send text' is an acceptable response to such objections. For the specific issue, the lack of correct history of why people did select TXT RR Types my conclusion was that some new added text was needed that described it. For that specific issue, I felt "send text" was the correct response. Patrik _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf