I would like to add my support here to Dave Crocker's very thoughtful and IMHO accurate description of this revised draft. I share his views that the substantive criticisms have not been addressed. What exactly is the harm that this draft proposes to prevent? I can certainly understand the natural reluctance to continue to pile on to the DNS various data attributes but its should be clear that that this cat has been out of the bag for some time. Clearly we do not want the DNS to be used for search like functions where there may be a indeterminate response but the examples cited do not address those issues. I am baffled by the ongoing criticism RFC 6116 and the desire of some members of the community to extend 6116 to values that may not necessarily be defined as a URI. ENUM works and works quite well in both e164.arpa and in private instantiations. Frankly I think this draft needs to be completely withdrawn. If there are issues with new uses of the DNS, DNSEXT or DNSOPS are fully chartered to provide community review and do not need any "fuzzy" guidance on what is and is not acceptable. This entire draft could beeasily simplified byt a one sentence statement. "If you need to do database look ups in the future we would prefer that you think of using protocols other than the DNS." -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Dave CROCKER Sent: Thursday, July 21, 2011 6:41 AM To: IETF Discussion Subject: Review of: draft-ietf-iab-draft-iab-dns-applications-02 This is a summary of a followup review of the draft, after the one noted in Ticket #35 of the trac wiki for this draft: <http://trac.tools.ietf.org/group/iab/trac/ticket/35> The complete version of this second review is at: <http://trac.tools.ietf.org/group/iab/trac/ticket/35#comment:2> Summary: The latest version of the draft contains many substantial changes. However it continues to have basic problems with direction, scope, detail, writing, and with basic confusion about architecture. The draft maintains its claim of being a general considerations discussion when, in fact, it continues to focus on fear of inappropriate proposals. It continues to invoke examples of inappropriate proposals that lack constituency or even currency. In spite of language claiming to distinguish new /uses/ of the DNS from /changes/ to the DNS, the draft continues to confuse the two. The problem appears to be a difficulty distinguishing architectural layers. This is like saying that TCP changes IP or that HTTP changes TCP. Hence, for example, DDDS is a layer /above/ the DNS. The only two interesting questions about a client layer's use of a provider layer -- such as DDDS's use of DNS -- is whether the functional match is acceptable and whether it's performance demands cause problems. When focused on one layer, any further discussion of the other likely to confuse things significantly, as demonstrated in the draft. The paper continues to make broad criticisms that lack foundation and sometimes even lack citation. Some of the statements and logic sequences were entirely opaque to me. I could not decipher what they meant. In some cases the apparent meaning was factually incorrect or confused. From all of this, I suspect that the only way to make useful progress is to start over, and to begin with a much, much more clear and concrete statement of the goal for the draft and then a very diligent effort to organize the paper's sequence and carefully document its assertions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf