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