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

Hi Olafur,
Inline...

> -----Original Message-----
> From: Ólafur Guðmundsson [mailto:[email protected]]
> Sent: Monday, December 17, 2007 10:40 AM
> To: [email protected]
> Subject: Re: [Enum] 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.

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.


> 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.

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.


> 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

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


> 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.

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


> 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.

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.


> 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.

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