Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00

[Ray.Bellis at nominet.org.uk]

> Chair hat off ..
> 
> Lawrence I generally agree with the thrust of your analysis. I find it 
very
> difficult to support the use of 3761 for digit analysis. 3761 was 
designed
> to query on the full E.164 string not a partial string. We would be 
going
> down a rat hole we do not want to go, especially now.
>
> ENUM is a pure 1 to 1 mapping from fully formed E.164 FQDN to URI's. The
> digit strings must be fully formed in advance before query not during. 
We
> have seen the German arguments etc and have passed on those etc.

Like it or not, for now at least it seems that private ENUM has been 
somewhat more successful than public ENUM.

The specific application for which this was originally designed is the 
UK's number portability database, where a private ENUM tree is used and 
where it is not known in advance to the application whether a complete 
number has been received.  The intent is to avoid excessive dips into that 
database, not least because there may be a (financial) cost associated 
with each dip.

If one does need this data (which NICC believe we do) then it makes 
absolute sense for it to be included in the ENUM tree.  By doing so we 
allow the central portability database to maintain a single protocol 
interface with the Communications Providers that are querying it.  When 
the CP asks for a NAPTR, they either get routing data, or a hint that more 
digits are required *from the same DNS request*.

cheers,

Ray

p.s. if it would make people happier I can quite readily change the 
examples so that they're not in e164.arpa.

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: ray at nominet.org.uk, t: +44 1865 332211
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum