Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 17 Dec 2007 10:39:40 -0500

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

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Dec 2007 18:09:21 -0500

Hi Olafur,
Inline...

> -----Original Message-----
> From: Ólafur Guðmundsson [mailto:[email-masked]]
> Sent: Monday, December 17, 2007 10:40 AM
> To: [email-masked]
> Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
>
>
> First:

Yes, that is essentially correct for these servers - they're private servers used in private/contained environments.  In that sense no it's not really different, or at least not meant to be. :)  That is to say it's not meant to be used in the public space at all, nor for DNS in general.  It's really just a very private use-case - basically proprietary - in fact we wouldn't have bothered documenting it, except we know many vendors want to do this type of thing in private use as well, so we figured it might as well be doc'ed so different vendor private clients can talk to different vendor private servers.

> want to accomplish or what your query sequence looks like.

The query sequence looks just like normal ENUM queries, except the querier happens to insert some opaque data which may or may not help the server filter or determine a better answer.

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

Yeah, you're right should have just said TBD. :(

> if there are any intermediary DNS protocol elements between the client and

Yes, this was intended to be hop-by-hop.

> hard for outsiders like me to judge this one or propose alternatives.

Absolutely:
DNS is being used in private/contained environments as a lightweight database lookup to map telephone numbers to private URI's, Calling Name lookups, and so on - i.e., "private ENUM".  This is very much a private ENUM use, not public ENUM (ie, not "real" DNS - it shares the protocol on the wire, but not the architecture).  The problem is, in order to give back the correct or at least most-specific answers, those private ENUM servers need some additional data from the (private) queriers: source URI data.  It's essentially just opaque text.  If the server doesn't understand it, it can just respond as if it didn't exist, or create an error - either would be fine for resolving their problem I think.

> current status is, it is not going away anytime soon.

No questions about that - it wasn't meant to modify how DNS works.  It was meant as a private-use extension for a specific private use of ENUM.

-hadriel