(late) comments on draft-kaplan-enum-source-uri-00

Couple of comments on the source-URI draft (sorry for being late):

at first glance, i found this to be an interesting idea (I was blamed to 
appreciate "weird" ideas a couple of times, so that might not be a good 
sign). I definitely understand the use case, and i also understand that 
the authors have intended this for a limited scope in private 
deployments (or, maybe in "trusted" cross carrier environments - did 
anybody say "federation"? :)

However, i have a couple of concerns with this:

- _If_ the nameserver is expected to return different answers depending 
on the contents of the Source-URI field, and those answers have to reach 
the client through the common mechanisms of recursion/caching etc. then 
this will break. The authoritative nameserver might not even receive the 
  option, or a caching server in between might ignore it. In the end, 
the client might receive an answer that is perfectly correct in terms of 
DNS semantics, but does not reflect the "correct" answer depending on 
the Source URI field.

<pessimism>
In other words, unless this is used between an "enlightened" client and 
an "enlightened" server without intermediate DNS elements (and the 
client ignores all caching assumptions), this will break. Since that is 
the case, i wonder why this needs to be standardized anyway, since it 
only works in a very limited subset of scenarios?
</pessimism>

- This has nothing to do with ENUM. The document requests registration 
of an EDNS0 option, which is totally independent (and out of scope) of 
the ENUM WG. It's application to ENUM-DNS-queries (section 5/6) is a use 
case - not more. As the document itself says in the abstract, it 
proposes an "DNS extension", not an "ENUM extension".

- I'm missing a way for the server to indicate that the option has 
actually been processed, so that the client can distinguish an 
"enlightened" response from a standard DNS response. What about copying 
the option into the response, so that the client can figure whether the 
answer depends on the URI?


Ok, if we^Hyou want to move forward, i suggest to do the following:

- Split the documents into the Option registration, and the ENUM use 
case. Keep the Option registration neutral, and describe it's use for 
ENUM in the use case document. Don't bother the ENUM wg with the option 
registration.

(RFC 2929 mandates only a "specification" for EDNS0 options, so i think 
even a draft would be enough for registration)

- Add extensive text about limited applicability of this option. 
Essentially, you can't trust it to be processed unless you control the 
whole chain.

- Provide a mechanism to indicate in the response whether the option has 
been processed.

- The security considerations section is  err... lacking. It should at 
least say that info in the option can't be trusted unless some trust 
relation along the whole chain is in place.

hope that helps,

Alex