Re: [Enum] Overlap dialing user experience (Re: I-D Action: New draft - draft-bellis-enum-send-n-00)

[Jay Daley <jay at nominet.org.uk>]

Lawrence

> Jay - I know that you ARE aware of Ofcom's number plan docs. These have
> absolutely F. all to do with ENUM, or LDAP, or any other implementation.
> They are a representation of the national number plan in the UK, and 
> they
> DO give the digit length for each block. From this can be derived:
> (i) the set of general prefix-dependent number length rules, AND
> (ii) the number of digits needed to determine the route for calls to
>       numbers in any of these blocks.
> [NB - (i) and (ii) ARE NOT THE SAME].
> Looks pretty static to me (qua Ofcom-anointed number plan changes).

Neither of those are the ENUM tree!!  There is an idealised state of the 
ENUM tree if is populated with every number in the national number plan 
but that is not going to happen.

The send-n proposal is about describing the ACTUAL structure not the 
idealised structure.  That is not static and not derivable from either (i) 
or (ii) above.

> Given that ENUM-like schemes are partitioned on a digit-by-digit 
> basis, one
> can reflect these digit length (and routing determination length) 
> values in
> DNS. Of course this is not kosher in ENUM, as these records will not 
> be at
> leaf nodes in the tree, and ENUM is for fully qualified E.164 numbers 
> ONLY.

Is that by dogma or design?

> It seems to me perfectly reasonable to consider other means of 
> publishing
> or disseminating this (meta-)data. DNS is not necessary, particularly 
> with
> such bizarre data models as seem to be proposed by NICC.

I agree entirely that we need a better, standardised way of representing 
(i) and (ii) above.  Some companies even make a living on creating such 
tables for their customers.  But that is entirely orthogonal to send-n.

Jay
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum