Why split IP allocations from the Internic?

Karl Denninger karl at MCS.NET
Wed Feb 26 13:44:18 EST 1997


> 
> On Wed, 26 Feb 1997, Jim Fleming wrote:
> 
> > In closing, can you or anyone explain in GREAT detail
> > why everyone seems to have decided that the IP address
> > allocations be split from the InterNIC, especially when their
> > is only one+ year left on the Cooperative Agreement ?
> 
> Quite simply, when the coop agreement ends, the Internic no longer 
> has to supply IP allocation services. Therefore, some arrangements
> have to be made in advance of that point to avoid the chaos that
> would result if an essential service were to disappear.
> 
> I can't see that any more detailled explanation is required than this.
> 
> Michael Dillon                   -               Internet & ISP Consulting
> Memra Software Inc.              -                  Fax: +1-250-546-3049
> http://www.memra.com             -               E-mail: michael at memra.com

I'd like to ask a few questions on all sides...


To NSI and Kim Hubbard:

1)	I have not seen anything in the bylaws or operational rules that
	state that the initial BOT (who are appointed) will be required to
	either stand for election or step down after a short (say, one year)
	period of time. 

	I think this needs to be addressed.  If you want to stagger initial
	terms, that's fine, but then let's have the NSI folks off the BOT
	first -- after the first 12 months.

2)	I'm still not satisfied with the representation provided to ARIN
	members.  At minimum a recall procedure for the BOT as well as the
	Advisory committee needs to be in place.  Direct election of the 
	Advisory committee would be even better (and yes, I'd like to run
	for that post :-)

3)	If this is a 501(c) organization then IRS forms have to be filed
	detailing revenue and expenses.  I'd like the bylaws to go further
	and mandate full disclosure and open books for the membership.

4)	Utilization requirements for additional space MUST be business-case
	neutral.  There are things in some of the recent RFCs that aren't,
	and that troubles me.  For example, there is a "strong disincentive"
	towards host-based addressing.  Yet I can show good examples of why
	its needed in many forms of service (like ISDN where the customer
	has a routing device, as well as customers who need to pierce
	corporate firewalls).  

	The bottom line is, if you have a /16, have you assigned it 
	efficiently -- not do you follow someone else's idea of a business 
	model.

	If THOSE kinds of criteria end up being the reason for denial of
	allocations there will IMHO be lawsuits.  That's not a good thing, 
	and I think we can reasonably avoid it.

	The bigger issue is customers who walk with space and new providers
	who *ACCEPT* them.  The issue isn't the customer who walks -- its
	the new provider to AGREES TO ROUTE THE OLD ADDRESS RANGE!  Stop
	THAT practice across the board and the CIDR collapse that everyone
	is shouting about goes away as an issue.

	I can document more than one customer of ours who has left for one
	reason or another with /24s and came back with "but xxxxx said 
	they will announce and route it" when we asked for the space back.
	Not one of those "xxxxx"s are little companies either -- they have
	ALL been major, Tier 1 backbone or MAJOR regional providers.  *I*m 
	not taking the arrows (or lawsuits) from the customer who signed 
	three years ago when I didn't have to make address non-portable 
	when this happens (yes, our policies are very different now, but 
	this is now and that was then.)

	Better yet, pressure vendors to sell real routers which don't have
	these problems with flapping and table size within the forseeable
	future.  There is one on the market now, and another due in June 
	of this year.
	
Why do I ask for these things?  Because I want ARIN to be "watertight" when
it comes to charges (which have already been made) that its biased, violating
laws, etc.  Let's try to get that codified.

PS: Kim, I *DO* like the changes you've made thus far.  I just don't think
    they go quite far enough in terms of representation, and that this can
    be easily fixed.


To the "naysayers":

1)	How is this supposed to get done?  It HAS TO HAPPEN folks.  I don't
	see anything that makes it horrible for ARIN as a structure to be
	there.

2)	Regarding fees - they aren't free.  Yep.  But the issue of global
	routability (which basically means you need a /19 or better today) 
	isn't one which ARIN can really address.  Frankly, attempting to
	address it at ARIN is, in my opinion, even MORE restraining on trade
	than NOT! 

	ARIN will have expenses.  I'd like to ask for all staff position
	salaries to be public; I believe that is reasonable, and furthermore
	that reasonable salaries are quite within the realm of what people
	should support.  The members will be professionals; I know what it
	costs to hire a reasonably-competent sysadmin, for example.  If you
	pay them twice that while working for ARIN I want to know about it
	and raise hell.  If you're hiring people at half of the prevailing
	wage I want to know ALSO -- because the bottom line there is that I
	would likely question their experience.

3)	IF you think you have a better mousetrap available -- let's see it.
	Put the pen to paper and document what you think we can do as an
	alternative, and why its better.  BACK IT UP WITH NUMBERS.  I can
	claim anything I want -- but if I can't show some credible
	documentation then its all just hot air.

That's where I sit... and I'm one of those guys who really *IS* a user of
these services, and we WILL be joining provided that the organization meets
what I believe are the public-policy points involved in making it bulletproof.

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal



More information about the Naipr mailing list