Re: Send-n, rat holes and real issues

I claim this should be about determining the length of numbers, and not a
solution to overlapped dialing. The length of the number 99% of the time is
totally a function of a regulator.  The other 1% of the time, the regulator
allocates a prefix, and a carrier, or in some cases an enterprise,
determines the length of the suffix.  We need a solution for that 1%, but
it's 1% and the 1% probably ought to not be the tail wagging the dog.

While I understand that this draft proposes a way for someone to get a
number length out of an ENUM tree, I propose that we solve the general
problem, which I believe is an acceptable solution applicable to the
overlapped dialing problem.  I'm not fussy about what the solution look
like, although I want it to be useful to the entity creating an ENUM tree as
well as an entity using ENUM.

Brian

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Jay Daley
> Sent: Wednesday, July 02, 2008 5:39 PM
> To: [email protected]
> Subject: [Enum] Send-n, rat holes and real issues
> 
> It appears to me that this discussion is actually getting somewhere
> sensible.  The following rat holes appear to have been exposed as bogus:
> 
> 1.  This is not /just/ about a fully populated tree for a national number
> space.  If you take a different example, like a tree of only ported
> numbers, or a private tree shared by a group of carriers then it does not
> matter what the regulator knows.
> 
> In those cases the shape of the tree is determined by the data that is put
> in it and _solely_ by the data put in it, so no outside data
> representation is of any use.  Protocols that describe the dial plan or
> numbering plan are orthogonal to this draft.
> 
> 2.  The views of some people that overlapped dialling should not be used
> cannot be tackled by this draft.  It exists, it is used and that is that.
> 
> 3.  According to all the DNS experts the treatment of wildcards is not an
> issue.
> 
> 
> 
> So that leaves us with the following real issues that are actually worth
> discussing.  The first two are more about DNS:
> 
> a. Whether or not we need a more general mechanism to describe the shape
> of the tree rather than the something just for ENUM?  Also expressed as
> whether there should be meta-data in the tree about the tree (and whether
> NAPTR is a good way to do that)?
> 
> b. What is the trust/security implication from one label in the tree
> making a statement about later labels in the tree even though they might
> be under different administrative control?
> 
> 
> and the second two are specifically about send-n:
> 
> c. Is the relative form of send-n worth the trouble?
> 
> d. Is the trade off between extra records vs reduced lookups worth it?
> 
> 
> Any more real issues?
> 
> Jay
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum