The argument against multiple Registries

Stephen Satchell satchell at ACCUTEK.COM
Sun Feb 23 14:04:14 EST 1997


ABSTRACT:  Instead of building multiple stand-alone registries, or even one
stand-along registry, let's consider asking an existing organization with
Registry and Internet experience to take on the ARIN function.  This means
that the overhead to support the Registry is shared with other functions.
Specific organizations are mentioned as possibilities.


To all:
     I have read Mr. Fleming's comments about setting up a Registry in each
state of the United States, and infer from some other comments that each
territorality (state, province, and small country) should have a Registry
for Internet Numbers.  I wish to state my opposition to such a distributed
registry and present my rationale for that opposition thusly.
     I base my opposition on the Three Laws of Murphy:  (1) It's never as
easy as it looks; (2) It always takes longer than you think; and (3) if
anything can go wrong, it will.  Let's look at how these quixotic laws
would work in the multiple-Registry environment, using the existing
automobile registration system in the United States as our parallel model.
     It goes without saying that the existing vehicle tag system can issue
the same license number to at least 50 different vehicles.  I say "at
least" because  some states have issued the same number multiple times to
different vehicles, and also because some people have committed fraud and
have a single tag adorning multiple vehicles.  Law enforcement *hates* this
scheme, because it means that an officer has to learn the "colors" of each
state -- and the problem is compounded by states issuing difference schemes
of plates.  (Nevada has three separate color schemes for its vehicle tags,
for example.)
     The suggestion has been to allocate an /8 to each registry.  I contend
that you might want to consider allocating blocks of /12 because no every
registry is going to need the full 16-million-endpoint assignments, not to
mention the problem of eating numbers so fast that growth of the Internet
outside of North America would be stifled.
     If you have as few as 60 Registries in North America (notice I'm not
even looking at Central or South America at this point) you have a *huge*
fixed overhead expense incurred by each registry.  Remember, in my strawman
back-of-the-envelope budget, about a million dollars went for minimal staff
and overhead all by itself.  So instead of having a two-million aggregate
budget, you would have AT LEAST SIXTY MILLION aggregate budget.
     I don't think so.
***


     So let's look at another direction.  So much of the budget would be
for office space, basic office services such as payroll, accounts
receivable, accounts payable, and the ONE PERSON really doing the work we
need, doling out Internet Numbers.  Two million dollars to support ONE
PERSON.  For based on the comments on the list, one person could handle
easily 300 allocations -- if that's all that is involved.  That works out
to less than two allocations per business day.
     So why do we need a large staff?  So why do we need to have this huge
connectivity?  Another entity is responsible for the functionality of the
DNS, and IN-ADDR.ARPA is a ---DNS--- function, not an allocation function.
The ARIN person would give out numbers that are guaranteed to be uniquely
allocated, from ONE place in the Americas.  The person obtaining the
allocation then pays a fee to the DNS maintenance people for the ability to
have endpoints in that allocation looked up using IN-ADDR.ARPA.
Co-ordination with the DNS folks?  That can be done by allowing the DNS
authority to access the ARIN assignment database (maybe even have ARIN send
the database at intervals) so that requests can be authenticated.


COUNTER-PROPOSAL:

     Have Kim go to work for IEEE in their Registry department, where they
already have the infrastructure in place:  connectivity, support staff,
office space, and all the rest.  Instead of a $3 million a year budget, the
budget could be as small as $150K a year, fully burdened.
     As for membership, the IEEE already has a full scheme in place.
     Don't like the Institute of Electrical and Electronic Engineers?  Then
talk to the ACM, Association for Computing Machinery.  All the comments
about the IEEE also apply to the ACM.
     Policy would be set by existing organizations and groups.  If we don't
have one already performing the function, we should get the organizations
who are most concerned about the routing problem under one virtual roof and
hash out what would be acceptable to them, and ARIN could then use that as
policy direction.

---
Stephen Satchell, {Motorola ISG, Satchell Evaluations}
<http://www.accutek.com/~satchell> for contact and other info
Opinions stated here are my PERSONAL opinions.





More information about the Naipr mailing list