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

[Lawrence Conroy <lconroy at insensate.co.uk>]

Hi Jay, Brian, folks,
  must resist - nope - I can't. This one has finally reached my  
threshold.
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).

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.

Re. your earlier comment on it not being possible in user ENUM - this  
is not
a technical/protocol argument. Your nation state may have chosen to  
require
each entry anywhere in the tree to be under the control of a  
subscriber OR
NOT BE THERE AT ALL, but that is only one choice. Other nation states/ 
regions
may allow (or even require) carrier control over nodes in the tree, or  
the
NRA may retain control over them, or give up entirely on DNS as a bad  
job
(e.g. USA/North America).

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.

all the best,
   Lawrence

On 9 Apr 2008, at 23:13, Jay Daley wrote:
> Brian
>
>> You are missing the point.
>>
>> The number of digits need to route the call to the correct domain is
>> determined by a more static database which is not subject to public  
>> enum
>> implementations.
>
> No I'm not missing the point - it the incorrect assumption in what  
> you are
> saying above that I am disagreeing with.  The number of digits  
> needed to
> route a call is not determined by an independent static database, it  
> is
> determined by the numbers provisioned in the ENUM trees, which in turn
> creates the structure of that tree.  This draft is a way of describing
> that structure.
>
>> Once you get to the domain, there is more routing to do.  I would  
>> prefer
>> that the domain handle that directly.  That is, after all, how SIP
> works.
>> We route to the domain using one set of mechanisms.  Then the domain
> uses
>> another set of mechanisms to route to the device.
>>
>> Right now, route to the device with variable length TNs is .001% of  
>> the
>> problem.  The other 99.999% is route to the domain.  I think a simple
>> solution to that would be great.  I don't think that is an ENUM
> solution.
>
> I have no objection to anyone working on that further routing.  But  
> nobody
> in their right mind who runs a user ENUM tree (or other ENUM tree)  
> would
> run a SIP server that just deals with that further routing and then  
> add a
> NAPTR for that SIP server at every non-terminal point in their ENUM  
> tree,
> if they could use send-n instead.
>
> Jay
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www.ietf.org/mailman/listinfo/enum

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