Re: [Enum] FW: I-D ACTION:draft-iab-dns-applications-00.txt

Lawrence,

Thanks for these notes. Your editorial concerns will be fixed in the next revision.

I'm not sure that dns-applications would be the right place to address Google'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 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 credentials 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, although there are also paths where it could turn out not to be useful.

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 query-response semantics of the DNS. Obviously the two protocols are otherwise very different.

I think I do agree that the second bullet in the second set of bullets on page sixteen doesn't capture what we meant here, though instinctively there must be some discouragement of excessive recursion. We'll try to find a more 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 discussed 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 synchronization 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.

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 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" <lconroy@insensate.co.uk> 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 applied
  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 "raised"
  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 "are 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 16, 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 semantics
  was still crystallising (or that they had been through enough pain by that point :)

Send-n as currently written may be in the sights, but it is perfectly possible to design
a "number length" DNS tree that will be very heavily cached and uses the DNS ability
to scale and be information-dense (unlike almost any other protocol, even TLS -- 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 ringtones
in the DNS; I hear much talk of how bad this is, but no-one ever proposed doing 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: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
> On Behalf Of Internet-Drafts@ietf.org
> Sent: Monday, October 18, 2010 2:45 PM
> To: i-d-announce@ietf.org
> Cc: iab@iab.org
> 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 Group
> 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
> enum@ietf.org
> https://www.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
enum@ietf.org
https://www.ietf.org/mailman/listinfo/enum