Re: New I-D:draft-kaplan-enum-source-uri-00.txt

On Tue, Dec 11, 2007 at 08:45:53PM -0500, Richard Shockey wrote:

> That said the larger issue is this document a ENUM WG or an DNSEXT document.

on a more abstract level this is the counterpart to the NSID EDNS option
that now would enable the client to identify itself.  The extension is that
the server would be allowed to change the response based on this identity.
First, this would be a massive paradigm shift (I know that "views" and
src-addr based "tricks" exist, but they live ouside the architecture),
which should, if at all, be discussed in the main WG responsible for protocol
maintenance.

Second, this "identity" transported by EDNS is hop-by-hop, where what is
obviously intended here is end-to-end. Intermediates cannot be expected
to either transparently transmit or unpack and repack this option code.

This addition to (QNAME,QTYPE,QCLASS) also does not seem to interact too
well with DNSSEC.

>  The ENUM client MUST NOT cache responses for such queries, and 
>  instead MUST treat the TTL value as zero.  Otherwise the local cache 
>  would be used for subsequent queries, even if the originating info 
>  changed, which would lead to false results.  Clearly this could be 

This, albeit an obvious restriction, would have negative side effects.

And apart from the privacy issues raised by others,

>  There are no specific security issues for this mechanism, beyond 
>  those already applicable to DNS and ENUM.  

also would need to discuss how the "URI" (or in general: the option payload)
would be authenticated and/or authorized and what the security model behind
the different "views" is.

It appears to me that not only are the saddlebags about to kill the
animal <http://www3.ietf.org/proceedings/00dec/slides/PLENARY-3/index.html>,
but in fact adding more protocol elements to ENUM (or DNS, for that matter)
only for use in "private infrastructure ENUM" scenarios urgently suggests
to revisit the applicability of the underlying infrastructure for this
use case.  Maybe it's time to replace the "ENUM" in "Infrastructure ENUM"
with another term.

-Peter