Re: Send-n, rat holes and real issues

> 
> Apologies in advance if this comes across as rude, I don't mean it to.
> 
> You've presented this view several times now and on at least a couple of
> those occasions a reply has been given explaining why your view is about
> something quite different from send-n, except in one edge case. Yet it
> doesn't appear that you have addressed that response.  So I'm going to
> have one more go at explaining this and I would really appreciate you
> responding to this rather than restating your view.
Actually, my view is you guys are duplicating the PSTN for a subclass of a
general problem, and you won't look beyond the copy of the existing solution
in a whole new world.  Our experience in the IETF is that nearly every time
we emulate the PSTN, we come to regret it.  When we look at the PROBLEM and
then design a good Internet solution to that problem, we are better off. 

You have a problem: how do you know how long a number is.  I think it's a
real problem.  You have a solution, which is "emulate the PSTN".  I think
that's a poor solution to a real problem. 


> 
> 1.  There are a number of different types of ENUM tree out there in use.
> They include:
> 
> a) National full number trees, fully populated (or almost) according to a
> national numbering plan
> b) National user trees, scarcely populated with no algorithmic or other
> descriptive means of saying what numbers are in the tree.
> c) National number portability trees, partially populated.  Again with no
> descriptive means of saying what numbers are in the tree.
> d) Inter-carrier trees, be definition only partially populated and both
> with and without external descriptions of what numbers are in the tree.
> e) Lots of other private trees.
I agree there are lots of ENUM trees out there, some of which are not
complete.

> 
> 
> 2.  The only type of tree from the list above where the type of plan you
> are proposing would obviate the need for send-n is a).  In all the other
> cases, because the tree is not fully populated, only a description of what
> numbers are _actually_ in the tree is of any use.
This is incorrect. 

I claim there is never harm in having the information that comes from the
regulator, regardless of the completeness of the tree.  In the 1% case where
there is variability of number length, the variable data need not be
complete.

I will admit to being concerned about getting the variable data FROM THE
AUTHORITATIVE SOURCE.  Send-n is indirect; the variable data is obtained
from an authoritative source which is then provided to users by the ENUM
operator.  It's fine with me if the variable data comes from, say, the ENUM
operator if someone wants or needs to do that.  That may need the protocol
to accommodate such arrangements.

> 
> 3.  You could of course maintain a separate database for b) and c) with a
> list of all numbers in the tree, using something like the protocol you
> propose, but I am hoping you are not proposing that because the
> duplication of effort, processing overhead and overall complexity would be
> astonishing.
Nope.  The source of the variable data, where it exists, can supply data for
only a subset of a full tree.  

> 
> 4.  I agree totally that we need a the type of protocol that you are
> proposing.  In fact I think it would be very valuable, more so than
> send-n, and I am willing to commit resources to work on it with you if you
> wish.
Great

> 
> However it is still completely orthogonal to send-n.
Why?  If you had the data I propose to get, it solves the send-n problem,
right?  Why would we want two ways to get the same information?

This is the crux of the discussion we are having.  You think send-n is
solving a different problem, rather than a subset of a general problem.  I
think send-n solves a subset (overlapped dialing) of a general problem, and
I want a single solution to the whole problem.