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: [email protected] [mailto:[email protected]] On Behalf
>  Of Jay Daley
>  Sent: Wednesday, April 09, 2008 7:02 PM
>  To: Lawrence Conroy
>  Cc: [email protected]
>  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
>  [email protected]
>  https://www.ietf.org/mailman/listinfo/enum