[ppml] FW: No transfer policies are needed

michael.dillon at bt.com michael.dillon at bt.com
Tue Apr 22 05:40:08 EDT 2008


> For instance, my company has a legacy Class B network that is 
> "in use". 
> However, it's entirely possible that the finance folks would 
> decide that, for a sufficient amount of money, we'd renumber 
> to 10/8 and sell the Class B, or perhaps renumber into a /24 
> subnet (for our public servers) and sell the rest.  I'm not 
> aware of anyone having offered us money, so I have no idea 
> what our CFO's reaction would be.

My worry is that people will only consider letting go of unused
blocks, not renumbering. And most of that space is probably in
orgs who have a class B which raises the specter of ISPs who
can't get a /17 from ARIN so they get 8 /20s from class B holders.
This means 8 new routes announced rather than 1. 

> > the transfer policy HARMS the organizations who succeed in buying 
> > addresses because they lose large sums of money which reduces their 
> > ability to move to IPv6.
> 
> It is not up to you to tell other organizations how to best 
> allocate their funds.

No, but I can call things as I see them. There is a cost-benefit
issue here for companies. Do I spend money on IPv6 which has delayed
benefits, or do I spend it on IPv4 and risk not being in a position
to invest additional money in two years when I need to shift to IPv6.
The people promoting IPv4 address trading are pushing up the costs 
for companies who do not invest in IPv6. And money spent on IPv4
address blocks is not an investment, unlike money spent on upgrading
routers to v6-compatible devices or upgrading monitoring/management
systems to support v6. 

>  If some folks decide that paying for 
> IPv4 space is better _for them_ than migrating to IPv6 (if 
> that's even possible), so be it.  I'll also point out that 
> for every party "harmed" in your view this way, there is 
> another organization _receiving_ money to help fund their migration.

Yes. My position is that these are the true beneficiaries of a 
transfer policy. I also think that there will be a smaller number of
buyers than sellers. These buyers will be shooting themselves in the
foot, or maybe just desperately scrambling to get by until their IPv6
capability comes on line. There will be many sellers, mostly smaller
orgs who have already gotten their IPv6 capability well underway, and
who like the idea of getting their competitors to finance the smaller
orgs headstart. Of course I could be wrong. Maybe MIT and HP will be
the true beneficiaries...

> Disclosures are only required when someone has a conflict of 
> interest; lack of disclosures does not imply people are 
> hiding things.  Unless you're accusing AC/BoT members of 
> ethics violations, one should assume that those who haven't 
> made a disclosure have nothing to disclose.

IP address blocks have no monetary value. Why should anyone bother
to disclose a holding or make any distinction between legacy or not?
If there were no talk of transfer policies, I don't see the point in
making any kind of formal disclosure. Let people search the ARIN db
if they are curious.

But all of a sudden, things change when we are seriously considering
proposals which monetize IP address blocks. Now is the time for this
sea change to be publicly recognized and for formal disclosures to
be made. 

> Furthermore, neither the AC nor BoT actually makes a decision 
> on policy -- the community does.  The BoT rubber-stamps the 
> AC's decisions unless there is evidence that the IRPEP was 
> not followed (which is rare).  The AC gauges community 
> consensus, regardless of the members' individual views.  As 
> others have pointed out, members of both bodies have recused 
> themselves (as shown in the minutes of their meetings) to 
> avoid even the appearance of impropriety.

I haven't trawled through the minutes of such meetings. And as you
say, the decisions are made by the community so what is wrong with
announcing address holdings to the community?

--Michael Dillon



More information about the ARIN-PPML mailing list