Confusing Name Space with Address Space and Technical routing issues, and the LAND RUSH of '97.

[Howard C. Berkowitz]

At 1:30 PM -0500 1/28/97, Larry Honig wrote:
>Howdy. Another semi-informed lurker here. Let me address two groups who
>seem to be speaking at cross purposes on this list: the technical "ins",
>who would certainly include people like Michael, Kim, Howard, Jon,
>(don't let my omission be taken as any sort of "diss", folks, but since
>I don't have years of clock time on this issue I obviously don't know
>all of the players), and the technical newbies, who, while not idiots at
>all (and who may be closer to the realities of grubbing for the cash
>which keeps little operations alive than the gurus on the mountain),
>don't seem to grok the essential differences between the registration of
>names and the registration of numbers.
>
>It seems to me that the continued confusion on this point - the need for
>ARIN when there is already a perceived vehicle for registration of names
>- is significant. Lets define a new term: the client/server ratio. At
>present, most users (the AOL-mailbox crowd) have a very HIGH
>client-server ratio; eg., most of their interaction is browsing or
>passive reception of email, and very little originates that gets
>propagated out onto the Web. Let's call the people with a high
>client/server ratio "the public". Now, for symmetry, define the "trade"
>as those entities (who may be individuals, companies or government
>agencies, or whatever) with a LOW client/server ratio. Of course, there
>may be gradations within these groups - the operators of IX points, or
>the participants in peering agreements that swap terabytes of data per
>hour clearly won't have the same interests, capital at risk (or
>available), speed to maneuver, etc., as the mythical "Mom 'n Pop" ISP -
>but both groups, to the public, appear as providers.

You may very well be on to something, although I am still trying to grok
the terminology.  Don't feel bad about that, because we went through a very
similar discussion (on the Big-Internet list if I remember) about some
related ideas in Dave Crocker's http://ds.internic.net/rfc/rfc1775.txt ,
"To Be 'On' the Internet."

See if you can define your terms building on 1775, which reflects some
consensus.
>
>Out of their aggregated self-interest, the public places a higher value
>on certain features of the communications network than does the trade.
>One example is the ease-of-finding a site, by using a name rather than a
>static IP, or even a dynamic IP. Trademark owners know this phenomenon
>well, and the reason that trademark owners spend money suing infringers
>is that their trademarks are truly valuable. The trade, on the other
>hand, is concerned about issues that the public never even hears about -
>unreachable routes, efficiency of routing algorithms, backbone capacity,
>etc.

In a funny way, this may be worth reinforcing.   I'm less thinking of the
issue of the intuitive ease of finding playboy.com, but the need to impress
on end users and newer ISPs the need to use names rather than hard-coded
addresses wherever possible, which MASSIVELY reduces the renumbering
problem.

>
>
>Some interesting questions can be asked. At what point - that is, how
>much does the public's client/server ratio have to shift - will the
>END-USER of communications services desire - or actually *need* -
>published (you could use the routing term "advertised") names,

Actually, I'd avoid "advertised" so it stays unambiguously related to routing.

>in name
>space, in something close to real-time? How quickly will IPv6 - or other
>extended addressing schemes - be practicable, and exactly how - and to
>what - will the addresses be assigned (for example, to every
>electron-passing piece of silicon, at the device level, at the appliance
>level, at some evanescent applications level?)

I wouldn't call that the architecture of V6.  It's much more intended as a
long address where you can do autoconfiguration -- at the very least, there
is a local address part (closest to what you suggest above) plus a
how-to-get-to-it routing part that changes.

Again...v6 is NOT A SHORT TERM SOLUTION to anything we are dealing with.
(Yes, if Jim Bound is listening, I will submit to being chained and
whipped, muttering "but it still moves.")

>How will name space have
>to adapt to the expansion of address space? How will pointer-to-pointer
>services, like LDAP, facilitate this? How will the the regulatory
>process (and ARIN smells to me like a regulatory entity in the making,
>no matter how it gets dressed up) affect this assignment process? Will
>it end up over-weighting the legitimate rights of capital, or will it
>short-shrift them? To the public, I would submit, the proliferation of
>regulatory bodies (even voluntary, associative bodies such as ARIN)
>seems unnecessary, complex, and a flim-flam, even if, to the trade, the
>regulated items (names versus IP's) seem obviously different, and hence
>in need of differing regulatory procedures.

Education is a part of this (disclaimer -- I am in the education business).
We have seen some flames launched already due to confusion between names
and addressing.
>
>The uninformed comments which confuse DNS registration issues with IP
>registration issues could be taken as a plea to rationalize the process
>IN THE EYES OF THE END-USER. This is a large-scale political issue, so
>the public-relations element should not be dismissed. If this is <OFF
>TOPIC>, then, of course, flame away.

I've spent a reasonable amount of time on Capitol Hill. While there can be
a great deal of furor and lawsuits, Congress usually winds up with enough
sense to avoid legislating technology, and there are checks and balances to
it.  The Exon bill was an aberration.  What is more typical is a
dividing-up-the-kill as we see with telecom interests.

Rather than get too far off the track in politics -- which, as Rep.
Gingrich has demonstrated, is a Bad Idea for a not-for-profit, there very
well may be a need for ARIN to take on an education function.  If it does,
that needs to be considered in the mission and budget.