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

First:
What is an "ENUM server" and what protocol does it speak?

 From the document it sounds like it speaks DNS on the wire but the behavior
is nothing that is supported by DNS.

Second:
+       10.  Example Exchange
+
+   [Do we need an example?]

Yes please because as an DNS person I still have no clue what you
want to accomplish or what your query sequence looks like.

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

This is so wrong I do not want to start, just change it to TDB

Forth:
DNS is a lookup protocol where the data is retrieved by specifying the
"whole Q-Trinity" QNAME, QCLASS, QTYPE
all questions with the same Q-Trinity asked from the same address, to
the same server should give out the same answer while the serial number
of the zone in question stays the same!

As far as I can tell: this document is proposing that some payload in
the DNS query packet,  outside the Query section, selects from different
answers and possibly modifies the answer selected.

Giving out the same answer with different TTL's is plain
wrong depending on ENDS0 payload.

TTL==0 is a BAD IDEA to start with, in particular if there are multiple
parallel query streams going on.

Fifth:
ENDS0 is hop-by-hop mechanism not end-to-end, so this may not work
if there are any intermediary DNS protocol elements between the client and
the authorative server.

I do not see the need for your section 8 in the document it confused me
just site section 4 of RFC2671 in your section 9.
Section 9, mixes the Option header with the option contents.
Please do not propose sub-typing in the option just get different
ENDS option code for each "version".

Sixth:
What is exactly the problem you want to solve?
There might be other solutions and without concrete examples it is
hard for outsiders like me to judge this one or propose alternatives.

Seventh:
<DNSEXT chair-hat>
IFF this working group has a firm proposal that modifies HOW DNS WORKS
that proposal should migrate to DNSEXT for formal processing.
DNSEXT role is still to "defend DNS from bad ideas" no matter what its
current status is, it is not going away anytime soon.

At this point in time, ENUM WG should figure out if modifying DNS is
REQUIRED and proceed from there.

         Olafur