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

Chair hat off..

It is worth noting again that this is NOT intended for e164.arpa or probably
any domain within the single root DNS. 

Adding a new protocol for this function would guarantee it would not be
used...ever.

The DNS protocols have been "fiddeled" with so long they are barely
recognizable as it is. I don't see what the problem is.

The issue of identifying where the query is coming from was an issue in my
CNAM draft. Though it did not require identification and authentication it
just as easily could have. The issue in using 3761 for CNAM queries was much
more practical. 

No vendor at this stage of ENUM deployments is ever going to put another
protocol stack in the softswitches or SMB's for this type of number
translation function. In order to deploy a working protocol to deal with a
specific use case like this you deal with the cards your dealt and in this
case again that is 3761.

Obviously people using SIP redirect for number translations don't have this
problem but we all know what the issues with SIP redirect are, for one you
get a 10X performance hit on query-response time.

The first order issue to resolve is,  does this proposal identify a
practical problem in ENUM deployments that needs to get fixed,  and IMHO the
answer to that is unquestionably YES.
 
>  
>  > As this is not for e164.arpa, but private trees instead, do you
>  actually
>  > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM just
>  used
>  > as a simple query protocol into a single database?
>  
>  Both.  The sub-tree model is incredibly useful for scaling in bigger
>  networks or handling federations/registries, and it's also the case
>  that it sometimes is just a simple query protocol to a single DB.
>  
>  -hadriel
>  
>  _______________________________________________
>  enum mailing list
>  [email protected]
>  https://www1.ietf.org/mailman/listinfo/enum