Re: Send-n, rat holes and real issues

Otmar Lendl <[email protected]>
Newsgroups gmane.ietf.enum
Message-ID <[email protected]>
On 2008/07/04 12:07, Duane <[email protected]> wrote:
> Jay Daley wrote:
> 
> > Exactly!!  Which is why we need send-n.
> 
> Just because you need a solution to a problem doesn't mean it must
> replicate what PSTN systems already do that's just crazy.
> 
> Has no one actually got a valid criticism for my suggestion of doing
> this as a routing type protocol rather than this hack job on ENUM?
> 
> Seems most ignored my suggestion completely except for one remark about
> TRIP.

We (including speermint) have been though that discussion already 
a few times. A BGP-like protocol for numbers (or better: prefixes)
just won't scale.

One part of what makes BGP work for IP routing is the aggregation
properties of IP addresses: large blocks are given to ISPs, which give
out smaller blocks to enterprises, or just individual addresses to
end-users.

The rest of the world doesn't care how this ISPs handed out addresses, a
single entry in the global routing table suffices.

It used to be the case that phone numbers worked in a similar fashion:
country codes, block allocation, individual number assignment. Perfect
for prefix-based routing.

Now add one table-spoon of "number portability" to your stew, season
it with "premium rate" and "freephone" numbers and watch your routing
tables explode.

More technically: phone numbers used to be addresses. Now they are
names. It used to be that the equivalent of phone numbers were IP
addresses. This no longer holds. If you really want to compare them to
Internet objects, take domain names.

So, how do *you* like the idea of a BGP like routing protocol for domain names?

/ol
-- 
// Otmar Lendl <[email protected]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
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.