Re: FW: I-D ACTION:draft-iab-dns-applications-00.txt
"Peterson, Jon" <[email protected]> Wed, 20 Oct 2010 10:43:43 -0400
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <C8E4785F.46C0D%[email protected]> |
--===============1607388394== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C8E4785F46C0Djonpetersonneustarbiz_" --_000_C8E4785F46C0Djonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lawrence, Thanks for these notes. Your editorial concerns will be fixed in the next r= evision. I'm not sure that dns-applications would be the right place to address Goog= le's pubic resolver, as the scope of this document is really the interplay = of applications and the DNS, and at least off the top of my head I don't se= e how the Google resolver is salient to that. In much the same way that iab= -dns-applications does not rule out DKIM's use of credentials in the DNS, i= nitially I don't think it should rule out the keyassure work either, which = in my opinion could turn out to be useful, although there are also paths wh= ere it could turn out not to be useful. The draft certainly does not suggest that HTTP and DNS are the same - merel= y that HTTP (or really any query-response protocol) can emulate the query-r= esponse semantics of the DNS. Obviously the two protocols are otherwise ver= y different. I think I do agree that the second bullet in the second set of bullets on p= age sixteen doesn't capture what we meant here, though instinctively there = must be some discouragement of excessive recursion. We'll try to find a mor= e exact way of stating that which doesn't seem to ban CNAME. We do want to = preserve concerns about redirecting between names in the DNS without DNSSEC= , though. While there are alternative technical solutions to many of the practices di= scussed in dns-applications, the issue the draft raises with send-n is its = "predictive" quality, the practice where one node in a tree tells resolvers= about the the state of nodes down the tree and the resulting synchronizati= on issues. Perhaps there are ways to approach send-n in the DNS that don't = exhibit this quality, but perhaps there are ways to do it outside of the DN= S entirely which require a lot less imagination. The draft doesn't attribute the story of ringtones in the DNS to any partic= ular source, and perhaps it is apocryphal, but that doesn't exempt it from = serving as an illustrative example of excessive data in the DNS. Jon Peterson NeuStar, Inc. On 10/18/10 6:20 PM, "Lawrence Conroy" <[email protected]> wrote: Hi Richard, folks, ... and you're surprised, given the authorship ?)p This is a good document, it is needed, and I don't read it that states that= ENUM is a bad idea. Seriously, this had to be shipped today as it's a -00 draft, so it has some= rough edges. My initial notes on the draft are: - In 3.1, the end of the second sentence on page 8 "needs work". - The second sentence of section 3.3 on page 9 also needs work; 1464 applie= d the TXT record that was defined in 1035 for use for arbitrary data. 1464 = did NOT define the TXT record. - The last sentence in 4.1.1 on page 12 has "like" when I'd expect "likely"= . - The first sentence of 4.2 uses "surfaced" in a slightly odd way; maybe "r= aised" or "exposed"? - in section 4.2 on first paragraph of page 13, void should be replaced by = unused. (draft-ietf-enum-void is ancient; the last one was draft-ietf-enum-unused= -04.txt). - The second sentence of the second paragraph of 4.4 on page 14 starts with= a typo -- should be "In". - being picky, the second "bullet" of section 5 on page 16 could replace "a= re only depended on" with "only depend". - missing closing parentheses missing in third sentence of first paragraph = on page 18. ---- I await with interest the IAB's comments on the Google resolver proposals (= perhaps on page 12) and also on the keyassure work (apparently on page 17, if I decode= it correctly) -- after all, Phil *might* (eventually) get carpal if he's the only one to = fight those evil people. There are places where the authors' dry sense of humour made me laugh: - http (or TLS) is the same as DNS -- on page 17, second paragraph, - by implication, CNAME considered a bad sign (there, and earlier on page 1= 6, second "bullet" of the second set of items on page 16), - the thought that DKIM did NOT chose to use TXT records partially because = it was infeasible at the time to get an RR type while as the DKIM syntax and sem= antics was still crystallising (or that they had been through enough pain by tha= t point :) Send-n as currently written may be in the sights, but it is perfectly possi= ble to design a "number length" DNS tree that will be very heavily cached and uses the DN= S ability to scale and be information-dense (unlike almost any other protocol, even T= LS -- ha!). Whether that would use NAPTRs or just plain TXT records (like everyone else= ) is an entirely different question. It would avoid any need for standardisation in= the IETF, which may be the point. Finally, I really would like to find the bogey man who thought of putting r= ingtones in the DNS; I hear much talk of how bad this is, but no-one ever proposed d= oing such a perverse thing, AFAICT. all the best, Lawrence On 18 Oct 2010, at 21:57, Richard Shockey wrote: > > I'm reading this as the "ENUM is considered harmful to the DNS" or don't > even think about E2MD > > -----Original Message----- > From: [email protected] [mailto:[email protected]= ] > On Behalf Of [email protected] > Sent: Monday, October 18, 2010 2:45 PM > To: [email protected] > Cc: [email protected] > Subject: I-D ACTION:draft-iab-dns-applications-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Internet Architecture Board Working Grou= p > of the IETF. > > Title : Architectural Considerations on Application > Features in the DNS > Author(s) : O. Kolkman, J. Peterson, H. Tschofenig, B. Aboba > Filename : draft-iab-dns-applications-00.txt > Pages : 23 > Date : 2010-10-18 > > While the principal purpose of the Domain Name System (DNS) is to > translate Internet domain names to IP addresses, over time a number > of Internet applications have integrated supplemental features into > the DNS to support their operations. Many of these features assist > in locating the appropriate service in a domain, or in transforming > intermediary identifiers into names that the DNS can process. > Proposals to piggyback more sophisticated application behavior on top > of the DNS, however, have raised questions about the propriety of > instantiating some features in the DNS, especially those with > security sensitivities. This document explores the architectural > consequences of installing application features in the DNS, and > provides guidance for future work in this area. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ > enum mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list [email protected] https://www.ietf.org/mailman/listinfo/enum --_000_C8E4785F46C0Djonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [Enum] FW: I-D ACTION:draft-iab-dns-applications-00.txt</TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'><BR> Lawrence,<BR> <BR> Thanks for these notes. Your editorial concerns will be fixed in the next r= evision.<BR> <BR> I’m not sure that dns-applications would be the right place to addres= s Google’s pubic resolver, as the scope of this document is really th= e interplay of applications and the DNS, and at least off the top of my hea= d I don’t see how the Google resolver is salient to that. In much the= same way that iab-dns-applications does not rule out DKIM’s use of c= redentials in the DNS, initially I don’t think it should rule out the= keyassure work either, which in my opinion could turn out to be useful, al= though there are also paths where it could turn out not to be useful.<BR> <BR> The draft certainly does not suggest that HTTP and DNS are the same –= merely that HTTP (or really any query-response protocol) can emulate the q= uery-response semantics of the DNS. Obviously the two protocols are otherwi= se very different.<BR> <BR> I think I do agree that the second bullet in the second set of bullets on p= age sixteen doesn’t capture what we meant here, though instinctively = there must be some discouragement of excessive recursion. We’ll try t= o find a more exact way of stating that which doesn’t seem to ban CNA= ME. We do want to preserve concerns about redirecting between names in the = DNS without DNSSEC, though.<BR> <BR> While there are alternative technical solutions to many of the practices di= scussed in dns-applications, the issue the draft raises with send-n is its = “predictive” quality, the practice where one node in a tree tel= ls resolvers about the the state of nodes down the tree and the resulting s= ynchronization issues. Perhaps there are ways to approach send-n in the DNS= that don’t exhibit this quality, but perhaps there are ways to do it= outside of the DNS entirely which require a lot less imagination.<BR> <BR> The draft doesn’t attribute the story of ringtones in the DNS to any = particular source, and perhaps it is apocryphal, but that doesn’t exe= mpt it from serving as an illustrative example of excessive data in the DNS= .<BR> <BR> Jon Peterson<BR> NeuStar, Inc.<BR> <BR> <BR> On 10/18/10 6:20 PM, "Lawrence Conroy" <<a href=3D"lconroy@ins= ensate.co.uk">[email protected]</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>Hi Richard, folks,<BR> ... and you're surprised, given the authorship ?)p<BR> <BR> This is a good document, it is needed, and I don't read it that states that= ENUM<BR> is a bad idea.<BR> <BR> Seriously, this had to be shipped today as it's a -00 draft, so it has some= rough edges.<BR> <BR> My initial notes on the draft are:<BR> <BR> - In 3.1, the end of the second sentence on page 8 "needs work".<= BR> <BR> - The second sentence of section 3.3 on page 9 also needs work; 1464 applie= d<BR> the TXT record that was defined in 1035 for use for arbitrary d= ata. 1464 did<BR> NOT define the TXT record.<BR> <BR> - The last sentence in 4.1.1 on page 12 has "like" when I'd expec= t "likely".<BR> <BR> - The first sentence of 4.2 uses "surfaced" in a slightly odd way= ; maybe "raised"<BR> or "exposed"?<BR> <BR> - in section 4.2 on first paragraph of page 13, void should be replaced by = unused.<BR> (draft-ietf-enum-void is ancient; the last one was draft-ietf-e= num-unused-04.txt).<BR> <BR> - The second sentence of the second paragraph of 4.4 on page 14 starts with= a typo<BR> -- should be "In".<BR> <BR> - being picky, the second "bullet" of section 5 on page 16 could = replace "are only<BR> depended on" with "only depend".<BR> <BR> - missing closing parentheses missing in third sentence of first paragraph = on page 18.<BR> <BR> ----<BR> <BR> I await with interest the IAB's comments on the Google resolver proposals (= perhaps on<BR> page 12) and also on the keyassure work (apparently on page 17, if I decode= it correctly)<BR> -- after all, Phil *might* (eventually) get carpal if he's the only one to = fight those<BR> evil people.<BR> <BR> There are places where the authors' dry sense of humour made me laugh:<BR> <BR> - http (or TLS) is the same as DNS -- on page 17, second paragraph,<BR> <BR> - by implication, CNAME considered a bad sign (there, and earlier on page 1= 6, second<BR> "bullet" of the second set of items on page 16),<BR> <BR> - the thought that DKIM did NOT chose to use TXT records partially because = it was<BR> infeasible at the time to get an RR type while as the DKIM synt= ax and semantics<BR> was still crystallising (or that they had been through enough p= ain by that point :)<BR> <BR> Send-n as currently written may be in the sights, but it is perfectly possi= ble to design<BR> a "number length" DNS tree that will be very heavily cached and u= ses the DNS ability<BR> to scale and be information-dense (unlike almost any other protocol, even T= LS -- ha!).<BR> Whether that would use NAPTRs or just plain TXT records (like everyone else= ) is an<BR> entirely different question. It would avoid any need for standardisation in= the IETF,<BR> which may be the point.<BR> <BR> Finally, I really would like to find the bogey man who thought of putting r= ingtones<BR> in the DNS; I hear much talk of how bad this is, but no-one ever proposed d= oing such<BR> a perverse thing, AFAICT.<BR> <BR> all the best,<BR> Lawrence<BR> <BR> <BR> On 18 Oct 2010, at 21:57, Richard Shockey wrote:<BR> <BR> ><BR> > I'm reading this as the "ENUM is considered harmful to the DNS&qu= ot; or don't<BR> > even think about E2MD<BR> ><BR> > -----Original Message-----<BR> > From: <a href=3D"[email protected]">i-d-announce-bounces@i= etf.org</a> [<a href=3D"mailto:[email protected]">mailto:i-d-an= [email protected]</a>]<BR> > On Behalf Of <a href=3D"[email protected]">Internet-Drafts@ietf= .org</a><BR> > Sent: Monday, October 18, 2010 2:45 PM<BR> > To: <a href=3D"[email protected]">[email protected]</a><BR> > Cc: <a href=3D"[email protected]">[email protected]</a><BR> > Subject: I-D ACTION:draft-iab-dns-applications-00.txt<BR> ><BR> > A New Internet-Draft is available from the on-line Internet-Drafts<BR> > directories.<BR> > This draft is a work item of the Internet Architecture Board Working G= roup<BR> > of the IETF.<BR> ><BR> > Title &nbs= p; : Architectural Considerations on Applicati= on<BR> > Features in the DNS<BR> > Author(s) = : O. Kolkman, J. Peterson, H. Tschofenig, B. Aboba<BR> > Filename &= nbsp; : draft-iab-dns-applications-00.txt<BR> > Pages &nbs= p; : 23<BR> > Date  = ; : 2010-10-18<BR> > <BR> > While the principal purpose of the Domain Name System (DNS) is to<BR> > translate Internet domain names to IP addresses, over time= a number<BR> > of Internet applications have integrated supplemental feat= ures into<BR> > the DNS to support their operations. Many of these f= eatures assist<BR> > in locating the appropriate service in a domain, or in tra= nsforming<BR> > intermediary identifiers into names that the DNS can proce= ss.<BR> > Proposals to piggyback more sophisticated application beha= vior on top<BR> > of the DNS, however, have raised questions about the propr= iety of<BR> > instantiating some features in the DNS, especially those w= ith<BR> > security sensitivities. This document explores the a= rchitectural<BR> > consequences of installing application features in the DNS= , and<BR> > provides guidance for future work in this area.<BR> ><BR> ><BR> > A URL for this Internet-Draft is:<BR> > <a href=3D"http://www.ietf.org/internet-drafts/draft-iab-dns-applicati= ons-00.txt">http://www.ietf.org/internet-drafts/draft-iab-dns-applications-= 00.txt</a><BR> ><BR> > Internet-Drafts are also available by anonymous FTP at:<BR> > <a href=3D"ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/int= ernet-drafts/</a><BR> ><BR> > Below is the data which will enable a MIME compliant mail reader<BR> > implementation to automatically retrieve the ASCII version of the<BR> > Internet-Draft.<BR> ><BR> > _______________________________________________<BR> > enum mailing list<BR> > <a href=3D"[email protected]">[email protected]</a><BR> > <a href=3D"https://www.ietf.org/mailman/listinfo/enum">https://www.iet= f.org/mailman/listinfo/enum</a><BR> <BR> _______________________________________________<BR> enum mailing list<BR> <a href=3D"[email protected]">[email protected]</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/enum">https://www.ietf.org= /mailman/listinfo/enum</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C8E4785F46C0Djonpetersonneustarbiz_-- --===============1607388394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ enum mailing list [email protected] https://www.ietf.org/mailman/listinfo/enum --===============1607388394==--