Re: Send-n, rat holes and real issues

"Jay Daley" <[email protected]>
Newsgroups gmane.ietf.enum
Message-ID <OFD555DBAD.B9D808B0-ON8025747B.0030C020-8025747B.003204A7@nominet.org.uk>
Brian

> I claim this should be about determining the length of numbers, and not 
a
> solution to overlapped dialing. [rest snipped]

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.

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.


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.

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. 

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.

However it is still completely orthogonal to send-n.

Jay
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.