[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Enum] Chair Question...
Well as a purely administrative issue ....
I'm assuming someone wants to present send-n or successor document in
Dublin?
Between this a revised UNUSED and of course, Source URI I'm going to need a
2 hour slot ?
Correct?
Working groups have "long tails" but really ...
> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf
> Of Jay Daley
> Sent: Wednesday, April 09, 2008 7:02 PM
> To: Lawrence Conroy
> Cc: enum at ietf.org
> Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action:
> New draft - draft-bellis-enum-send-n-00)
>
> 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
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum