From dogwallah at gmail.com  Mon Sep  1 03:50:33 2008
From: dogwallah at gmail.com (McTim)
Date: Mon, 1 Sep 2008 10:50:33 +0300
Subject: [arin-ppml] IPv4 is depleted today
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E56C@SUEXCL-02.ad.syr.edu>
References: <48B7DE9F.7707.3AEC08B@farmer.umn.edu>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E56C@SUEXCL-02.ad.syr.edu>
Message-ID: <f65fb55e0809010050s1fdb70d2sd211244158f884dd@mail.gmail.com>

Milton,

On Sat, Aug 30, 2008 at 7:54 PM, Milton L Mueller <mueller at syr.edu> wrote:
<snip>
> Your post has two clear implications. One is that any policy regarding
> IPv4 depletion should not be contingent on free pool exhaustion but
> should go into effect as soon as feasible. The second is that you have
> conclusively demonstrated how inapplicable and outdated the whole
> business of assigning IPv4 according to "need" has become in these
> circumstances.

Perhaps you are forgetting the goals of the RIRs, two of the crucial
ones are Conservation and Aggregation.  Allocation and Assignment
according to need furthers both principles (generally).

If you have a proposal to change the NRM 4.2.1.4. (or any other part
of the NRM), please submit this as a policy proposal per:
http://www.arin.net/policy/irpep.html

<snip>

>
> For me, liberalization of transfers is no longer a debate about the
> merits of that policy itself. It has become a debate about whether the
> ARIN community has become so ideologically rigid in its commitment to
> "address Marxism"

nice one ;-/, see DK's reply to you re: keeping on topic.

that it cannot adapt to new economic realities. I will
> watch the progress of these policies with interest as a kind of
> diagnosis of the health of the RIR governance regime. If ARIN and the
> others cannot face reality and execute on this matter, it will not bode
> well for the future.

The RIRs bottom up PDPes do face reality as the discussion in the
various RIR fora have shown.  They may not want to "execute" they way
you do, but this doesn't mean the "governance regime" isn't healthy,
it just means that your POV isn't the consensus one.

-- 
Cheers,

McTim
mctim.blogspot.com


From rw at firstpr.com.au  Mon Sep  1 21:42:06 2008
From: rw at firstpr.com.au (Robin Whittle)
Date: Tue, 02 Sep 2008 11:42:06 +1000
Subject: [arin-ppml] IPv4 is depleted today - unrealistic
 statements	about IPv6 inevitability
In-Reply-To: <g3zlmue9ig.fsf@nsa.vix.com>
References: <C0F2465B4F386241A58321C884AC7ECC07CD0B71@E03MVZ2-UKDY.domain1.systemhost.net>	<48B9610C.5010404@firstpr.com.au>
	<g3zlmue9ig.fsf@nsa.vix.com>
Message-ID: <48BC99EE.9010509@firstpr.com.au>

Short version:   I think that the routing scaling problems will not
                 be so severe as to lead to widespread IPv6-only
                 adoption in the foreseeable future.

                 The only routers which will be affected
                 significantly by the growing number of DFZ routes
                 will be those of transit providers and large ISPs
                 where the routers have the highest number of
                 neighbours.  I believe the operators of those
                 routers will always find it better to upgrade or
                 replace those routers, or to limit the number of
                 neighbours they connect to, rather than drop some
                 DFZ routes and therefore provide a second-rate
                 service.

                 "Dual Stack Lite" is the most plausible model for
                 using IPv4 address space more intensively for
                 DSL/DOCSIS customers - but it would be costly to
                 implement and to run, and probably can't do port
                 forwarding. Therefore, it would be a second-rate
                 service a significant proportion of end-users -
                 primarily those who use P2P file sharing -

                 would find unworkable.  This would make it very
                 difficult to market, due to support calls and
                 competitors who offer a full IPv4 service touting
                 the limitations of "Dual Stack Lite".

                 The most likely response to the IPv4 routing
                 scaling problem and the related shortage of
                 IPv4 space (caused largely by the current BGP
                 only system being unable to slice the space
                 up finely without bloating the DFZ routing table)
                 is a Core-Edge Separation solution such as LISP,
                 APT, Ivip or TRRP.  (Six/One Router is also a
                 Core Edge Separation solution, but it only works
                 for IPv6.)  This could be used as the basis for a
                 new kind of IPv4 global mobility.


Hi Paul,

I largely agree with you.

Mailing lists thrive on disagreement, so here goes.  You wrote:

> when other networks can't get new IPv4 or can't deaggregate the IPv4 they
> bought off of e-bay fast enough because the other, other networks can't
> grow their routing tables fast enough, 

I don't think this will be a significant problem.  DFZ routers can
handle more then the current ~260k routes.  If it suddenly shot up
to 360k tomorrow, I guess virtually every DFZ router would work
fine.  The system may become more fragile, the CPUs more busy etc.
but the only hard limits are FIB capacity and RIB memory.

I understand some routers with TCAM FIBs hit their limit of 244k in
the last year or so:

  http://psg.com/lists/rrg/2008/msg01851.html

I understand that RIB memory requirements depends largely on the
number of DFZ routes multiplied by the number of BGP neighbours.

If there was a gradual increase in the number of DFZ routes, most
operators would be ensuring their routers didn't connect to
sufficient neighbours to come close to their RIB memory limitations,
so the increase in DFZ routes would lead to gradual acceleration of
replacement or upgrade costs, and/or to limiting the number of
neighbours any one particular router is used with.

As the DFZ routing table grows, every network which finds its router
stretched to its limit needs to decide whether to use the router in
a role with less neighbours, whether to replace it or whether to
keep it on station, and by some strategy have it ignore some growing
subset of the routes.

You seem to be suggesting that this last option will occur, and that
an increasing number of networks will fail to have their DFZ routers
carry the whole IPv4 DFZ routing table.  That would have the effect
of making certain parts of the Net unreachable from each network.
Unless all such networks coordinated their activities to ignore the
same subset of routes, then there would be a generalised loss of
connectivity affecting an increasingly large subset of routes -
presumably mainly /24s in some foreign country.

For this to occur, I think some conditions would have to be met:

1 - The networks concerned figured it was better to disrupt their
    customers' connectivity to an increasingly large subset of
    /24s than to wear the costs of:

    a - Replacing or upgrading routers.

    b - Using existing routers with less neighbours than they would
        like.

2 - That the networks (presumably ISPs, but also AS end-user
    networks such as of universities, large corporations etc.)
    would continue to do this despite the complaints they would
    get from their customers / users.


I could imagine the administrator of a small AS end-user network
might take a look at the /24s and define a subset of them which are
advertised in some far-distant country they don't expect to connect
much.  The administrator might then decide it was better to drop
those routes than buy a new router.  However, such small end-user
networks are not running routers with the large numbers of
neighbours which causes the most likely limitation to be reached -
RIB memory limits.

AFAIK, no modern router has an FIB problem with the current DFZ size
 - I understand they could all handle a million or more prefixes,
since many large networks have many more internal prefixes than the
260k in the DFZ.

So I think the only routers where the RIB limit will be reached will
 be of big ISPs, transit providers etc. - those with ten or more
(very rough guess) neighbours.

I believe there is no way any network operating such a router would
want to make it fail to connect to a subset of the Net.  Such lack
of connectivity would surely impact one of the many networks whose
traffic flows through this router.  In some cases it would cause the
traffic to flow in some other way, but maybe there is no other path,
and maybe the operator of this router has a contract to provide full
connectivity to other networks.

So I cannot imagine how your scenario would actually develop: a
significant number of networks being unreachable due to those or
other networks hitting RIB limits with their routers and deciding to
keep running them with the same number of neighbours, but by not
accepting some subset of the /24s.


> to start doing their growth some other way.  they won't stop growing.  GIH
> seems to think that the "other way" this growth will happen is going to be
> NAT and while i agree that there will be an uptick i cannot think that this
> will be all that happens.

So you are suggesting that many ISPs will purchase, obtain or
whatever IPv4 space suitable for their growth needs (I agree with
this) but won't be able to use it because a significant number of
networks refuse to accept their route, for reasons discussed above.


> many of you here won't need IPv6 because you've run out of space.  you will
> need IPv6 because other networks have run out of space, and because new
> deployments will have no choice.  

I don't think they will "need" IPv6, because IPv6 does not give them
what their customers need: IPv4 connectivity.

A pure IPv6 service is completely unsellable now and I think this
will remain so for the foreseeable future - except perhaps where the
end-users are only using 3G cellphones and are getting all the
communications they want with the IPv6 services provided largely by
their mobile carrier.

The only way IPv6 might be useful in ordinary DSL/DOCSIS/FTTH access
networks is for ISPs to implement something like "Dual Stack Lite".

David Conrad and I had a long discussion about this on the Routing
Research Group mailing list:

   http://psg.com/lists/rrg/2008/msg02045.html  RW
   http://psg.com/lists/rrg/2008/msg02077.html  DC
   http://psg.com/lists/rrg/2008/msg02079.html  RW
   http://psg.com/lists/rrg/2008/msg02080.html  RW  P2P usage rates
   http://psg.com/lists/rrg/2008/msg02081.html  DC
   http://psg.com/lists/rrg/2008/msg02083.html  RW

There would be many cost problems installing and running the
"Carrier Grade NAT" boxes required for this proposal.  IPv4
addresses are still needed, but some number of DSL/DOCSIS customers
would share a single IPv4 address.

A major limitation is that this service would not allow the
end-user's PCs to grab a port on the NAT boxes public address, as I
understand is often done today for P2P applications and perhaps some
games.

I haven't studied this depth, but I understand this is normally done
via uPnP IGD - and there's no way this can be done for multiple
end-users sharing the one public NAT address.  Even if the NAT box
somehow supported it, the first end-user to request  TCP 80 would
get it, and the others wouldn't be able to - and would soon be
pestering the help desk with complaints.  (Though maybe it could be
made to provide it, as long as the applications requesting the ports
would accept some other port number than the one they first
requested, since some other customer might already have that port.)


> but you don't have to take my word for it;
> you can wait for hard evidence and then do a bunch of in-year hurry-up
> unbudgeted upgrades.  i think that approach is a little bit silly, since the
> actual costs of running dual-stack, at least near your edge or in your labs,
> is not high enough to be worth avoiding.  even if you have to tunnel at
> first because your upstreams and/or peers aren't as visionary as yourself.

I think the costs of running dual stack and making it work would be
pretty high.  There are plenty of apps which don't work with IPv6
and there are few servers on IPv6.

IPv6 is not a fix for the problem of not being able to reach every
part of the IPv4 Internet, because it doesn't reach any of the IPv4
Internet.  The IPv6 Internet is a different Internet from the IPv4
Internet.

Theoretically, "Dual Stack Lite" is a means of using IPv6 access
networks to concentrate one or more dozen domestic/SOHO end-users
onto a a single IPv4 address, but this is not at all the same as
genuine IPv6 adoption which makes the IPv6 Internet actually reach
more computers.  If those "Dual Stack Lite" users all ran dual-stack
then they could start to use their native IPv6 connectivity as well.
 This would be good for P2P and games for instance - assuming their
peers also had native IPv6 and were successfully running their home
network and PCs dual stack (and most of them wouldn't be).

But what sort of configuration work, software upgraded,
complexities, flakiness, support calls etc. would be required for
ordinary end-users to run their home networks dual stack successfully?

I don't believe "Dual Stack Lite" is marketable, since a significant
and important subset of customers require uPnP IGD port forwarding.
 There's no way of successfully mass-marketing a service like this
if even a few percent of people find it second rate.  Word would get
around and the cost of support calls would be too high.  All a
competitor has to do is advertise full IPv4 support, rather than the
second-rate "Dual Stack Lite" approach, and it would be much more
difficult to attract and retain customers, including those who
didn't need uPnP IGD.


> speaking of vision, here are the competing ones as i see them.  on one hand
> we've got a massively deaggregated IPv4-only core with the density of pure
> neutronium 

Yes - and I reach for the patchcord which is less than one micron long!

> and only the largest carriers able to handle the route churn and
> FIB storage, and where the market value of one more /24 is set by the cost
> of trying to find someone who will route it for you, and there are harsh
> pressures on old PI, and there's more or less no new PI, and there will be
> no new entrants into the IPv4 core routing market.  the rest of us will be
> paying high dollars for edge PA and using NAT universally.  

It could get this bad if there is no widely deployed Core-Edge
Scheme to solve the routing scaling problem (LISP, APT, Ivip, TRRP
or Six/One Router).  I predict it would get this bad and still it
would be cheaper to keep using IPv4 directly, or via "Dual Stack
Lite" than to try and sell customers a pure IPv6 service which is
for an Internet most people don't connect to.


> all new apps will
> either not depend on end-to-end or they will fail, so things like VoIP will
> have to be carrier-side and most new apps will ride on TCP/80.

I haven't thought through all the details, but it would be bad.


> on the other hand we've got a brief unpleasant period like described above
> before enough other networks add native IPv6 to make it worthwhile for late
> adopters to finally add native IPv6, at which point new apps have a choice
> of "IPv6 native, or IPv4 NAT" and new entrants to the core routing arena
> have that choice and while it's risky some folks will make it work somehow.

There's always a point in an "IPv6 will start to be widely adopted
real soon now, really" story where the logic takes leave of this Earth.

IPv4 and IPv6 is the biggest IT upgrade chicken and egg problem we
have ever seen.  There is a barrier between the current state and
the desired state and the barrier is much higher than for any
comparable transition problem, such as Windoze to Unix/Linux or
Windows to Mac.

The 100% connectivity the IPv4 Internet offers to all other Internet
users is not at all provided by IPv6 and won't be for decades, if
ever.  As long as that remains the case, then there's reason to use
IPv6 exclusively, because it doesn't work: it doesn't provide
connectivity to 100% of users, or anything like it.


I think you are saying that while networks would be able to get IPv4
space for quite a long time, as people split it more finely and use
it more intensively, that this will cause widespread adoption of
IPv6 (either without any IPv4 NAT arrangement, or with the
address-efficient "Dual Stack Lite" approach), because the RIB or
perhaps FIB limitations of DFZ routers cause many networks not to
carry the whole DFZ routing table.

However, I have argued above that this is only likely to kick in
with the RIB of the transit routers with the most neighbours - and
that the providers who operate those will always find it more viable
to upgrade the router, or restrict the number of neighbours, rather
than offer incomplete connectivity.


> pressure against PI will remain about the same as it is now.  NAT will
> gradually shrink down to places where its security features are worthwhile,
> or where there's just no good enough reason to tear it out and go native.
> 
> i don't merely like the second vision better.  i am the parent of teenagers
> i have studied history and am sure that if new generations of humans and
> their corporations are told that they will have to live out their lives
> according to the values and compromises of their forebears and that their
> opporunities must all be shackled by tithes to existing landowners, then
> they WILL find another way.

I agree - but I think the way is likely to be a Core Edge Separation
scheme to solve the IPv4 routing scaling problem.  Then, very large
numbers (hundreds of millions or even a billion or two) networks
(many or most with a single IPv4 address) will have what I call
"Scalable PI" (SPI) address space.

SPI space will be portable between ISPs (which have Egress Tunnel
Routers) and will support multihoming.

I think there is money to be made creating such a system - so it
won't necessarily wait for IETF standards to be established.  This
is particularly so since the Core Edge Separation scheme could be
profitably extended to provide a global mobility system, with a
stable IPv4 (or IPv6) address, portable all over the world, with
generally optimal path lengths, while being compatible with all
existing applications and with all existing hosts as correspondent
hosts.  Steve Russert and I just finished a paper on this:

  http://www.firstpr.com.au/ip/ivip/#mobile


Pure IPv6 connectivity won't be any value to most end-users until
some very high fraction of all other end-users - including those at
home, in offices, and all web servers, game servers etc. - have
native IPv6 connectivity too.  Whether that fraction is 99% or
99.99% I don't know, but it is so far from the current small
fraction of one percent that I believe we can safely conclude that
pure IPv6 will remain unmarketable for the mass-market of home/SOHO
users for the foreseeable future (say to 2020 at least), while there
will be a growing demand for an IPv4 Core Edge Separation scheme.

Such a scheme will produce a new kind of address space which is in
high demand - portable, multihomable etc. without the need for BGP
expertise or investment.  It will work fine for very small slabs of
IPv4 address space, including single IPv4 addresses.

That will be a real and saleable service, while pure IPv6 will not
be saleable, and while IPv6 with "Dual Stack Lite" will be difficult
to sell, since 20% or more of home/SOHO customers need the port
forwarding it (probably) can't provide.

 - Robin



From jcurran at istaff.org  Tue Sep  2 01:47:07 2008
From: jcurran at istaff.org (John Curran)
Date: Tue, 2 Sep 2008 01:47:07 -0400
Subject: [arin-ppml] Routing Scaling Problems
In-Reply-To: <48BC99EE.9010509@firstpr.com.au>
References: <C0F2465B4F386241A58321C884AC7ECC07CD0B71@E03MVZ2-UKDY.domain1.systemhost.net>	<48B9610C.5010404@firstpr.com.au>
	<g3zlmue9ig.fsf@nsa.vix.com> <48BC99EE.9010509@firstpr.com.au>
Message-ID: <64BE7873-F6C9-4BDE-AA4B-ACDDB210D009@istaff.org>

On Sep 1, 2008, at 9:42 PM, Robin Whittle wrote:
>
> Short version:   I think that the routing scaling problems will not
>                 be so severe as to lead to widespread IPv6-only
>                 adoption in the foreseeable future.
>
>                 The only routers which will be affected
>                 significantly by the growing number of DFZ routes
>                 will be those of transit providers and large ISPs
>                 where the routers have the highest number of
>                 neighbours.  I believe the operators of those
>                 routers will always find it better to upgrade or
>                 replace those routers, or to limit the number of
>                 neighbours they connect to, rather than drop some
>                 DFZ routes and therefore provide a second-rate
>                 service.

"Second-rate" service is a matter of perspective, since the
alternative of continuously upgrading all of the DFZ routers
in a major transit-free ISP (presuming the equipment of that
scale is even available) means enormous capital expenditures,
and to do so solely because other providers are filling up
routing tables with fragments would require some interesting
financial justifications in any company.

Given that some providers are already having trouble keeping
up, is it your assumption that all "tier one" providers simply
have no choice, and pass along these ever increasing costs to
their existing customers?  It would only take one backbone ISP
to opt instead to drop "less popular" routes and have much lower
costs to make for some very interesting competitive pressure.

/John


From michael.dillon at bt.com  Tue Sep  2 03:52:02 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 2 Sep 2008 08:52:02 +0100
Subject: [arin-ppml] IPv4 is depleted today - unrealistic
	statements	about IPv6 inevitability
In-Reply-To: <48BC99EE.9010509@firstpr.com.au>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC07D44872@E03MVZ2-UKDY.domain1.systemhost.net>


> I don't think they will "need" IPv6, because IPv6 does not 
> give them what their customers need: IPv4 connectivity.

> A major limitation is that this service would not allow the 
> end-user's PCs to grab a port on the NAT boxes public 
> address, as I understand is often done today for P2P 
> applications and perhaps some games.

You seem to be assuming that everything else stays the
same, and that IPv6 users have to adapt to the reality
of the IPv4 network or do without. But that is not a
reasonable view. Everything is in flux and as IPv4 exhaustion
becomes better publicized, the developers of IPv4 software
are beginning to make it IPv6 compatible. 

So yes, there are some things that won't work well or won't
work at all, if IPv6 users have to go through NAT gateways
to access the IPv4 network. But that only means that there
is greater impetus for people to put these things on the
IPv6 Internet, and then the problem goes away.

Transition to IPv6 is an evolutionary process, not some kind
of big bang product launch.

> I think the costs of running dual stack and making it work 
> would be pretty high.  

So do many others. That's why we are looking at using 6PE over
an IPv4 MPLS core network. Minimize the impact on the existing
network. Any ISP with routers in more than one city really should
be considering migration to MPLS as a possible transition to 
the IPv6 Internet.

> There are plenty of apps which don't 
> work with IPv6 and there are few servers on IPv6.

This is just a time argument. Nobody is saying that today is the
time to start hooking up IPv6-only customers. We are saying that
today is the time to start trialing IPv6 in the lab, and to start
the careful process of deploying it on your live network. This
will all take a couple of years to get right, and then there will be
apps and servers on IPv6.

> It could get this bad if there is no widely deployed 
> Core-Edge Scheme to solve the routing scaling problem (LISP, 
> APT, Ivip, TRRP or Six/One Router). 

There are other non-technology ways to solve this problem.

> There's always a point in an "IPv6 will start to be widely 
> adopted real soon now, really" story where the logic takes 
> leave of this Earth.

Agreed. But the fact is that IPv6 has been deployed in production
for many years in research and academic networks. And in all
continents, government and military organizations are increasing
their deployment. People who remember the early Internet understand
how exponential growth works. A precondition for 1500% per annum
growth (that was 1995), is many, many years of fractional percentage
growth. Slow and steady wins the race.

> The 100% connectivity the IPv4 Internet offers to all other 
> Internet users is not at all provided by IPv6

It's not provided by IPv4 either. There are vast parts of the IPv4
Internet that you cannot get to because of language barriers and
because of routing issues at the edge of the big cloud.

> Pure IPv6 connectivity won't be any value to most end-users 
> until some very high fraction of all other end-users - 
> including those at home, in offices, and all web servers, 
> game servers etc. - have native IPv6 connectivity too.  

You don't understand the network effect and how it drives 
that long slow tail that leads to a sudden leap in growth.
It's not flashy, but its essential and it is well under
way for IPv6.

--Michael Dillon


From kkargel at polartel.com  Tue Sep  2 09:55:58 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 2 Sep 2008 08:55:58 -0500
Subject: [arin-ppml] IPv4 is depleted today
In-Reply-To: <063C51B9C31343FDA0EBB4F986E01C33@tedsdesk>
References: <48B8304F.8816.4EDD8D6@farmer.umn.edu>
	<063C51B9C31343FDA0EBB4F986E01C33@tedsdesk>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AA4@mail>

<<Enormous snipping leaving hugely out of context quote>> 

>>You are right.  We should just kill the transfer policy idea and be
done with it.

>>Ted

I tend to agree Ted, I think for the most part nobody is going to do
anything real until AFTER they are denied new IPv4 addresses..  And
there is nothing we can do about it.

Change is painful for the human mind, and people will avoid change and
risk for as long as absolutely possible.  The runout is going to happen,
and it is going to hurt.  It would hurt a lot less if people were
prepared, in fact it could be downright painless, but we don't really
have a right to force anyone to prepare.  

The best thing I can see to do is to let IPv4 run out naturally, and
when that happens sit back and watch the show..  You and I will be
prepared, our customers will be able to get to most content providers,
there is not much more we can do.

IPv4 will not stop working, it will continue on.  Business in the
Internet will be as usual.  The only change will be a great slowing in
NEW hosts.  

The human animal is basically lazy.  They will move to IPv6 when it is
less work than not moving, and not a moment before.

Kevin


From dudepron at gmail.com  Tue Sep  2 10:41:23 2008
From: dudepron at gmail.com (Aaron)
Date: Tue, 2 Sep 2008 10:41:23 -0400
Subject: [arin-ppml] Routing Scaling Problems
In-Reply-To: <64BE7873-F6C9-4BDE-AA4B-ACDDB210D009@istaff.org>
References: <C0F2465B4F386241A58321C884AC7ECC07CD0B71@E03MVZ2-UKDY.domain1.systemhost.net>
	<48B9610C.5010404@firstpr.com.au> <g3zlmue9ig.fsf@nsa.vix.com>
	<48BC99EE.9010509@firstpr.com.au>
	<64BE7873-F6C9-4BDE-AA4B-ACDDB210D009@istaff.org>
Message-ID: <480dad640809020741r2f9db34aged2a69a7127bd367@mail.gmail.com>

Wouldn't that just bring us full circle? Filtering /20 and longer brings
back some memories..

Aaron

On Tue, Sep 2, 2008 at 1:47 AM, John Curran <jcurran at istaff.org> wrote:

> On Sep 1, 2008, at 9:42 PM, Robin Whittle wrote:
> >
> > Short version:   I think that the routing scaling problems will not
> >                 be so severe as to lead to widespread IPv6-only
> >                 adoption in the foreseeable future.
> >
> >                 The only routers which will be affected
> >                 significantly by the growing number of DFZ routes
> >                 will be those of transit providers and large ISPs
> >                 where the routers have the highest number of
> >                 neighbours.  I believe the operators of those
> >                 routers will always find it better to upgrade or
> >                 replace those routers, or to limit the number of
> >                 neighbours they connect to, rather than drop some
> >                 DFZ routes and therefore provide a second-rate
> >                 service.
>
> "Second-rate" service is a matter of perspective, since the
> alternative of continuously upgrading all of the DFZ routers
> in a major transit-free ISP (presuming the equipment of that
> scale is even available) means enormous capital expenditures,
> and to do so solely because other providers are filling up
> routing tables with fragments would require some interesting
> financial justifications in any company.
>
> Given that some providers are already having trouble keeping
> up, is it your assumption that all "tier one" providers simply
> have no choice, and pass along these ever increasing costs to
> their existing customers?  It would only take one backbone ISP
> to opt instead to drop "less popular" routes and have much lower
> costs to make for some very interesting competitive pressure.
>
> /John
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080902/30e47217/attachment.htm>

From iljitsch at muada.com  Tue Sep  2 10:49:44 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Tue, 2 Sep 2008 16:49:44 +0200
Subject: [arin-ppml] Routing Scaling Problems
In-Reply-To: <480dad640809020741r2f9db34aged2a69a7127bd367@mail.gmail.com>
References: <C0F2465B4F386241A58321C884AC7ECC07CD0B71@E03MVZ2-UKDY.domain1.systemhost.net>
	<48B9610C.5010404@firstpr.com.au> <g3zlmue9ig.fsf@nsa.vix.com>
	<48BC99EE.9010509@firstpr.com.au>
	<64BE7873-F6C9-4BDE-AA4B-ACDDB210D009@istaff.org>
	<480dad640809020741r2f9db34aged2a69a7127bd367@mail.gmail.com>
Message-ID: <26F0625B-4733-447D-9A4D-D42CD8AD0D1C@muada.com>

On 2 sep 2008, at 16:41, Aaron wrote:

> Wouldn't that just bring us full circle? Filtering /20 and longer  
> brings back some memories..

Wasn't this /18?

Anyway, I would suggest ditching everything longer than /16. That's  
95% of the routing table but only 6% of the address space.

http://www.bgpexpert.com/presentations/lacnic-ivb-ipv6-routingtable.pdf



From mueller at syr.edu  Tue Sep  2 11:42:28 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 2 Sep 2008 11:42:28 -0400
Subject: [arin-ppml] Privacy rights & IP number whois ( was Re: The LRSA
	$100 fee...)
In-Reply-To: <A45F6D39-A48B-48A8-9CA0-D7518A605C90@pch.net>
References: <48B82BBE.80907@bogomips.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu>
	<03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu>
	<99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net>
	<A45F6D39-A48B-48A8-9CA0-D7518A605C90@pch.net>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E59A@SUEXCL-02.ad.syr.edu>


> -----Original Message-----
> From: Tom Vest [mailto:tvest at pch.net]
> 
> A couple of quick questions:
> 
> 1. Do you think that the completeness and accuracy of current DNS
> whois is the right standard for IP number whois?

I have a more relevant question to ask. Do you think that IP number
Whois should be optimized to permit copyright holders to identify
individual file-sharers on ISP networks and serve legal process on them?


You answer that first, we'll discuss the details of DNS Whois
afterwards. It is a subject I know a lot about.



From dogwallah at gmail.com  Tue Sep  2 12:03:07 2008
From: dogwallah at gmail.com (McTim)
Date: Tue, 2 Sep 2008 19:03:07 +0300
Subject: [arin-ppml] Privacy rights & IP number whois ( was Re: The LRSA
	$100 fee...)
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E59A@SUEXCL-02.ad.syr.edu>
References: <48B82BBE.80907@bogomips.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu>
	<03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu>
	<99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net>
	<A45F6D39-A48B-48A8-9CA0-D7518A605C90@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E59A@SUEXCL-02.ad.syr.edu>
Message-ID: <f65fb55e0809020903s3a34d964o2f192f2c0dd34e91@mail.gmail.com>

Milton,

On Tue, Sep 2, 2008 at 6:42 PM, Milton L Mueller <mueller at syr.edu> wrote:
>
>> -----Original Message-----
>> From: Tom Vest [mailto:tvest at pch.net]
>>
>> A couple of quick questions:
>>
>> 1. Do you think that the completeness and accuracy of current DNS
>> whois is the right standard for IP number whois?
>
> I have a more relevant question to ask. Do you think that IP number
> Whois should be optimized to permit copyright holders to identify
> individual file-sharers on ISP networks and serve legal process on them?

I think that question is disingenuous,  The level of specificity of IP
Whois has always been granularly set so that the appropriate folk can
be contacted in case of network trouble/abuse/DDos/outage, not for any
socio-economic reason.

No one has ever suggested it IIRC, if you have a policy proposal in
this regard, you know where to send it.

>
>
> You answer that first, we'll discuss the details of DNS Whois
> afterwards. It is a subject I know a lot about.

Yes, but that wasn't TVs query, which was:

>> 1. Do you think that the completeness and accuracy of current DNS
>> whois is the right standard for IP number whois?


-- 
Cheers,

McTim
mctim.blogspot.com


From mueller at syr.edu  Tue Sep  2 12:13:12 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 2 Sep 2008 12:13:12 -0400
Subject: [arin-ppml] Privacy rights & IP number whois ( was Re: The LRSA
	$100 fee...)
In-Reply-To: <f65fb55e0809020903s3a34d964o2f192f2c0dd34e91@mail.gmail.com>
References: <48B82BBE.80907@bogomips.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu>
	<03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu>
	<99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net>
	<A45F6D39-A48B-48A8-9CA0-D7518A605C90@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E59A@SUEXCL-02.ad.syr.edu>
	<f65fb55e0809020903s3a34d964o2f192f2c0dd34e91@mail.gmail.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E59F@SUEXCL-02.ad.syr.edu>


> -----Original Message-----
> From: McTim [mailto:dogwallah at gmail.com]
> I think that question is disingenuous,

No, it isn't. And your response proves it, because it says exactly what
I thought it would:

> The level of specificity of IP
> Whois has always been granularly set so that the appropriate folk can
> be contacted in case of network trouble/abuse/DDos/outage, not for any
> socio-economic reason.

Right! Exactly. So first we establish the PURPOSE of the data, and what
are the limits of its appropriate use, and THEN we can settle on how
"complete and accurate" it is. 

The problem with DNS Whois is that the order of those questions has been
reversed. 

On the other hand, if you put a bunch of commercially and legally useful
but potentially sensitive private information into Whois that can be
used indiscriminately for any purpose by any person on the planet at any
time and for any reason, then people are going to deliberately put
shielded or guarded or inaccurate information into it.


> Yes, but that wasn't TVs query, which was:
> 
> >> 1. Do you think that the completeness and accuracy of current DNS
> >> whois is the right standard for IP number whois?
> 

I don't think _anything_ about current DNS Whois should serve as a model
for IP address Whois. Not the access policy, not the accuracy or
"completeness" not anything. 




From kkargel at polartel.com  Tue Sep  2 12:23:30 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 2 Sep 2008 11:23:30 -0500
Subject: [arin-ppml] Privacy rights & IP number whois ( was Re: The
	LRSA$100 fee...)
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E59F@SUEXCL-02.ad.syr.edu>
References: <48B82BBE.80907@bogomips.com><369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com><7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu><03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net><7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu><99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net><A45F6D39-A48B-48A8-9CA0-D7518A605C90@pch.net><7663C7E01D8E094989CA62F0B0D21CD901E0E59A@SUEXCL-02.ad.syr.edu><f65fb55e0809020903s3a34d964o2f192f2c0dd34e91@mail.gmail.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E59F@SUEXCL-02.ad.syr.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AA7@mail>

>From the ISP's perspective, the Whois reports information for the contacts
that the IP address is assigned to.  I have thousands of customers, most of
which are transitory in nature.  Keeping records in whois for thousands of
transitory customers would be an unrealistic burden.

There is already a system in place that very nicely allows copyright holders
access to the customer.  When there is an infringement the copyright holder
files a report with law enforcement, law enforcement provides me with a
subpeona and I provide them with every bit of data I have to satisfy the
subpoena.  This is a good and working heirarchical system that protects
everyones rights and allows the laws to be justly enforced at the same time.

If the issue is a DoS issue, then as the ISP my name is publicly available
on the IP record, and I would be the appropriate contact anyway.  If there
is a problem of abuse from an IP within my edges I can quickly and easily
block, limit or otherwise deal with the problem.  

I think the system that is in place is for the most part well designed and
working.  Some streamlining could be done but those are minor points. 

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Milton L Mueller
Sent: Tuesday, September 02, 2008 11:13 AM
To: McTim
Cc: ARIN PPML
Subject: Re: [arin-ppml] Privacy rights & IP number whois ( was Re: The
LRSA$100 fee...)


> -----Original Message-----
> From: McTim [mailto:dogwallah at gmail.com] I think that question is 
> disingenuous,

No, it isn't. And your response proves it, because it says exactly what I
thought it would:

> The level of specificity of IP
> Whois has always been granularly set so that the appropriate folk can 
> be contacted in case of network trouble/abuse/DDos/outage, not for any 
> socio-economic reason.

Right! Exactly. So first we establish the PURPOSE of the data, and what are
the limits of its appropriate use, and THEN we can settle on how "complete
and accurate" it is. 

The problem with DNS Whois is that the order of those questions has been
reversed. 

On the other hand, if you put a bunch of commercially and legally useful but
potentially sensitive private information into Whois that can be used
indiscriminately for any purpose by any person on the planet at any time and
for any reason, then people are going to deliberately put shielded or
guarded or inaccurate information into it.


> Yes, but that wasn't TVs query, which was:
> 
> >> 1. Do you think that the completeness and accuracy of current DNS 
> >> whois is the right standard for IP number whois?
> 

I don't think _anything_ about current DNS Whois should serve as a model for
IP address Whois. Not the access policy, not the accuracy or "completeness"
not anything. 


_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public
Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080902/41106c8a/attachment.bin>

From mueller at syr.edu  Tue Sep  2 12:29:30 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 2 Sep 2008 12:29:30 -0400
Subject: [arin-ppml] Privacy rights & IP number whois ( was Re: The LRSA
	$100 fee...)
In-Reply-To: <6eb799ab0808311641nc3a569eqbc20352cf9de47e9@mail.gmail.com>
References: <48B82BBE.80907@bogomips.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu>
	<03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu>
	<99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net>
	<A45F6D39-A48B-48A8-9CA0-D7518A605C90@pch.net>
	<6eb799ab0808311641nc3a569eqbc20352cf9de47e9@mail.gmail.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E5A0@SUEXCL-02.ad.syr.edu>


> -----Original Message-----
> From: James Hess [mailto:mysidia at gmail.com]
> 
> In my view there is no legitimate privacy right protected by allowing
> contact information to be witheld in _EITHER_ the case of DNS or IP
> whois. WHOIS proxy services should simply not be allowed by any
> registry.  Privacy deals with private, personal information.
> The right to privacy is not a right to anonymity.   There is no human
> right to anonymity.

This is typical of the debates we went through on the DNS side. I see we
have perhaps another 10 years of work to do on the address side. 

Like many people coming to these debates with limited knowledge of the
legal, historical and political aspects of privacy and data protection
debates, James presents us with a series of oversimplified false
dichotomies: either there is "no privacy at all" or "society has no
access to any information about the person," etc. 

But the law has dealt with this for ages, and it is perfectly possible
to have specific conditions under which specific kinds of information
are revealed to law enforcement or others when necessary, following due
process, without being made publicly available indiscriminately. 

A simple example is drivers' license records. It is not legal for anyone
in the world to copy down someone's license plate number and go to the
Internet and look up their vehicle registration record, and get their
home address, phone number, etc. Only police and law enforcement
authorities can do that.

Do you think it should be different? 

With all due respect to James, the definition of privacy rights is a
legal issue, decided by legislatures, courts and constitutions, not by
technical administrators who think it's convenient for them to have
certain kinds of information, or who concoct de novo theories about how
using "public" resources somehow eliminates all claims to privacy of the
person using it.

Here's a good place to start investigating some aspects of anonymity.
http://www.eff.org/issues/anonymity  

Wrt to registration records, there is a clear distinction to be made
between individuals, which the law refers to as natural persons, and
"legal persons" which are not persons at all but organizations. Privacy
rights mostly inhere in individuals, natural persons. This is
well-established in privacy law. However, organizations also have some
weaker rights to withhold information from public exposure. 

The other thing to keep in mind is that in Internet governance you may
be making decisions with global effect, when national laws on the topic
may vary. So unless you believe you have a right to legislate for people
in other countries, you might want to approach the topic with a bit more
nuance and humility. 

> What individuals do with domains and with IPs is no less a public
> manner than owning something like a public corporation.

That claim sounds pretty odd on the face of it. Someone has an email
address and it's the equivalent of being the trustee of a publicly
listed corporation drawing on millions of other people's money? 

But if you really believe that, give me your mobile number, go ahead and
publish it on this list and let it be publicly archived, because I don't
see any difference between that and a domain. 



From mueller at syr.edu  Tue Sep  2 12:47:34 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 2 Sep 2008 12:47:34 -0400
Subject: [arin-ppml] The LRSA $100 fee...
In-Reply-To: <3c3e3fca0808311630s833e70fwf6f0c6ee00e3259e@mail.gmail.com>
References: <48B82BBE.80907@bogomips.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu>
	<03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu>
	<3c3e3fca0808311630s833e70fwf6f0c6ee00e3259e@mail.gmail.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E5A3@SUEXCL-02.ad.syr.edu>

> -----Original Message-----
> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of
William
> of addresses as a diminishing resource. Without transparency, nothing
> even vaguely similar to ARIN's current management process can exist.
> Privacy and anonymity are forms of secrecy. They have an important
> role in our society, but secrecy is fundamentally incompatible with
> transparency. You can't have both.

Bill
I was talking about DNS Whois. One must be very careful indeed to keep
the conversations about DNS and IP address whois distinct. 

As I think my other posts have made clear, it is perfectly appropriate
for address Whois records to identify the assignee who occupies the
resources, especially when this has operational implications regarding
routing, address hijacking, etc. 

And as McTim's post made clear, one has to be careful to segregate the
true operational needs from other kinds of needs that might be loaded on
to a Whois system. 




From mksmith at adhost.com  Tue Sep  2 12:53:15 2008
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 2 Sep 2008 09:53:15 -0700
Subject: [arin-ppml] The LRSA $100 fee...
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E5A3@SUEXCL-02.ad.syr.edu>
References: <48B82BBE.80907@bogomips.com><369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com><7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu><03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net><7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu><3c3e3fca0808311630s833e70fwf6f0c6ee00e3259e@mail.gmail.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E5A3@SUEXCL-02.ad.syr.edu>
Message-ID: <17838240D9A5544AAA5FF95F8D520316049038AF@ad-exh01.adhost.lan>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf
> Of Milton L Mueller
> Sent: Tuesday, September 02, 2008 9:48 AM
> To: William Herrin
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] The LRSA $100 fee...
> 
> > -----Original Message-----
> > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of
> William
> > of addresses as a diminishing resource. Without transparency, nothing
> > even vaguely similar to ARIN's current management process can exist.
> > Privacy and anonymity are forms of secrecy. They have an important
> > role in our society, but secrecy is fundamentally incompatible with
> > transparency. You can't have both.
> 
> Bill
> I was talking about DNS Whois. One must be very careful indeed to keep
> the conversations about DNS and IP address whois distinct.

Then please refer to IP address whois as in-addr.arpa records, not IP whois records.

Regards,

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080902/914a4637/attachment.sig>

From sleibrand at internap.com  Tue Sep  2 13:03:03 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 02 Sep 2008 10:03:03 -0700
Subject: [arin-ppml] The LRSA $100 fee...
In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049038AF@ad-exh01.adhost.lan>
References: <48B82BBE.80907@bogomips.com><369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com><7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu><03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net><7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu><3c3e3fca0808311630s833e70fwf6f0c6ee00e3259e@mail.gmail.com>	<7663C7E01D8E094989CA62F0B0D21CD901E0E5A3@SUEXCL-02.ad.syr.edu>
	<17838240D9A5544AAA5FF95F8D520316049038AF@ad-exh01.adhost.lan>
Message-ID: <48BD71C7.4050609@internap.com>

Michael K. Smith - Adhost wrote:

>> I was talking about DNS Whois. One must be very careful indeed to keep
>> the conversations about DNS and IP address whois distinct.
> 
> Then please refer to IP address whois as in-addr.arpa records, not IP whois records.

Milton isn't talking about in-addr.arpa PTR records.  He's drawing the 
distinction between the output of "whois somedomain.com" (DNS whois) and 
"whois 192.168.0.1" (IP whois).  While they both use the whois protocol, 
those two namespaces operate under somewhat different rules.

-Scott


From mueller at syr.edu  Tue Sep  2 13:26:56 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 2 Sep 2008 13:26:56 -0400
Subject: [arin-ppml] The LRSA $100 fee...
In-Reply-To: <99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net>
References: <48B82BBE.80907@bogomips.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu>
	<03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu>
	<99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E5AE@SUEXCL-02.ad.syr.edu>


> -----Original Message-----
> From: Tom Vest [mailto:tvest at pch.net]
> > Sorry to spoil your points with facts.
> 
> Facts?! If you are referring to your latest ad hoc substitution of
> what we were previously talking about by something you'd be more
[snip]

> But I'll grant a partial indulgence anyway. "Improvement since 1999"
> is a clever way of phrasing the answer, 

No it's not. Again, you have to have some familiarity with the facts.
1999 is the date competition and the current registrar accreditation
agreement was put into place, and that's what we were discussing. You
said competition made it all go to hell. I contested that. 

> GAO 06-165, November 2005:
> Prevalence of False Contact Information for Registered Domain Names
> http://www.gao.gov/new.items/d06165.pdf

The GAO study makes a plausible claim that about 5% of Whois records are
"patently" inaccurate about perhaps another 3.5% have some data field
missing. 

There is no historical comparative data. The report also showed that
ICANN's correction process worked about 1/3 of the time. Not good, but
before 1999 there was no process for reporting and correcting records at
all. 

Don't forget to keep this all in context. This is DNS Whois, not IP
address Whois. The registries know who has what domain and as long as
the registrar is identified and the nameserver records are accurate the
name functions and it can be tracked if necessary. All the other info is
ONLY of interest to TM lawyers trying to surveill and serve process on
domain name owners. The absence of a data field (e.g., an admin contact
name missing or bogus) has no appreciable effect on the operation of the
DNS or on the Internet. 

What we were discussing, if you will recall, is whether Whois accuracy
in 2008 is better than it was in 1999, when competition was instituted.
Are you able to credibly contest this claim? Or not? If not, what
exactly is your point, Tom? 

Further - and I don't know the answer to this one - do you think ARIN
Whois's level of general accuracy exceeds 92%? You might want to check
that.  

At this stage the argument for improved enforcement of the Whois
reporting and correction process is little more than an argument for a
bigger ICANN and a free service to IPR lawyers. Since 2005 ICANN's
budget has more than doubled, I think. We will approach $100 million in
the next couple years. Does that make you happy? Does it make you lick
your lips at how big and wealthy ARIN can become if you play your cards
right? 




From dogwallah at gmail.com  Tue Sep  2 14:29:26 2008
From: dogwallah at gmail.com (McTim)
Date: Tue, 2 Sep 2008 21:29:26 +0300
Subject: [arin-ppml] The LRSA $100 fee...
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E5AE@SUEXCL-02.ad.syr.edu>
References: <48B82BBE.80907@bogomips.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu>
	<03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu>
	<99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E5AE@SUEXCL-02.ad.syr.edu>
Message-ID: <f65fb55e0809021129k61f01c28wf0005b451f561091@mail.gmail.com>

On Tue, Sep 2, 2008 at 8:26 PM, Milton L Mueller <mueller at syr.edu> wrote:
<OT/chalk n cheese stuff snipped>
> the next couple years. Does that make you happy? Does it make you lick
> your lips at how big and wealthy ARIN can become if you play your cards
> right?

See John Curran's remarks at the beginning of this thread:

<quote>
"Okay, to be clear, ARIN's got a surplus today but that's a good
thing.  We've lowered fees 5 times, added new services, and I
know that I'll at least advocate that continue to reduce fees and
increase services to the extent that seems financially prudent.

If one takes a very long term view, it's clear that there will not
be a lot of allocation activity with IPv6 (i.e. folks coming back
for additional blocks ;-) and it's uncertain whether there will be
much IPv6 policy activity.  It's a valid question as to what level
of subscription to registration services is needed when someone
doesn't anticipating putting in their next Internet resource request
within the same decade, and hence what fees should apply.  For
reference (from the online Annual Report), subscription services
fees made up just over 85% of ARIN's total receipts, so any
significant change in the nature of subscription services or fees
could have a significant impact on ARIN's overall finances.

</quote>

In other words, IIUC, ARIN will never be "big and wealthy", your
comparison with ICANN isn't useful.

-- 
Cheers,

McTim
mctim.blogspot.com


From tedm at ipinc.net  Tue Sep  2 14:58:28 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 2 Sep 2008 11:58:28 -0700
Subject: [arin-ppml] IPv4 is depleted today
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10AA4@mail>
Message-ID: <520A5264CB154E6A820BE6FA969CB4E8@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Tuesday, September 02, 2008 6:56 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv4 is depleted today
> 
> 
> <<Enormous snipping leaving hugely out of context quote>> 
> 
> >>You are right.  We should just kill the transfer policy idea and be
> done with it.
> 
> >>Ted
> 
> I tend to agree Ted, I think for the most part nobody is 
> going to do anything real until AFTER they are denied new 
> IPv4 addresses..  And there is nothing we can do about it.
> 
> Change is painful for the human mind, and people will avoid 
> change and risk for as long as absolutely possible.  The 
> runout is going to happen, and it is going to hurt.  It would 
> hurt a lot less if people were prepared, in fact it could be 
> downright painless, but we don't really have a right to force 
> anyone to prepare.  
> 
> The best thing I can see to do is to let IPv4 run out 
> naturally, and when that happens sit back and watch the 
> show..  You and I will be prepared, our customers will be 
> able to get to most content providers, there is not much more 
> we can do.
> 
> IPv4 will not stop working, it will continue on.  Business in 
> the Internet will be as usual.  The only change will be a 
> great slowing in NEW hosts.  
> 
> The human animal is basically lazy.  They will move to IPv6 
> when it is less work than not moving, and not a moment before.
> 

Absolutely, but this is an equation with 2 sides - one side is
ease of moving to IPv6, the other side is ease of NOT moving
to IPv6 and continuing to use IPv4.

It is imperative that our policy making strive to increase
ease of moving to IPv6 and decrease ease of staying with IPv4.

A liberalized transfer policy does nothing to increase ease of
moving to IPv6, all it does is make it easier to stay on IPv4.

Ted



From sleibrand at internap.com  Tue Sep  2 15:21:07 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 02 Sep 2008 12:21:07 -0700
Subject: [arin-ppml] IPv4 is depleted today
In-Reply-To: <520A5264CB154E6A820BE6FA969CB4E8@tedsdesk>
References: <520A5264CB154E6A820BE6FA969CB4E8@tedsdesk>
Message-ID: <48BD9223.4030606@internap.com>

Ted Mittelstaedt wrote:

> It is imperative that our policy making strive to increase
> ease of moving to IPv6 and decrease ease of staying with IPv4.
> 
> A liberalized transfer policy does nothing to increase ease of
> moving to IPv6, all it does is make it easier to stay on IPv4.

I think you just identified a key point of disagreement / philosophical 
difference.

To my mind the idea that "we need to adopt policy to make people's lives 
harder", in the interest of promoting our idea of their long-term best 
interest, is an extraordinary claim that requires extraordinary evidence 
that the benefits outweigh the harms.

I'm all in favor of easing the move to IPv6.  However, I think we also 
need to do what we can to ease the transition across the board.

-Scott


From tedm at ipinc.net  Tue Sep  2 17:24:43 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 2 Sep 2008 14:24:43 -0700
Subject: [arin-ppml] IPv4 is depleted today
In-Reply-To: <48BD9223.4030606@internap.com>
Message-ID: <F24F22BEE0A241AC9A8C858366128C9B@tedsdesk>



> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com] 
> Sent: Tuesday, September 02, 2008 12:21 PM
> To: Ted Mittelstaedt
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv4 is depleted today
> 
> 
> Ted Mittelstaedt wrote:
> 
> > It is imperative that our policy making strive to increase ease of 
> > moving to IPv6 and decrease ease of staying with IPv4.
> > 
> > A liberalized transfer policy does nothing to increase ease 
> of moving 
> > to IPv6, all it does is make it easier to stay on IPv4.
> 
> I think you just identified a key point of disagreement / 
> philosophical 
> difference.
> 
> To my mind the idea that "we need to adopt policy to make 
> people's lives 
> harder", in the interest of promoting our idea of their 
> long-term best 
> interest, is an extraordinary claim that requires 
> extraordinary evidence 
> that the benefits outweigh the harms.
> 

But nobody who is against a liberalized transfer policy is asking
that we adopt ANYTHING.  They are asking that we DO NOT adopt
anything.

> I'm all in favor of easing the move to IPv6.  However, I 
> think we also 
> need to do what we can to ease the transition across the board.
> 

Your right.  I hope you define "transition" as I do, meaning
in this instance CHANGE from IPv4 to IPv6, and NOT meaning
continue to use IPv4 and ignoring IPv6.

Would you be willing to tie a liberalized policy to a requirement
that the transferee (ie: the party that is obtaining the IPv4 as
a result of a liberalized transfer) submit a transition plan to
IPv6 to ARIN, and some reasonable proof that they were actually
doing some of the items on it?  Such as obtaining IPv6 allocations
from ARIN?  And such as providing the date their feed is going to
natively route IPv6 and the date that they plan to do so as well?
And maybe some mandatory followup by ARIN a few years later to
insure these things are being done?

If not, what a transfer policy does is allow the status quo to
continue UNCHANGED.  That is NOT transition.

Ted



From Lee.Howard at stanleyassociates.com  Tue Sep  2 17:40:09 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Tue, 2 Sep 2008 17:40:09 -0400
Subject: [arin-ppml] IPv4 is depleted today - unrealistic
	statements	about IPv6 inevitability
In-Reply-To: <48BC99EE.9010509@firstpr.com.au>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robin Whittle
> Sent: Monday, September 01, 2008 9:42 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] IPv4 is depleted today - unrealistic 
> statements about IPv6 inevitability
> 
> Short version:   I think that the routing scaling problems will not
>                  be so severe as to lead to widespread IPv6-only
>                  adoption in the foreseeable future.

The people I speak to who operate large network think differently.

 
>                  The only routers which will be affected
>                  significantly by the growing number of DFZ routes
>                  will be those of transit providers and large ISPs
>                  where the routers have the highest number of
>                  neighbours.  I believe the operators of those
>                  routers will always find it better to upgrade or
>                  replace those routers, or to limit the number of
>                  neighbours they connect to, rather than drop some
>                  DFZ routes and therefore provide a second-rate
>                  service.

Those operators tell me there are no routers available or planned
that can handle the projected volume of routes and updates.  One
of the engineers for a router company you'll recognize told us about
a year ago that Moore's Law is approaching its limits regarding
routing scalability.

http://www.arin.net/meetings/minutes/ARIN_XX/ppm1_transcript.html#anchor
_7
Look for "MR. LI".

The problem is not that transit providers and large ISPs don't want
to upgrade.  They do like to test their equipment before they put
it into production, but mostly, they like that equipment to exist
before they design their network around it.

Buy Jason Schiller a drink and ask him about "routing to the left."
 
>                  The most likely response to the IPv4 routing
>                  scaling problem and the related shortage of
>                  IPv4 space (caused largely by the current BGP
>                  only system being unable to slice the space
>                  up finely without bloating the DFZ routing table)
>                  is a Core-Edge Separation solution such as LISP,
>                  APT, Ivip or TRRP.  (Six/One Router is also a
>                  Core Edge Separation solution, but it only works
>                  for IPv6.)  This could be used as the basis for a
>                  new kind of IPv4 global mobility.

Many people have advocated here for a split between routing 
identifier and host identifier.  Most were discussing IPv6.  I
don't think this forum can help much in that debate, look over 
there --------------------->  IETF


[long version read and skipped, because the short version was so
pithy]

> > will need IPv6 because other networks have run out of space, and 
> > because new deployments will have no choice.
> 
> I don't think they will "need" IPv6, because IPv6 does not 
> give them what their customers need: IPv4 connectivity.

No, they want "Internet" connectivity.  

> I think the costs of running dual stack and making it work 
> would be pretty high.  There are plenty of apps which don't 
> work with IPv6 and there are few servers on IPv6.

Yep, we've gotten ourselves into a fine mess.

> But what sort of configuration work, software upgraded, 
> complexities, flakiness, support calls etc. would be required 
> for ordinary end-users to run their home networks dual stack 
> successfully?

Any OS released after 2006?

> too high.  All a competitor has to do is advertise full IPv4 
> support, rather than the second-rate "Dual Stack Lite" 
> approach, and it would be much more difficult to attract and 
> retain customers, including those who didn't need uPnP IGD.

Yep, it's a fine mess.

> It could get this bad if there is no widely deployed 
> Core-Edge Scheme to solve the routing scaling problem (LISP, 
> APT, Ivip, TRRP or Six/One Router).  I predict it would get 
> this bad and still it would be cheaper to keep using IPv4 
> directly, or via "Dual Stack Lite" than to try and sell 
> customers a pure IPv6 service which is for an Internet most 
> people don't connect to.

Er, why is that the only translation mechanism you're including?

> I think you are saying that while networks would be able to 
> get IPv4 space for quite a long time, as people split it more 
> finely and use it more intensively, that this will cause 
> widespread adoption of
> IPv6 (either without any IPv4 NAT arrangement, or with the 
> address-efficient "Dual Stack Lite" approach), because the 
> RIB or perhaps FIB limitations of DFZ routers cause many 
> networks not to carry the whole DFZ routing table.
> 
> However, I have argued above that this is only likely to kick 
> in with the RIB of the transit routers with the most 
> neighbours - and that the providers who operate those will 
> always find it more viable to upgrade the router, or restrict 
> the number of neighbours, rather than offer incomplete connectivity.

Routing does not scale to 4 billion routes.  Don't know exactly
where hardware can't do it anymore.

If large network operators have to:
* spend millions for these new routers that I'm told don't exist, and 
* implement Dual Stack Lite, and 
* buy addresses from some market created out of a possible 
liberalized transfer policy, and
* NAT aggressively,

will that always be cheaper and provide better connectivity than 
IPv6 with translation technologies (tunnels, NAT-PT, teredo, 6to4, 
whatever: http://www.getipv6.info/index.php/Planning_IPv6_Deployment)
?


Lee


From sleibrand at internap.com  Tue Sep  2 17:51:28 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 02 Sep 2008 14:51:28 -0700
Subject: [arin-ppml] IPv4 is depleted today
In-Reply-To: <F24F22BEE0A241AC9A8C858366128C9B@tedsdesk>
References: <F24F22BEE0A241AC9A8C858366128C9B@tedsdesk>
Message-ID: <48BDB560.1070807@internap.com>

Ted Mittelstaedt wrote:
> 
>> Ted Mittelstaedt wrote:
>>
>>> It is imperative that our policy making strive to increase ease of 
>>> moving to IPv6 and decrease ease of staying with IPv4.
>>>
>>> A liberalized transfer policy does nothing to increase ease 
>>> of moving 
>>> to IPv6, all it does is make it easier to stay on IPv4.
 >>
>> I think you just identified a key point of disagreement / 
>> philosophical 
>> difference.
>>
>> To my mind the idea that "we need to adopt policy to make 
>> people's lives 
>> harder", in the interest of promoting our idea of their 
>> long-term best 
>> interest, is an extraordinary claim that requires 
>> extraordinary evidence 
>> that the benefits outweigh the harms.
>>
> 
> But nobody who is against a liberalized transfer policy is asking
> that we adopt ANYTHING.  They are asking that we DO NOT adopt
> anything.

Understood, but didn't you just say that we need to "decrease ease of 
staying with IPv4"?

>> I'm all in favor of easing the move to IPv6.  However, I 
>> think we also 
>> need to do what we can to ease the transition across the board.
>>
> 
> Your right.  I hope you define "transition" as I do, meaning
> in this instance CHANGE from IPv4 to IPv6, and NOT meaning
> continue to use IPv4 and ignoring IPv6.
> 
> Would you be willing to tie a liberalized policy to a requirement
> that the transferee (ie: the party that is obtaining the IPv4 as
> a result of a liberalized transfer) submit a transition plan to
> IPv6 to ARIN, and some reasonable proof that they were actually
> doing some of the items on it?  Such as obtaining IPv6 allocations
> from ARIN?  And such as providing the date their feed is going to
> natively route IPv6 and the date that they plan to do so as well?
> And maybe some mandatory followup by ARIN a few years later to
> insure these things are being done?

I supported such conditions in the Soft Landing proposal, and would not 
oppose them in a transfer policy.  However, the consensus seems to be that 
we should be removing restrictions from 2008-2, not adding them, so I'd 
need to see some community support for such conditions before I'd consider 
adding them to the proposal.

> If not, what a transfer policy does is allow the status quo to
> continue UNCHANGED.  That is NOT transition.

IMO transition is not something we can force.  Either it will happen or it 
won't, and at best we can only nudge things along slightly.  What we can 
do is make it easier to adopt v6, by lots of hard work fixing 
interoperability problems.  We can also take policy action to ease the 
transition and buy a little time while those problems are fixed.  IMO 
*not* doing everything we can on both fronts is an abdication of ARIN's 
stewardship responsibility.

-Scott

P.S. This will be my last post on this topic today.  If we haven't both 
made our positions clear, more message won't do the trick.  :)


From tedm at ipinc.net  Tue Sep  2 17:57:31 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 2 Sep 2008 14:57:31 -0700
Subject: [arin-ppml] Privacy rights & IP number whois ( was Re: The
	LRSA$100 fee...)
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E5A0@SUEXCL-02.ad.syr.edu>
Message-ID: <63486C1D644B4259A177B1A39C5D76CD@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
> Sent: Tuesday, September 02, 2008 9:30 AM
> To: James Hess; Tom Vest
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Privacy rights & IP number whois ( 
> was Re: The LRSA$100 fee...)
> 
> 
> 
> > -----Original Message-----
> > From: James Hess [mailto:mysidia at gmail.com]
> > 
> > In my view there is no legitimate privacy right protected 
> by allowing 
> > contact information to be witheld in _EITHER_ the case of DNS or IP 
> > whois. WHOIS proxy services should simply not be allowed by any 
> > registry.  Privacy deals with private, personal information.
> > The right to privacy is not a right to anonymity.   There 
> is no human
> > right to anonymity.
> 
> This is typical of the debates we went through on the DNS 
> side. I see we have perhaps another 10 years of work to do on 
> the address side. 
> 
> Like many people coming to these debates with limited 
> knowledge of the legal, historical and political aspects of 
> privacy and data protection debates, James presents us with a 
> series of oversimplified false
> dichotomies: either there is "no privacy at all" or "society 
> has no access to any information about the person," etc. 
> 
> But the law has dealt with this for ages, and it is perfectly 
> possible to have specific conditions under which specific 
> kinds of information are revealed to law enforcement or 
> others when necessary, following due process, without being 
> made publicly available indiscriminately. 
> 
> A simple example is drivers' license records. It is not legal 
> for anyone in the world to copy down someone's license plate 
> number and go to the Internet and look up their vehicle 
> registration record, and get their home address, phone 
> number, etc. Only police and law enforcement authorities can do that.
> 

That is a poor example since it's absolutely false.  DMV record
availability is set by the state governments in the US not feds
and it differs from state to state.  About 6-8 years ago in my 
state there were no restictions at all, none whatsoever and it
WAS perfectly legal to do this.

Nowadays, you have to go to the DMV, but you do not have to go
to law enforcement, and if you can make a good enough case
to the DMV people they will in fact give you the information.
I have done so recently in fact.  And this is if the vehicle is
a privately owned car.  If it is commercially owned then yes,
you absolutely have the right for this information, no questions
asked, and the DMV in my state will give it to you, no questions
asked.

> Do you think it should be different? 
> 

Owning a vehicle it is not possible for me to access every other
vehicle in the world.  I can easily access (ie: crash into) any
other vehicle on the road in my city, I can (with more effort)
touch most other vehicles in the US.  The further away I go with
my licensed vehicle, however, the more difficult it is to touch
other owner's vehicles.

With an IP address I can immediately access any other IP holder in
the world.

Thus, it is quite obvious that people in society have much more
right to information on IP address holders than they have on
people who own vehicles.

> With all due respect to James, the definition of privacy 
> rights is a legal issue, decided by legislatures, courts and 
> constitutions, not by technical administrators who think it's 
> convenient for them to have certain kinds of information, or 
> who concoct de novo theories about how using "public" 
> resources somehow eliminates all claims to privacy of the 
> person using it.
> 

The legislatures, courts and constitutions of different countries
in the world all differ greatly on this, and what laws there are
out there differ widely.  This kind of issue is what the United
Nations was created to solve.  And so far the UN has not issued
guidelines and directives on this for IP addresses.  They HAVE
done so for DNS names through WIPO on the issue of trademarks.

The UN moreover has a history of studiously avoiding issuance
of guidelines for things like this where the existing cooperative
infrastructure appears to be working.   In all liklyhood it will
NEVER get involved in dictating terms of whois for IP addresses.

So until such time as that happens from the UN, well then I am
sorry but it IS, in fact "up to technical adminstrators" not
up to a specific country's arbitrary and capricious laws,
because it is clearly a global, not a national, issue.

> Here's a good place to start investigating some aspects of 
> anonymity. http://www.eff.org/issues/anonymity  
> 
> Wrt to registration records, there is a clear distinction to 
> be made between individuals, which the law refers to as 
> natural persons, and "legal persons" which are not persons at 
> all but organizations. Privacy rights mostly inhere in 
> individuals, natural persons. This is well-established in 
> privacy law. However, organizations also have some weaker 
> rights to withhold information from public exposure. 
> 
> The other thing to keep in mind is that in Internet 
> governance you may be making decisions with global effect, 
> when national laws on the topic may vary. So unless you 
> believe you have a right to legislate for people in other 
> countries, you might want to approach the topic with a bit 
> more nuance and humility. 
> 

We are not legislating for people in other countries.  We
are legislating for a NETWORK that other countries have happened
to decide has value to connect to.

Any other country in the world is free to inplug itself from
the Internet.  North Korea certainly does so.  China also
filters heavily.  Other countries have limited their connections.
If they don't like the disclosure requirements we place on
the Internet then they can simply go away, and perhaps form
their own separate Internet.  And if they aren't going to
unplug and go away, and still aren't going to supply the
disclosure that is demanded, then we certainly can make that
obvious to the the rest of the administrators on the Internet,
who can then use this as criteria on what they want to block. 

> > What individuals do with domains and with IPs is no less a public 
> > manner than owning something like a public corporation.
> 
> That claim sounds pretty odd on the face of it.

It -is- odd because he is mixing IP's and DNS domains, which
are separate and different things.

> Someone has 
> an email address and it's the equivalent of being the trustee 
> of a publicly listed corporation drawing on millions of other 
> people's money? 
> 
> But if you really believe that, give me your mobile number, 
> go ahead and publish it on this list and let it be publicly 
> archived, because I don't see any difference between that and 
> a domain. 
>

Neither do it - however in your 2 paragraphs here you are
referring to domains, not IP addresses. 

Thanks,
Ted



From tedm at ipinc.net  Tue Sep  2 18:28:20 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 2 Sep 2008 15:28:20 -0700
Subject: [arin-ppml] IPv4 is depleted today
In-Reply-To: <48BDB560.1070807@internap.com>
Message-ID: <A385A5B6F3E7441BA0087AE04AAB7800@tedsdesk>



> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com] 
> Sent: Tuesday, September 02, 2008 2:51 PM
> To: Ted Mittelstaedt
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv4 is depleted today
> 
> 
> Ted Mittelstaedt wrote:
> > 
> >> Ted Mittelstaedt wrote:
> >>
> >>> It is imperative that our policy making strive to increase ease of
> >>> moving to IPv6 and decrease ease of staying with IPv4.
> >>>
> >>> A liberalized transfer policy does nothing to increase ease
> >>> of moving 
> >>> to IPv6, all it does is make it easier to stay on IPv4.
>  >>
> >> I think you just identified a key point of disagreement /
> >> philosophical 
> >> difference.
> >>
> >> To my mind the idea that "we need to adopt policy to make
> >> people's lives 
> >> harder", in the interest of promoting our idea of their 
> >> long-term best 
> >> interest, is an extraordinary claim that requires 
> >> extraordinary evidence 
> >> that the benefits outweigh the harms.
> >>
> > 
> > But nobody who is against a liberalized transfer policy is 
> asking that 
> > we adopt ANYTHING.  They are asking that we DO NOT adopt anything.
> 
> Understood, but didn't you just say that we need to "decrease ease of 
> staying with IPv4"?
> 

Our current policy naturally decreases ease of staying with IPv4
post IPv4 runout.  You might say that we already adopted an
anti-liberalized transfer policy years ago by not permitting people
to buy and sell IPv4 from day one.

However this is beside the point.  The fact is that some opponents of
a liberalized transfer policy wouldn't agree with my assertion that
our policymaking should decrease ease of staying with IPv4. The ones
that would agree don't want to mix opposition to a transfer policy with
advocacy of more stringent requirements for IPv4.  (at least, no one
who has opposed it as cited a reason for opposition is that they want
to put in a policy change making it more difficult, so I have to
conclude this)

Thus, the set of liberalized transfer policy opponents contains a lot
of people, some more and some less anti-IPv4, with different ideas on
how to do this, and therefore as I was explaining in the first place, you
cannot simply lump it all together into a big mass.


> >> I'm all in favor of easing the move to IPv6.  However, I
> >> think we also 
> >> need to do what we can to ease the transition across the board.
> >>
> > 
> > Your right.  I hope you define "transition" as I do, 
> meaning in this 
> > instance CHANGE from IPv4 to IPv6, and NOT meaning continue to use 
> > IPv4 and ignoring IPv6.
> > 
> > Would you be willing to tie a liberalized policy to a 
> requirement that 
> > the transferee (ie: the party that is obtaining the IPv4 as 
> a result 
> > of a liberalized transfer) submit a transition plan to IPv6 
> to ARIN, 
> > and some reasonable proof that they were actually doing some of the 
> > items on it?  Such as obtaining IPv6 allocations from ARIN? 
>  And such 
> > as providing the date their feed is going to natively route 
> IPv6 and 
> > the date that they plan to do so as well? And maybe some mandatory 
> > followup by ARIN a few years later to insure these things are being 
> > done?
> 
> I supported such conditions in the Soft Landing proposal, and 
> would not 
> oppose them in a transfer policy.  However, the consensus 
> seems to be that 
> we should be removing restrictions from 2008-2, not adding 
> them, so I'd 
> need to see some community support for such conditions before 
> I'd consider 
> adding them to the proposal.
> 

That's fine, but if we fail to reach consensus to adopt many 
different "son of liberalized transfer policies" time after time, then
I think after about the 3 or 4th iteration fails, your going to have to try
something different, regardless of what people seem to indicate.

I recognize the logical position for someone advocating a liberalized
transfer policy is to start by trying to push such a policy with
as few strings attached.  You don't compromise right out of the
box because you don't know yet if you can push it through without
the strings.  You only compromise when you fail.

> > If not, what a transfer policy does is allow the status quo to 
> > continue UNCHANGED.  That is NOT transition.
> 
> IMO transition is not something we can force.  Either it will 
> happen or it 
> won't, and at best we can only nudge things along slightly.  
> What we can 
> do is make it easier to adopt v6, by lots of hard work fixing 
> interoperability problems.  We can also take policy action to 
> ease the 
> transition and buy a little time while those problems are fixed.  IMO 
> *not* doing everything we can on both fronts is an abdication 
> of ARIN's 
> stewardship responsibility.
> 

The argument that we need more time assumes:

1) IPv6 isn't ready now
2) More time will result in it being ready

Both are huge, unsupported assumptions.  I often see these claims 
about IPv6 but I never see the people making such claims responding
with concrete, specific problems with IPv6 itself.  The closest
they usually get is in listing problems with deploying it, not
in using it after it's deployed.

Kind of like arguing against a specific model of tire for your
motorcycle because you have spoked rims, and require an innertube
to put the tire on, rather than because of the mileage, treadwear,
material, etc. etc. of the actual tire itself.

> -Scott
> 
> P.S. This will be my last post on this topic today.  If we 
> haven't both 
> made our positions clear, more message won't do the trick.  :)
> 

yep! :-)

Ted



From bill at herrin.us  Tue Sep  2 19:11:08 2008
From: bill at herrin.us (William Herrin)
Date: Tue, 2 Sep 2008 19:11:08 -0400
Subject: [arin-ppml] IPv4 is depleted today - unrealistic statements
	about IPv6 inevitability
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
References: <48BC99EE.9010509@firstpr.com.au>
	<369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
Message-ID: <3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>

On Tue, Sep 2, 2008 at 5:40 PM, Howard, W. Lee
<Lee.Howard at stanleyassociates.com> wrote:
> Those operators tell me there are no routers available or planned
> that can handle the projected volume of routes and updates.  One
> of the engineers for a router company you'll recognize told us about
> a year ago that Moore's Law is approaching its limits regarding
> routing scalability.
>
> http://www.arin.net/meetings/minutes/ARIN_XX/ppm1_transcript.html#anchor
> _7
> Look for "MR. LI".

Lee,

Robin and I have been working with Tony Li over on the Routing
Research Group for the past year or so. He's a smart guy but his
estimate is too low by at least an order of magnitude and possibly as
much as two.

The missing link is parallelism. Tony assumes we'll continue to
compute 100% of all routes on each uniprocessor MIPS system as Cisco
does today. On RRG, we've seen at least two viable methods of
introducing useful parallelism in a BGP-based system at a sublinear
increase in cost. They don't buy growth forever, but they buy a lot
more than Tony thinks.


> Routing does not scale to 4 billion routes.  Don't know exactly
> where hardware can't do it anymore.

Doesn't have to. As long as the /24 lower boundary on routability
holds, IPv4 will stay on a logarithmic growth curve that flattens out
somewhere around 7M or 8M routes. Given a Opteron-like dedicated
memory banks plus hypertransport architecture and some mild
improvements to the software that take advantage of multiprocessing
without substantively altering the BGP algorithm, we can build a
router that can handle 7M to 8M routes today and we'll be able to
build it cost-effectively by the time we need it. It'll be more
expensive that today's core routers, but it won't put you out of
business.

In other words, IPv6 is not the only choice. The best choice maybe,
but don't for an instant imagine that  properly motivated people can't
find a way to make the IPv4 Internet continue to grow.


> If large network operators have to [make IPv4 continue to work]
> will that always be cheaper and provide better connectivity than
> IPv6 with translation technologies (tunnels, NAT-PT, teredo, 6to4,
> whatever: http://www.getipv6.info/index.php/Planning_IPv6_Deployment)?

That approaches the real question: IPv6 migration has a cost function
and so does IPv4 growth. Where do the cost lines cross? When does it
become less expensive to deploy IPv6 and exert the push that brings
IPv4 to a close?

The plain truth is that we don't have enough data to do better than
guess at the answer to that question. But we do know that each IPv6
route costs 2 to 3 times as much to implement in the router as an IPv4
route. And we know that there is no new magic in IPv6 routing:
multihoming still requires a unique global route.

If I had to guess, I'd guess that the cost lines never cross. Even as
IPv4 gets more expensive, it remains more cost effective to squeeze a
little more out of it than to attempt an IPv6 migration. If I'm right,
it means that some successor technology that directly solves the
routing problem will leapfrog IPv6 in 10 or 20 years without IPv6 ever
having reached useful deployment or ever having paid back its early
adopters.


> Yep, we've gotten ourselves into a fine mess.

And that's the sad truth.

Regards,
Bill Herrin





-- 
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From mueller at syr.edu  Tue Sep  2 23:30:29 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 2 Sep 2008 23:30:29 -0400
Subject: [arin-ppml] Privacy rights & IP number whois
References: <63486C1D644B4259A177B1A39C5D76CD@tedsdesk>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9018841DE@SUEXCL-02.ad.syr.edu>




-----Original Message-----
From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
>That is a poor example since it's absolutely false.  DMV record
>availability is set by the state governments in the US not feds
>and it differs from state to state.

"Absolutely false" is a strong claim. My claim was that there is no state (and I made no claim about whether the law was federal or state) that allows anyone to look at a drivers license on the road and anonymously type it into an Internet-based database and receive, without any restriction on time, person, manner or purpose,  the name, address, email and telephone number of the person who registered that plate. I still don't think that claim is false, and as far as I can tell nothing has been said to refute it.

>About 6-8 years ago in my 
>state there were no restictions at all, none whatsoever and it
>WAS perfectly legal to do this.

I'd like to verify. Please name the state. 

Also: Where there were "no restrictions at all" was the access available anonymously via Internet? Was the data subject notified? Was a purpose requested? Was the requestor's information recorded? If the answer to the first question was "no" and to all the others "yes", then my assertion is verified, not refuted by your example. If the answer to the first question is "yes," do you think it unreasonable that they stopped doing that? Can you appreciate why they might have stopped doing that? These are honest, not rhetorical questions. I want to know why you would feel that it is important for Internet users not to be anonymous but you would support anonymous downloading and use of sensitive information. 

>I have done so recently in fact.  And this is if the vehicle is
>a privately owned car.  If it is commercially owned then yes,
>you absolutely have the right for this information, no questions
>asked, and the DMV in my state will give it to you, no questions
>asked.

But that's the legal person / natural person distinction. That's grounded in privacy law. And in either case, the DMV still has to verify who the owner is before you get any data, right? You don't get it anonymously off the Internet. 

>Thus, it is quite obvious that people in society have much more
>right to information on IP address holders than they have on
>people who own vehicles.

Perhaps you misinterpret what I am saying. I am not saying that there should be no address Whois. ARIN's IP address Whois, from a privacy standpoint, poses no serious problems today. It tells you which company has been assigned the address block and gives you contact info for that company. That is all it needs to do to fulfill its operational purpose, which is to maintain uniqueness and promote conservation and aggregation and other forms of routing stability. 

If there are criminal or even some civil problems with a specific internet user, IP Whois allows you to identify the operator and law enforcement can, using existing powers, subpoena the operator for additional identification or usage information about individual account holders at the operator. Due process. No problem with that. 

But ARIN's address Whois does not -- and, I hope you agree, should not -- tell anyone in the world who wants to know what Ted Middlstaedt's phone number is and what he did on the Internet last night, simply because they somehow got hold of your IP address number.  

I hope people on this list are aware of the Verizon v. RIAA case. It was all about IP address information and under what conditions it can be linked to a specific subscriber. http://www.eff.org/files/filenode/RIAA_v_Verizon/opinion-20031219.pdf 

As Verizon claimed at the time, the RIAA's position "opens the door for any person claiming to own a copyright to submit a one-page form to a clerk of a court and obtain the unlimited ability to collect private subscriber information" based on the collection of an IP address from a p2p site. 

>The legislatures, courts and constitutions of different countries
>in the world all differ greatly on this, and what laws there are
>out there differ widely.  This kind of issue is what the United
>Nations was created to solve.  And so far the UN has not issued
>guidelines and directives on this for IP addresses.

Are you inviting the UN to intervene in address policy? Shall I forward this message to the ITU and tell them that an ARIN ppml member really wants them to get involved?  

;-)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080902/dbf3cdc8/attachment.htm>

From stephen at sprunk.org  Wed Sep  3 00:42:48 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 02 Sep 2008 23:42:48 -0500
Subject: [arin-ppml] IPv4 is depleted today -
 unrealistic	statements	about IPv6 inevitability
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
Message-ID: <48BE15C8.50007@sprunk.org>

Howard, W. Lee wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robin Whittle
>> Sent: Monday, September 01, 2008 9:42 PM
>> To: ppml at arin.net
>> Subject: Re: [arin-ppml] IPv4 is depleted today - unrealistic 
>> statements about IPv6 inevitability
>>                  The only routers which will be affected
>>                  significantly by the growing number of DFZ routes
>>                  will be those of transit providers and large ISPs
>>                  where the routers have the highest number of
>>                  neighbours.  I believe the operators of those
>>                  routers will always find it better to upgrade or
>>                  replace those routers, or to limit the number of
>>                  neighbours they connect to, rather than drop some
>>                  DFZ routes and therefore provide a second-rate
>>                  service.
>>     
>
> Those operators tell me there are no routers available or planned
> that can handle the projected volume of routes and updates.  One
> of the engineers for a router company you'll recognize told us about
> a year ago that Moore's Law is approaching its limits regarding
> routing scalability.
>
> http://www.arin.net/meetings/minutes/ARIN_XX/ppm1_transcript.html#anchor
> _7
> Look for "MR. LI".
>   

With all due respect to Tony (and I mean that sincerely), it seems like 
every year I've been in the tech biz, someone is shouting that the sky 
is falling and we've finally hit the wall on Moore's Law, yet a year 
later some other person has come up with a magical solution that saves 
us all and puts that particular crisis off for another year or two.  I 
hate to rely on that trend continuing, but given the track record so 
far, I find it hard to believe otherwise, despite Tony's statistics.  I 
remember when folks were telling us x86 CPUs couldn't run faster than 
100MHz, and they had lots of great statistics too, yet now the same 
folks are talking about how the 4GHz barrier is insurmountable...

> The problem is not that transit providers and large ISPs don't want
> to upgrade.  They do like to test their equipment before they put
> it into production, but mostly, they like that equipment to exist
> before they design their network around it.
>
> Buy Jason Schiller a drink and ask him about "routing to the left."
>  
>   
>>                  The most likely response to the IPv4 routing
>>                  scaling problem and the related shortage of
>>                  IPv4 space (caused largely by the current BGP
>>                  only system being unable to slice the space
>>                  up finely without bloating the DFZ routing table)
>>                  is a Core-Edge Separation solution such as LISP,
>>                  APT, Ivip or TRRP.  (Six/One Router is also a
>>                  Core Edge Separation solution, but it only works
>>                  for IPv6.)  This could be used as the basis for a
>>                  new kind of IPv4 global mobility.
>>     
>
> Many people have advocated here for a split between routing 
> identifier and host identifier.  Most were discussing IPv6.  I
> don't think this forum can help much in that debate, look over 
> there --------------------->  IETF
>   

ITYM the RRG of the IRTF.  The output of that work will eventually make 
it to the IETF for standardization.

>> But what sort of configuration work, software upgraded, 
>> complexities, flakiness, support calls etc. would be required 
>> for ordinary end-users to run their home networks dual stack 
>> successfully?
>>     
>
> Any OS released after 2006?
>   

That ignores all the apps and CPE devices (mostly DSL/cable "modems", 
which have an integrated NAT/FW function) that don't understand IPv6.  
Even if upgrades were available, which in most cases are not, you still 
have to get all the users to install them...

Or, we could just get NAT-PT working.  At least one vendor is already 
shipping it.

S


From stephen at sprunk.org  Wed Sep  3 00:47:22 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 02 Sep 2008 23:47:22 -0500
Subject: [arin-ppml] IPv4 is depleted today - unrealistic
 statements	about IPv6 inevitability
In-Reply-To: <3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
References: <48BC99EE.9010509@firstpr.com.au>	<369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
	<3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
Message-ID: <48BE16DA.6040707@sprunk.org>

William Herrin wrote:
> On Tue, Sep 2, 2008 at 5:40 PM, Howard, W. Lee
> <Lee.Howard at stanleyassociates.com> wrote:
>   
>> If large network operators have to [make IPv4 continue to work] will that always be cheaper and provide better connectivity than IPv6 with translation technologies (tunnels, NAT-PT, teredo, 6to4, whatever: http://www.getipv6.info/index.php/Planning_IPv6_Deployment)?
>>     
>
> That approaches the real question: IPv6 migration has a cost function and so does IPv4 growth. Where do the cost lines cross? When does it become less expensive to deploy IPv6 and exert the push that brings IPv4 to a close?
>
> The plain truth is that we don't have enough data to do better than guess at the answer to that question. But we do know that each IPv6 route costs 2 to 3 times as much to implement in the router as an IPv4 route.
>   

Yes, one IPv6 route is more expensive than one IPv4 route, due to the 
simple fact that they're longer.  However, it is expected (with a 
reasonable basis) that each org will have fewer IPv6 routes because the 
RIRs are deliberately giving each org far more space than they should 
ever need, plus reserving plenty of room for unexpected growth.  We're 
looking at an order of magnitude reduction, at least, in the number of 
routes in the DFZ if the current folks using PIv4 switched to PIv6.  Of 
course, the natural result is that more orgs will be allowed to get PIv6 
space, but then you're no longer comparing apples to apples.

> And we know that there is no new magic in IPv6 routing: multihoming still requires a unique global route.
>   

For now.  The RRG is working on that part of the problem.

> If I had to guess, I'd guess that the cost lines never cross. Even as IPv4 gets more expensive, it remains more cost effective to squeeze a little more out of it than to attempt an IPv6 migration. If I'm right, it means that some successor technology that directly solves the routing problem will leapfrog IPv6 in 10 or 20 years without IPv6 ever having reached useful deployment or ever having paid back its early adopters.
>   

I think your statement is true if you look at it from a short-term cost 
perspective each quarter, but not if you look at the long-term costs.

S


From michael.dillon at bt.com  Wed Sep  3 04:53:14 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 3 Sep 2008 09:53:14 +0100
Subject: [arin-ppml] IPv4 is depleted today
In-Reply-To: <48BD9223.4030606@internap.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC07DAB945@E03MVZ2-UKDY.domain1.systemhost.net>


> A liberalized transfer policy does nothing to increase ease of moving 
> to IPv6, all it does is make it easier to stay on IPv4.

It forces companies to spend money on IP addresses thus reducing
the amount they have available for capex and opex. How does this
make it easier to stay on IPv4? In particular, in all but the 
smallest ISPs, it now forces the addressing people to ask for
money that they did not have to ask for before. It is one thing
to have a recurring budget item for up to $18,000 per year
for ARIN subscription fees. It is quite another thing to ask
for a one-time figure which is probably quite a bit higher, to
buy something that used to be free and included in the annual fee.

Just explaining it all to management is going to be one
big pain in the rear.

For this and other reasons, transfer policies are a bad bad thing.

--Michael Dillon


From michael.dillon at bt.com  Wed Sep  3 05:05:11 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 3 Sep 2008 10:05:11 +0100
Subject: [arin-ppml] Unique route?
In-Reply-To: <3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC07DAB98B@E03MVZ2-UKDY.domain1.systemhost.net>

>  And we know that 
> there is no new magic in IPv6 routing:
> multihoming still requires a unique global route.

Not true. The route does not need to be global. There are ways to do
this with two ISPs who peer locally and cooperate to keep the traffic
flowing without actually announcing the multihomed customer's individual
route globally. Instead there is an aggregate route being announce by
both and this aggregate holds multiple multihomed customers.

Obviously, this solves the route table problem by combining a technical
action and a business action into a total solution. It's not the thing
operations people normally think of because they are not involved in the
commercial side of the business or any partnerships beyond vanilla
peering agreements.

IPv6 does contain a bit of magic here because address space is plentiful
enough that an ISP could carve off a big chunk of space to use for such
a multihoming service without worrying that it will impact their usage
stats for the next ARIN application in 6 months. That is serious magic.

--Michael Dillon


From jcurran at istaff.org  Wed Sep  3 05:58:29 2008
From: jcurran at istaff.org (John Curran)
Date: Wed, 3 Sep 2008 05:58:29 -0400
Subject: [arin-ppml] IPv4 is depleted today - unrealistic statements
	about IPv6 inevitability
In-Reply-To: <3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
References: <48BC99EE.9010509@firstpr.com.au>
	<369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
	<3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
Message-ID: <7F4C91E5-4858-45E6-A865-A2EAA17C654D@istaff.org>

On Sep 2, 2008, at 7:11 PM, William Herrin wrote:
> Doesn't have to. As long as the /24 lower boundary on routability
> holds, IPv4 will stay on a logarithmic growth curve that flattens out
> somewhere around 7M or 8M routes.

Just for my understanding, why would /24 remain a realistic lower
boundary?  Is this assertion based on an assumption that (all) ISP's
in a post-depletion situation will turn away prospects who show up
with a /25 or smaller IP block?

/John


From lear at cisco.com  Wed Sep  3 08:00:13 2008
From: lear at cisco.com (Eliot Lear)
Date: Wed, 03 Sep 2008 14:00:13 +0200
Subject: [arin-ppml] Unique route?
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC07DAB98B@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC07DAB98B@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <48BE7C4D.1030701@cisco.com>

michael.dillon at bt.com wrote:
>>   And we know that
>> there is no new magic in IPv6 routing:
>> multihoming still requires a unique global route.
>>      
>
> Not true. The route does not need to be global. There are ways to do
> this with two ISPs who peer locally and cooperate to keep the traffic
> flowing without actually announcing the multihomed customer's individual
> route globally. Instead there is an aggregate route being announce by
> both and this aggregate holds multiple multihomed customers.
>
> Obviously, this solves the route table problem by combining a technical
> action and a business action into a total solution. It's not the thing
> operations people normally think of because they are not involved in the
> commercial side of the business or any partnerships beyond vanilla
> peering agreements.
>    

It's not the thing business people normally think of either, because a 
serious concern they have is lock-in, and this doesn't solve that on its 
own.  Let us agree that there is no "one size fits all" approach, and 
then we can apply some assumptions that argue in favor of geographically 
assigned addresses (which is really where your proposal leads).  There 
is a reasonable argument that such addressing is scalable from a routing 
system standpoint, if you can get to that state.  To the best of my 
knowledge, nobody has gotten to that state.

Eliot


From farmer at umn.edu  Wed Sep  3 09:20:11 2008
From: farmer at umn.edu (David Farmer)
Date: Wed, 03 Sep 2008 08:20:11 -0500
Subject: [arin-ppml] the Transfer Policy Argument Space
Message-ID: <48BE48BB.29942.2FA0005@farmer.umn.edu>

I'm hearing many different arguments related to the transfer policy.  I've 
come to the conclusion that this is a very complicated argument space we 
are dealing with and I don't think everyone is seeing the whole argument 
landscape, I know I'm having problems with this.  As things exist currently, 
I'm not sure we can come to any consensus, not even a consensus to drop 
the issue.

Therefore, in this thread I would like some help to map out the argument 
space we are working with.  I would like us to intentionally simplify the 
arguments and gloss over many of the nuances.  What I'm asking for us to 
do is map out the breath and shape of the argument space we are dealing 
with here, rather than to perfectly capture the nuances of each argument.

If you want to argue the merits of some part of the argument, please do that 
as part of another thread.  If possible I would like help in this thread to 
clearly and dispassionately state the various parts of the argument, not to 
argue it.

So to that end, I'm going try to start, this is only a start, please help by 
adding or refining the arguments, but argue them in different threads please:

1. IPv6 is a failure and can not succeed, therefore we must extend the life of 
IPv4 indefinitely beyond free poll exhaustion, a transfer policy is part of that;

2. IPv6 will eventually succeed, however we need to keep IPv4 viable until 
the transiton is complete, a transfer policy will help keep IPv4 viable beyond  
free poll exhaustion;

3. IPv6 will eventually succeed, but only if there is a forcing function to move 
people from IPv4, free poll exhaustion is this forcing function;



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From bmanning at vacation.karoshi.com  Wed Sep  3 09:48:00 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 3 Sep 2008 13:48:00 +0000
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <48BE48BB.29942.2FA0005@farmer.umn.edu>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
Message-ID: <20080903134800.GA19106@vacation.karoshi.com.>

> 1. IPv6 is a failure and can not succeed, therefore we must extend the life of 
> IPv4 indefinitely beyond free poll exhaustion, a transfer policy is part of that;
> 
> 2. IPv6 will eventually succeed, however we need to keep IPv4 viable until 
> the transiton is complete, a transfer policy will help keep IPv4 viable beyond  
> free poll exhaustion;
> 
> 3. IPv6 will eventually succeed, but only if there is a forcing function to move 
> people from IPv4, free poll exhaustion is this forcing function;
> 
> 

David,

	how about lets leave IPv6 (mostly) out of the discussion?

) IPv4 will continue to be used/useful for the next N years (N==10-20). 

) Demand for IPv4 has outstripped supply.

) Until viable alternatives become available, the trend will be to find 
  more efficent ways to use the IPv4 pool.


--bill


From michael.dillon at bt.com  Wed Sep  3 09:51:46 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 3 Sep 2008 14:51:46 +0100
Subject: [arin-ppml] Unique route?
In-Reply-To: <48BE7C4D.1030701@cisco.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC07DABF87@E03MVZ2-UKDY.domain1.systemhost.net>

>  Let us agree that there is no 
> "one size fits all" approach, and then we can apply some 
> assumptions that argue in favor of geographically assigned 
> addresses (which is really where your proposal leads).  There 
> is a reasonable argument that such addressing is scalable 
> from a routing system standpoint, if you can get to that 
> state.  To the best of my knowledge, nobody has gotten to that state.

Now you are beginning to see where the magic is in IPv6, at least
potentially. Because there is a huge unallocated address space, we
really can get away from "one size fits all" and enable some
people to make it work.

--Michael Dillon


From bill at herrin.us  Wed Sep  3 09:53:48 2008
From: bill at herrin.us (William Herrin)
Date: Wed, 3 Sep 2008 09:53:48 -0400
Subject: [arin-ppml] IPv4 is depleted today - unrealistic statements
	about IPv6 inevitability
In-Reply-To: <48BE16DA.6040707@sprunk.org>
References: <48BC99EE.9010509@firstpr.com.au>
	<369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
	<3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
	<48BE16DA.6040707@sprunk.org>
Message-ID: <3c3e3fca0809030653m542be62fn89b201875fd02a6a@mail.gmail.com>

On Wed, Sep 3, 2008 at 5:58 AM, John Curran <jcurran at istaff.org> wrote:
> Just for my understanding, why would /24 remain a realistic lower
> boundary?  Is this assertion based on an assumption that (all) ISP's
> in a post-depletion situation will turn away prospects who show up
> with a /25 or smaller IP block?

John,

It's pretty hard to change. Nearly all of the 30k or so ASes filter at
the /24 boundary today and you'd need nearly all of them to change in
order to support the smaller blocks at the same time as cost pressure
from the growing routing table strongly encourages them to look for
ways to accept fewer routes instead of more.


On Wed, Sep 3, 2008 at 12:47 AM, Stephen Sprunk <stephen at sprunk.org> wrote:
> Yes, one IPv6 route is more expensive than one IPv4 route, due to the simple
> fact that they're longer.  However, it is expected (with a reasonable basis)
> that each org will have fewer IPv6 routes because the RIRs are deliberately
> giving each org far more space than they should ever need, plus reserving
> plenty of room for unexpected growth.  We're looking at an order of
> magnitude reduction, at least, in the number of routes in the DFZ if the
> current folks using PIv4 switched to PIv6.

Stephen,

No, we're not looking at an order of magnitude reduction. That's a
fantasy. After factoring in traffic engineering and multihoming
(neither of which have new magic in IPv6), the best case scenario is
that disaggregation drops from the current 8:1 to a little over 2:1.
Those gains are erased at the starting gate by the longer address
size.


>> And we know that there is no new magic in IPv6 routing: multihoming still
>> requires a unique global route.
>
> For now.  The RRG is working on that part of the problem.

Yes, we are. Shall I tell you what we've found so far?

We've found three broad categories of solutions:

1. Map-encap monolithic push
2. Map-encap pull-cache
3. Total dynamic addressing


Map-encap monolithic push

Map-encap monolithic push is essentially MPLS but in the inter-domain
space. Each AS pushes the minimum number of routes to satisfy
resilience and traffic engineering. All IPv4 and IPv6 prefixes are
then mapped to those routes through an alternate and much more static
distribution system. Packets are encapsulated (think: labeled) in a
tunnel packet which is delivered to the remote AS before
decapsulation.

If you believe as Tony does that the RIB is the first bottleneck, this
approach brings IPv4 routing in line with the best case scenario for
IPv6 routing at a much lower cost than deploying IPv6. Unfortunately,
it does jack for the FIB in either IPv4 or IPv6. Every router at the
border of the core still has to carry and process a full table.


Map-encap pull-cache

Pull-cache takes things another step. Origin-only ASes need no longer
orignate any routes into the system and transit ASes need only
originate one. Traffic engineering is moved into the map, sections of
which are queried (pulled) as needed by small map-encap routers near
the edge. Those routers label the packets with one of the destination
ASes which can handle local delivery.

Since no one router has to deal with the full table, this solves both
the RIB and FIB problems for both IPv4 and IPv6 down to a /32 and /128
level respectively at an expense much less than deploying IPv6. The
problem with this approach is that it requires a DNS-like delay to
pull and cache the map entry when two distant hosts first initiate
communication.


Total dynamic addressing

Do away with static address block assignment entirely. Your ISP
assigns and changes your addresses during operation at its
convenience. This dynamic address assignment is carried directly in
the routing protocol. The same thing happens to it upstream. As the
machine count grows, you get new assignments and the old addresses
rapidly expire. As a small multihomed user you get multiple addresses,
one from each upstream and run a route policy protocol so that
individual machines can make a reasonable choice about which address
to use for any given packet. The largest of users with many
interconnections (the current transit ASes) get their dynamically
assigned and dynaically changed block from a central authority and
route it with a BGP-like protocol.

Total dynamic addressing is a clean-slate solution. To make it work,
we have to jettison TCP and UDP. Layer 4 protocols and above have to
be redesigned to accomodate the fact that the layer-3 addresses no
longer identify the machine in any respect. The layer-3 addresses can
serve only to describe the machine's ephemeral location in the global
network graph.

With this approach, there's no reason the route count would ever again
top 100,000. It's a successor protocol to both IPv4 and IPv6. It
could, in theory, bootstrap itself on any existing IPv4 or IPv6
infrastructure since layer 4 and up care no more about layer 3 than
layer 3 cares about layer 2. But that's the closest relationship it
has with either IPv4 or IPv6.


Here's the thing I want you to realize: deploying IPv6 doesn't help
you with any of the three approaches. The first two solve the routing
problem for both IPv4 and IPv6 while the latter replaces both
protocols. We haven't found -any- realistic approaches to the routing
problem for which IPv6 offers more than a mild convenience versus
doing the same thing with IPv4.


Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bmanning at vacation.karoshi.com  Wed Sep  3 09:57:05 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 3 Sep 2008 13:57:05 +0000
Subject: [arin-ppml] IPv4 is depleted today - unrealistic statements
	about IPv6 inevitability
In-Reply-To: <3c3e3fca0809030653m542be62fn89b201875fd02a6a@mail.gmail.com>
References: <48BC99EE.9010509@firstpr.com.au>
	<369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
	<3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
	<48BE16DA.6040707@sprunk.org>
	<3c3e3fca0809030653m542be62fn89b201875fd02a6a@mail.gmail.com>
Message-ID: <20080903135705.GA19327@vacation.karoshi.com.>

 can't speak for the 30k ASN's out there, but the couple dozen I have
touched in the past decade or so are perfectly willing to take a /25 
from me... most will not transit it though.

--bill


On Wed, Sep 03, 2008 at 09:53:48AM -0400, William Herrin wrote:
> On Wed, Sep 3, 2008 at 5:58 AM, John Curran <jcurran at istaff.org> wrote:
> > Just for my understanding, why would /24 remain a realistic lower
> > boundary?  Is this assertion based on an assumption that (all) ISP's
> > in a post-depletion situation will turn away prospects who show up
> > with a /25 or smaller IP block?
> 
> John,
> 
> It's pretty hard to change. Nearly all of the 30k or so ASes filter at
> the /24 boundary today and you'd need nearly all of them to change in
> order to support the smaller blocks at the same time as cost pressure
> from the growing routing table strongly encourages them to look for
> ways to accept fewer routes instead of more.
> 
> 
> On Wed, Sep 3, 2008 at 12:47 AM, Stephen Sprunk <stephen at sprunk.org> wrote:
> > Yes, one IPv6 route is more expensive than one IPv4 route, due to the simple
> > fact that they're longer.  However, it is expected (with a reasonable basis)
> > that each org will have fewer IPv6 routes because the RIRs are deliberately
> > giving each org far more space than they should ever need, plus reserving
> > plenty of room for unexpected growth.  We're looking at an order of
> > magnitude reduction, at least, in the number of routes in the DFZ if the
> > current folks using PIv4 switched to PIv6.
> 
> Stephen,
> 
> No, we're not looking at an order of magnitude reduction. That's a
> fantasy. After factoring in traffic engineering and multihoming
> (neither of which have new magic in IPv6), the best case scenario is
> that disaggregation drops from the current 8:1 to a little over 2:1.
> Those gains are erased at the starting gate by the longer address
> size.
> 
> 
> >> And we know that there is no new magic in IPv6 routing: multihoming still
> >> requires a unique global route.
> >
> > For now.  The RRG is working on that part of the problem.
> 
> Yes, we are. Shall I tell you what we've found so far?
> 
> We've found three broad categories of solutions:
> 
> 1. Map-encap monolithic push
> 2. Map-encap pull-cache
> 3. Total dynamic addressing
> 
> 
> Map-encap monolithic push
> 
> Map-encap monolithic push is essentially MPLS but in the inter-domain
> space. Each AS pushes the minimum number of routes to satisfy
> resilience and traffic engineering. All IPv4 and IPv6 prefixes are
> then mapped to those routes through an alternate and much more static
> distribution system. Packets are encapsulated (think: labeled) in a
> tunnel packet which is delivered to the remote AS before
> decapsulation.
> 
> If you believe as Tony does that the RIB is the first bottleneck, this
> approach brings IPv4 routing in line with the best case scenario for
> IPv6 routing at a much lower cost than deploying IPv6. Unfortunately,
> it does jack for the FIB in either IPv4 or IPv6. Every router at the
> border of the core still has to carry and process a full table.
> 
> 
> Map-encap pull-cache
> 
> Pull-cache takes things another step. Origin-only ASes need no longer
> orignate any routes into the system and transit ASes need only
> originate one. Traffic engineering is moved into the map, sections of
> which are queried (pulled) as needed by small map-encap routers near
> the edge. Those routers label the packets with one of the destination
> ASes which can handle local delivery.
> 
> Since no one router has to deal with the full table, this solves both
> the RIB and FIB problems for both IPv4 and IPv6 down to a /32 and /128
> level respectively at an expense much less than deploying IPv6. The
> problem with this approach is that it requires a DNS-like delay to
> pull and cache the map entry when two distant hosts first initiate
> communication.
> 
> 
> Total dynamic addressing
> 
> Do away with static address block assignment entirely. Your ISP
> assigns and changes your addresses during operation at its
> convenience. This dynamic address assignment is carried directly in
> the routing protocol. The same thing happens to it upstream. As the
> machine count grows, you get new assignments and the old addresses
> rapidly expire. As a small multihomed user you get multiple addresses,
> one from each upstream and run a route policy protocol so that
> individual machines can make a reasonable choice about which address
> to use for any given packet. The largest of users with many
> interconnections (the current transit ASes) get their dynamically
> assigned and dynaically changed block from a central authority and
> route it with a BGP-like protocol.
> 
> Total dynamic addressing is a clean-slate solution. To make it work,
> we have to jettison TCP and UDP. Layer 4 protocols and above have to
> be redesigned to accomodate the fact that the layer-3 addresses no
> longer identify the machine in any respect. The layer-3 addresses can
> serve only to describe the machine's ephemeral location in the global
> network graph.
> 
> With this approach, there's no reason the route count would ever again
> top 100,000. It's a successor protocol to both IPv4 and IPv6. It
> could, in theory, bootstrap itself on any existing IPv4 or IPv6
> infrastructure since layer 4 and up care no more about layer 3 than
> layer 3 cares about layer 2. But that's the closest relationship it
> has with either IPv4 or IPv6.
> 
> 
> Here's the thing I want you to realize: deploying IPv6 doesn't help
> you with any of the three approaches. The first two solve the routing
> problem for both IPv4 and IPv6 while the latter replaces both
> protocols. We haven't found -any- realistic approaches to the routing
> problem for which IPv6 offers more than a mild convenience versus
> doing the same thing with IPv4.
> 
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From kkargel at polartel.com  Wed Sep  3 10:06:44 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 3 Sep 2008 09:06:44 -0500
Subject: [arin-ppml] IPv4 is depleted today - unrealistic
	statementsabout IPv6 inevitability
In-Reply-To: <7F4C91E5-4858-45E6-A865-A2EAA17C654D@istaff.org>
References: <48BC99EE.9010509@firstpr.com.au><369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com><3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
	<7F4C91E5-4858-45E6-A865-A2EAA17C654D@istaff.org>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AAE@mail>

 Absolutely, we do that today..

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of John Curran
Sent: Wednesday, September 03, 2008 4:58 AM
To: William Herrin
Cc: ppml at arin.net
Subject: Re: [arin-ppml] IPv4 is depleted today - unrealistic
statementsabout IPv6 inevitability

On Sep 2, 2008, at 7:11 PM, William Herrin wrote:
> Doesn't have to. As long as the /24 lower boundary on routability 
> holds, IPv4 will stay on a logarithmic growth curve that flattens out 
> somewhere around 7M or 8M routes.

Just for my understanding, why would /24 remain a realistic lower boundary?
Is this assertion based on an assumption that (all) ISP's in a
post-depletion situation will turn away prospects who show up with a /25 or
smaller IP block?

/John
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public
Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080903/edc5dd8e/attachment.bin>

From iljitsch at muada.com  Wed Sep  3 10:10:20 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 3 Sep 2008 16:10:20 +0200
Subject: [arin-ppml] IPv4 is depleted today -
	unrealistic	statements	about IPv6 inevitability
In-Reply-To: <48BE15C8.50007@sprunk.org>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
	<48BE15C8.50007@sprunk.org>
Message-ID: <501873EC-846F-4145-AEC6-E882196D7238@muada.com>

On 3 sep 2008, at 6:42, Stephen Sprunk wrote:

> it seems like
> every year I've been in the tech biz, someone is shouting that the sky
> is falling and we've finally hit the wall on Moore's Law, yet a year
> later some other person has come up with a magical solution that saves
> us all and puts that particular crisis off for another year or two.

The sky isn't falling but there's also no magical solution. We know  
that if we increased the number of prefixes in BGP by, say, 2 or 4  
times overnight, large parts of the internet would fail. We don't have  
anything that keeps this from happening except the expectation that  
tomorrow won't be _too_ different from today.

After the IAB routing and addressing workshop where Tony talked about  
this stuff several people from router vendors came out and said they  
can (some even do) build routers that can handle 2 million prefixes:  
nearly 8 times the IPv4 table that we have today. Presumably, those  
routers will be in place by the time we hit that many prefixes. But  
all the lines keep going up, and the "bad" ones (that we don't  
control) cross the "good" ones (that we do control) at some point.  
This is not an immediate issue, but it does pose a problem in the  
future.

> I remember when folks were telling us x86 CPUs couldn't run faster  
> than
> 100MHz, and they had lots of great statistics too, yet now the same
> folks are talking about how the 4GHz barrier is insurmountable...

And during the last bubble people thought we'd never again have an  
economic downturn...

>>> But what sort of configuration work, software upgraded,
>>> complexities, flakiness, support calls etc. would be required
>>> for ordinary end-users to run their home networks dual stack
>>> successfully?

A local IPv6 router. Apple sells one that's also a pretty nice wifi  
base station and a rather slow file server.

Plus, if you have Windows XP, a single command line command or  
fiddling with the network settings a bit.

IPv6-only is harder.

> That ignores all the apps and CPE devices (mostly DSL/cable "modems",
> which have an integrated NAT/FW function) that don't understand IPv6.
> Even if upgrades were available, which in most cases are not, you  
> still
> have to get all the users to install them...

> Or, we could just get NAT-PT working.  At least one vendor is already
> shipping it.

NAT-PT means that you run IPv6-only locally and you connect to IPv4  
servers through a translator. This means you must be able to do DNS  
lookups over IPv6 (which XP can't do and MacOS can't autoconfigure)  
and have IPv6 connectivity, so your CPE must support it. In other  
words: it doesn't solve any of the issues you mention in the previous  
paragraph.


From vixie at isc.org  Wed Sep  3 10:11:26 2008
From: vixie at isc.org (Paul Vixie)
Date: Wed, 03 Sep 2008 14:11:26 +0000
Subject: [arin-ppml] IPv4 is depleted today - unrealistic statements
	about IPv6 inevitability
In-Reply-To: Your message of "Tue, 02 Sep 2008 19:11:08 -0400."
	<3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com> 
References: <48BC99EE.9010509@firstpr.com.au>
	<369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>
	<3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com> 
Message-ID: <6335.1220451086@nsa.vix.com>

[lee howard]
> http://www.arin.net/meetings/minutes/ARIN_XX/ppm1_transcript.html#anchor_7
> Look for "MR. LI".

[bill herrin]
> Robin and I have been working with Tony Li over on the Routing Research
> Group for the past year or so. He's a smart guy but his estimate is too
> low by at least an order of magnitude and possibly as much as two.

wouldn't any new technology already have to be on the price lists, if not
also actually shipping, in order to have any impact within the time frame
we're concerned about?

> The missing link is parallelism. Tony assumes we'll continue to compute
> 100% of all routes on each uniprocessor MIPS system as Cisco does today.
> On RRG, we've seen at least two viable methods of introducing useful
> parallelism in a BGP-based system at a sublinear increase in cost. They
> don't buy growth forever, but they buy a lot more than Tony thinks.

what are the scaling properties of that proposed design?  how many FIB and
RIB entries at what churn rate could we assume was reasonable in "tier 1"
after how many years from now?  will there be such a disconnect in the next
generation of routers that there will be no "hand me down" effect from the
current "tier 1" to edges, customers, and competitors?

does parallelism at the node level get us to the point where the speed of
light isn't enough for route propagation among the number of routes and
nodes we can have, and the whole thing gets to what reciprocating engine
people call "valve float" where convergence never occurs?

> > Routing does not scale to 4 billion routes.  Don't know exactly
> > where hardware can't do it anymore.
> 
> Doesn't have to. As long as the /24 lower boundary on routability
> holds, IPv4 will stay on a logarithmic growth curve that flattens out
> somewhere around 7M or 8M routes.

why do you think a /24 is the lower boundary that "the market" would yield?

> ... In other words, IPv6 is not the only choice. ...

i'd like to discuss your antecedents further before arguing that conclusion.

note that if RRG has dissenting views, then someone who disagrees with tony
li's views from denver, could ask for a speaking slot in los angeles.  the
community ought to be open to well reasoned arguments from many perspectives.


From Lee.Howard at stanleyassociates.com  Wed Sep  3 10:17:27 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Wed, 3 Sep 2008 10:17:27 -0400
Subject: [arin-ppml] IPv4 is depleted today - unrealistic statements
	about IPv6 inevitability
In-Reply-To: <3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>

[good work is being done on routing scalability] > They don't 
> buy growth forever, but they buy a lot more than Tony thinks.

Great!  Can I (if I were a major ISP) buy 10 routers using this
architecture in time to design, test, and deploy before the
inflation of the routing table presumed in this thread?

 
> > Routing does not scale to 4 billion routes.  Don't know 
> exactly where 
> > hardware can't do it anymore.
> 
> Doesn't have to. As long as the /24 lower boundary on 
> routability holds, IPv4 will stay on a logarithmic growth 
> curve that flattens out somewhere around 7M or 8M routes. 

Is that a fair assumption?  The argument I thought I was 
reading said that aggressive deaggregation was easier and
cheaper than deploying IPv6.


> In other words, IPv6 is not the only choice. The best choice 
> maybe, but don't for an instant imagine that  properly 
> motivated people can't find a way to make the IPv4 Internet 
> continue to grow.

I do indeed imagine that.  It keeps me awake at night.  We're
using different constraints on the term "IPv4 Internet" though.

 
> > If large network operators have to [make IPv4 continue to 
> work] will 
> > that always be cheaper and provide better connectivity than
> > IPv6 with translation technologies (tunnels, NAT-PT, teredo, 6to4,
> > whatever: 
> http://www.getipv6.info/index.php/Planning_IPv6_Deployment)?
> 
> That approaches the real question: IPv6 migration has a cost 
> function and so does IPv4 growth. Where do the cost lines 
> cross? When does it become less expensive to deploy IPv6 and 
> exert the push that brings
> IPv4 to a close?
> 
> The plain truth is that we don't have enough data to do 
> better than guess at the answer to that question. 

I agree with your question.  What data would we need?  Is it 
possible to get such data, so network operators will be able
to make well-informed design and purchasing decisions?

> But we do 
> know that each IPv6 route costs 2 to 3 times as much to 
> implement in the router as an IPv4 route. And we know that 
> there is no new magic in IPv6 routing:
> multihoming still requires a unique global route.

True, but in IPv6 it's likely to require only one unique global
route, unlike the fragments of CIDR space seen in IPv4.  I saw
in another post you believe it could go from 8:1 to 2:1, which 
gain is largely removed be the address space overhead.  I still
think deaggregation is a stupid way to do TE, and that BGP needs
another knob for that purpose, but I understand the difficulty
in getting that knob adopted (unless somebody important decides
to suppress more-specifics where an aggregate is announced and
otherwise override deaggregation TE).

> If I had to guess, I'd guess that the cost lines never cross. Even as
> IPv4 gets more expensive, it remains more cost effective to 
> squeeze a little more out of it than to attempt an IPv6 
> migration. If I'm right, it means that some successor 
> technology that directly solves the routing problem will 
> leapfrog IPv6 in 10 or 20 years without IPv6 ever having 
> reached useful deployment or ever having paid back its early adopters.

You know, if all that happens with IPv6 is that it generates
enough innovation in IPv4 to keep the Internet largely intact
and stable, I'd be happy.

I understand your points, and you're largely right, but where 
we have insufficient data it still looks to me that
when comparing cost and risk, sticking with
IPv4 is higher on both in the long run. 
 
Lee


From iljitsch at muada.com  Wed Sep  3 10:18:56 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 3 Sep 2008 16:18:56 +0200
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <48BE48BB.29942.2FA0005@farmer.umn.edu>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
Message-ID: <394C44B0-EBF8-4DFD-9A91-BC0E594F7623@muada.com>

On 3 sep 2008, at 15:20, David Farmer wrote:

4. There will be a painful transition from IPv4 to IPv6. This pain is  
minimized if the time that people realize that the transition is  
inevitable and the time IPv6 is working is maximized, so new policies  
that make the moment we run out of IPv4 address space less predictable  
are harmful, as are policies that make IPv4 address space harder to  
obtain;


From schnizlein at isoc.org  Wed Sep  3 09:48:30 2008
From: schnizlein at isoc.org (John Schnizlein)
Date: Wed, 3 Sep 2008 09:48:30 -0400
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <48BE48BB.29942.2FA0005@farmer.umn.edu>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
Message-ID: <F8EFE8FE-94FC-48BB-8893-2859C51C0FF2@isoc.org>

Mapping the space is a good start.  Thank you for proposing it.

Keeping the dimensions of this as nearly orthogonal as possible should  
help. I propose factoring your #2 and #3 into these two:

2. IPv6 will eventually succeed, because of the inadequacy of IPv4  
addressing to support the growth of the Internet.

3. How should the resulting scarcity of routable IPv4 addresses be  
managed, with arbitrary administrative rules, or with constrained  
transfers?

I would also add, because it seems to be the elephant in the room,

4. How much burden on the routing infrastructure (DFZ) would be  
produced by the de-aggregation that would result from a transfer  
policy?  For example, is the constraint that transfers must be within  
the space administered by a single RIR necessary?

John

On 2008Sep3, at 9:20 AM, David Farmer wrote:

> ... Therefore, in this thread I would like some help to map out the  
> argument
> space we are working with. ...
>
> So to that end, I'm going try to start, this is only a start, please  
> help by
> adding or refining the arguments, but argue them in different  
> threads please:
>
> 1. IPv6 is a failure and can not succeed, therefore we must extend  
> the life of
> IPv4 indefinitely beyond free poll exhaustion, a transfer policy is  
> part of that;
>
> 2. IPv6 will eventually succeed, however we need to keep IPv4 viable  
> until
> the transiton is complete, a transfer policy will help keep IPv4  
> viable beyond
> free poll exhaustion;
>
> 3. IPv6 will eventually succeed, but only if there is a forcing  
> function to move
> people from IPv4, free poll exhaustion is this forcing function;
>



From iljitsch at muada.com  Wed Sep  3 10:42:24 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 3 Sep 2008 16:42:24 +0200
Subject: [arin-ppml] Routing table growth, was Re:  IPv4 is depleted today
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>
Message-ID: <E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>

On 3 sep 2008, at 16:17, Howard, W. Lee wrote:

> before the
> inflation of the routing table presumed in this thread?

I must have missed that... What was said about that?

The only way the routing table is going to grow significantly faster  
than it has until now when we run out of v4 space is if the people  
that now get blocks of a million addresses are going to string  
together hundreds of small blocks. And they're not going to do that,  
because it's too much work and too expensive. If you're Comcast and  
already have a /8 (from ARIN--not a legacy one!) you can easily take a  
million addresses and NAT that space so you can put 2, 4, 8, 1000  
customers behind each of those addresses without going through complex  
and presumably expensive address acquisitions.

The 90% of the address allocations for small blocks (10% of the space)  
will simply continue in the same way they have for years, someone who  
needs a /24 will get a /24 and not four /26s. Or maybe they'll get  
_one_ /26. This won't impact the routing table growth much, if at all.

>> In other words, IPv6 is not the only choice. The best choice
>> maybe, but don't for an instant imagine that  properly
>> motivated people can't find a way to make the IPv4 Internet
>> continue to grow.

> I do indeed imagine that.  It keeps me awake at night.

You'll be able to go to http://www.google.com/ over IPv4 for a very  
long time. Don't expect do much peer-to-peer communication over IPv4  
in the less immediate future, though.

>> That approaches the real question: IPv6 migration has a cost
>> function and so does IPv4 growth. Where do the cost lines
>> cross? When does it become less expensive to deploy IPv6 and
>> exert the push that brings
>> IPv4 to a close?

>> The plain truth is that we don't have enough data to do
>> better than guess at the answer to that question.

> I agree with your question.  What data would we need?

http://www.networkworld.com/news/2003/1215ipv6.html

(That was 5 years ago, BTW.)

>> But we do
>> know that each IPv6 route costs 2 to 3 times as much to
>> implement in the router as an IPv4 route.

Do we? More bits = more expensive, presumably. But where does 2 to 3  
times come from? Note that today we have about 8.4 prefixes per AS for  
v4 and 1.2 for v6.

>> And we know that there is no new magic in IPv6 routing:
>> multihoming still requires a unique global route.

There is an alternative that is especially appropriate for smaller  
multihomers:

http://www.ietf.org/html.charters/shim6-charter.html

>> If I had to guess, I'd guess that the cost lines never cross. Even as
>> IPv4 gets more expensive, it remains more cost effective to
>> squeeze a little more out of it than to attempt an IPv6
>> migration.

It's not the cost: it's the benefits. If it costs $50 to implement v4  
and you can reach 500 sites out of the Alexa top 500, that's $0.10 per  
destination. If v6 is only $40 but you can only reach the 0.4% of the  
Alexa top 500 sites that have IPv6 that's $5 per destination.

From kkargel at polartel.com  Wed Sep  3 10:54:16 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 3 Sep 2008 09:54:16 -0500
Subject: [arin-ppml] IPv4 is depleted today - unrealisticstatementsabout
	IPv6 inevitability
In-Reply-To: <278B5E4BCD5E654385A9F83C7CA6D5173E16ED3596@MAILBOX-01.qcommcorp.ad>
References: <48BC99EE.9010509@firstpr.com.au><369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com><3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com><7F4C91E5-4858-45E6-A865-A2EAA17C654D@istaff.org>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AAE@mail>
	<278B5E4BCD5E654385A9F83C7CA6D5173E16ED3596@MAILBOX-01.qcommcorp.ad>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AAF@mail>

 That would be an accurate assessment of how we do things, however it is
also how our peers do things so in practice we don't get anything smaller
than a /24 from anyone else either..


-----Original Message-----
From: Hyunseog Ryu [mailto:hyunseog.ryu at norlight.com] 
Sent: Wednesday, September 03, 2008 9:13 AM
To: Kevin Kargel; ppml at arin.net
Subject: RE: [arin-ppml] IPv4 is depleted today - unrealisticstatementsabout
IPv6 inevitability

If I do remember correctly, some ISPs are accepting whatever size from BGP
downstream customers.

/25, /26, /27,..., even /30

But they will not advertise those small size of BGP prefixes back to other
peering partners.




-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Kevin Kargel
Sent: Wednesday, September 03, 2008 9:07 AM
To: ppml at arin.net
Subject: Re: [arin-ppml] IPv4 is depleted today - unrealistic
statementsabout IPv6 inevitability

 Absolutely, we do that today..

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of John Curran
Sent: Wednesday, September 03, 2008 4:58 AM
To: William Herrin
Cc: ppml at arin.net
Subject: Re: [arin-ppml] IPv4 is depleted today - unrealistic
statementsabout IPv6 inevitability

On Sep 2, 2008, at 7:11 PM, William Herrin wrote:
> Doesn't have to. As long as the /24 lower boundary on routability 
> holds, IPv4 will stay on a logarithmic growth curve that flattens out 
> somewhere around 7M or 8M routes.

Just for my understanding, why would /24 remain a realistic lower boundary?
Is this assertion based on an assumption that (all) ISP's in a
post-depletion situation will turn away prospects who show up with a /25 or
smaller IP block?

/John
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public
Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080903/40e19d6c/attachment.bin>

From Stu_Mitchell at ios.doi.gov  Wed Sep  3 11:01:57 2008
From: Stu_Mitchell at ios.doi.gov (Stu_Mitchell at ios.doi.gov)
Date: Wed, 3 Sep 2008 11:01:57 -0400
Subject: [arin-ppml] DNSSEC
Message-ID: <OF13BE9FE0.01AA8799-ON852574B9.00514BDC-852574B9.005294A8@ios.doi.gov>

Hello,

Pardon me, if this isn't the right place to ask....

OMB issued OMB memo 08-23, which requires federal agencies to deploy 
DNSSEC to the second level domains under "dot gov" by December 2009. I was 
wondering about the reverse records. Are there plans to sign the reverse 
domains?

Thanks

Stu Mitchell
Dept. of the Interior
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080903/a84c8ee9/attachment.htm>

From tvest at pch.net  Wed Sep  3 11:32:37 2008
From: tvest at pch.net (Tom Vest)
Date: Wed, 3 Sep 2008 11:32:37 -0400
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>
	<E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>
Message-ID: <662B99F1-F15B-47FF-9A7B-917D83B2E5A4@pch.net>


On Sep 3, 2008, at 10:42 AM, Iljitsch van Beijnum wrote:

> On 3 sep 2008, at 16:17, Howard, W. Lee wrote:
>
>> before the
>> inflation of the routing table presumed in this thread?
>
> I must have missed that... What was said about that?
>
> The only way the routing table is going to grow significantly faster
> than it has until now when we run out of v4 space is if the people
> that now get blocks of a million addresses are going to string
> together hundreds of small blocks. And they're not going to do that,
> because it's too much work and too expensive. If you're Comcast and
> already have a /8 (from ARIN--not a legacy one!) you can easily take a
> million addresses and NAT that space so you can put 2, 4, 8, 1000
> customers behind each of those addresses without going through complex
> and presumably expensive address acquisitions.
>
> The 90% of the address allocations for small blocks (10% of the space)
> will simply continue in the same way they have for years, someone who
> needs a /24 will get a /24 and not four /26s. Or maybe they'll get
> _one_ /26. This won't impact the routing table growth much, if at  
> all.
>
>>> In other words, IPv6 is not the only choice. The best choice
>>> maybe, but don't for an instant imagine that  properly
>>> motivated people can't find a way to make the IPv4 Internet
>>> continue to grow.
>
>> I do indeed imagine that.  It keeps me awake at night.
>
> You'll be able to go to http://www.google.com/ over IPv4 for a very
> long time. Don't expect do much peer-to-peer communication over IPv4
> in the less immediate future, though.
>
>>> That approaches the real question: IPv6 migration has a cost
>>> function and so does IPv4 growth. Where do the cost lines
>>> cross? When does it become less expensive to deploy IPv6 and
>>> exert the push that brings
>>> IPv4 to a close?
>
>>> The plain truth is that we don't have enough data to do
>>> better than guess at the answer to that question.
>
>> I agree with your question.  What data would we need?
>
> http://www.networkworld.com/news/2003/1215ipv6.html
>
> (That was 5 years ago, BTW.)
>
>>> But we do
>>> know that each IPv6 route costs 2 to 3 times as much to
>>> implement in the router as an IPv4 route.
>
> Do we? More bits = more expensive, presumably. But where does 2 to 3
> times come from? Note that today we have about 8.4 prefixes per AS for
> v4 and 1.2 for v6.
>
>>> And we know that there is no new magic in IPv6 routing:
>>> multihoming still requires a unique global route.
>
> There is an alternative that is especially appropriate for smaller
> multihomers:
>
> http://www.ietf.org/html.charters/shim6-charter.html
>
>>> If I had to guess, I'd guess that the cost lines never cross. Even  
>>> as
>>> IPv4 gets more expensive, it remains more cost effective to
>>> squeeze a little more out of it than to attempt an IPv6
>>> migration.
>
> It's not the cost: it's the benefits. If it costs $50 to implement v4
> and you can reach 500 sites out of the Alexa top 500, that's $0.10 per
> destination. If v6 is only $40 but you can only reach the 0.4% of the
> Alexa top 500 sites that have IPv6 that's $5 per destination.

The question is, what mechanisms will contribute to increasing that  
benefit number?

1. Incumbent IPv4-based operators altruistically make their own  
content and services transparently accessible to remote IPv6-only  
networks,

and/or

2. Topologically adjacent IPv6-only networks grow and proliferate,  
driven solely by IPv6-based demand for IPv6-based content and services,

and/or

3. IPv4 transfer prices and/or outsourced v4/v6 translation services  
remain low enough so that otherwise IPv6-only networks can exchange  
traffic with each other remotely without being substantially /  
differentially disadvantaged relative to IPv4-based incumbents.

Is the community skeptical about (1)? We seem to be quite cynical  
about other presumptions about altruistic behavior, or even neutral/ 
status quo/policy compliant behavior in the address scramble to come.  
(1) would not only cost operators $$$ with no obvious/direct return,  
it would also tend to moderate the demand/prices for IPv4 post-runout,  
which would not be in the interests of potential IPv4 sellers.

As assumptions about (2) realistic, especially in the presence of  
ongoing, active competition by full-functioning IPv4-based operators?

It seems like an awful lot is riding on faith in (3), even though it  
directly conflicts with (1).

TV














From iljitsch at muada.com  Wed Sep  3 11:57:22 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 3 Sep 2008 17:57:22 +0200
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <662B99F1-F15B-47FF-9A7B-917D83B2E5A4@pch.net>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>
	<E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>
	<662B99F1-F15B-47FF-9A7B-917D83B2E5A4@pch.net>
Message-ID: <C433A554-873E-41C6-92C8-3B01E4DE1256@muada.com>

On 3 sep 2008, at 17:32, Tom Vest wrote:

>> It's not the cost: it's the benefits. If it costs $50 to implement v4
>> and you can reach 500 sites out of the Alexa top 500, that's $0.10  
>> per
>> destination. If v6 is only $40 but you can only reach the 0.4% of the
>> Alexa top 500 sites that have IPv6 that's $5 per destination.

> The question is, what mechanisms will contribute to increasing that  
> benefit number?

I don't think being able to reach IPv6 destinations in the immediate  
future will drive IPv6 adoption. The driver will be the lack of IPv4  
space for ISPs. They will then have to choose a mechanism to get  
content (which will presumably still be predominately on v4) to their  
users. One way is to do NAT in the ISP network. Another is NAT-PT  
(well, probably NAT64, (hopefully) its successor) and yet another  
"dual stack lite".

I'll assume the first familiar, the second is IPv6 clients talking to  
IPv4 servers through a v6-v4 translator + NAT and the third IPv4  
clients talking through an IPv6 cloud and an IPv4 NAT to an IPv4 server.

The last two both have the advantage that an ISP can support many  
customers behind a big fat NAT box without having to do routing/ 
addressing trickery and there's just the one NAT box. With the first  
solution internal routing and management becomes a nightmare and if  
there are additional NATs peer-to-peer becomes REALLY hard.

So NAT64 and/or dual stack light, along with futureproofness, may be  
what gets IPv6 in the door at ISPs. Then, when the number of IPv6  
eyeballs is sufficiently large, it becomes interesting for content  
providers to talk to those people directly over v6, this helps them  
track people more easily, among other things.

> 1. Incumbent IPv4-based operators altruistically make their own  
> content and services transparently accessible to remote IPv6-only  
> networks,

0.4% of the Alexa top 500...

Note that once we're at about 10% or so IPv6 use, it really doesn't  
matter all that much if it grows beyond that, until we reach 50/50 and  
then, 90%. At that point, people will start turning off IPv4. Between  
10% and 90% we'll have a de facto dual stack internet.

> 2. Topologically adjacent IPv6-only networks grow and proliferate,  
> driven solely by IPv6-based demand for IPv6-based content and  
> services,

Peer-to-peer. I already have IPv6 bittorrent peers regularly these days.

> 3. IPv4 transfer prices and/or outsourced v4/v6 translation services  
> remain low enough so that otherwise IPv6-only networks can exchange  
> traffic with each other remotely without being substantially /  
> differentially disadvantaged relative to IPv4-based incumbents.

I don't understand.


From jcurran at istaff.org  Wed Sep  3 12:08:09 2008
From: jcurran at istaff.org (John Curran)
Date: Wed, 3 Sep 2008 12:08:09 -0400
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>
	<E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>
Message-ID: <357FB042-CCFB-4674-B2F3-BE9ECECDA2F4@istaff.org>

On Sep 3, 2008, at 10:42 AM, Iljitsch van Beijnum wrote:
> The 90% of the address allocations for small blocks (10% of the space)
> will simply continue in the same way they have for years, someone who
> needs a /24 will get a /24 and not four /26s. Or maybe they'll get
> _one_ /26. This won't impact the routing table growth much, if at  
> all.

Okay, I'm holding a very different set of assumptions...
where am I mistaken in the list below?

1. The majority of address space allocated today is going to a
    small number of very large ISPs.

2. These ISP's love to connect new customers to their networks, and
    have long-term financial forecasts based on this assumption.

3. Connecting a new organization to the Internet requires a small
    number of unique addresses (due to NAT use by many organizations)
    which can be out of provider space today (and hence routing neutral
    since they all come from the most recent very large RIR allocation
    to that ISP).

4. At depletion, ISP's will free up internal addresses and use them to
    the extent possible, and might encourage customers with PA space to
    give up unneeded address space in their assignment, but that's only
    going to allow continued growth for a fairly short time.

5. ISP's will then: A) Look at connecting new customers via IPv6 and
    the transition technology du jour, and/or B) Attempt to obtain
    more IPv4 address blocks.

6. If someone wants to 'make money' via address block transfers,
    they'll want to make the most money possible via such transfers.

7. The value of a /23 block is always going to be less than 2 /24's
    (since the 2 contiguous /24's are in demand to both anyone who
     wants the /23 *and* additional folks who desire just a /24).

8. The major ISP's realize that routing lots of "relatively small"
    address blocks obtained any way possible is really bad due to
    the routing table impact but other than (5A) above, it's the
    only option available for connecting new customers.

9. It won't take long for large ISP's to also realize that they
    are capable of affording 1M route DFZ routers, and such routers
    will let make use of even smaller obtained PI blocks and both
    handle the routes internally and share some of those routes
    to those other "tier 1"'s who happen to be doing the same...

10.  This model works "successfully" (although without any real
      of hierarchical aggregation due to extensive PI reuse) and
      provides us a small number of additional year of growth
      before collapsing due to departure from RFC 2008/BCP 7.

/John







From stephen at sprunk.org  Wed Sep  3 12:08:22 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 03 Sep 2008 11:08:22 -0500
Subject: [arin-ppml] IPv4 is depleted today
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC07DAB945@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC07DAB945@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <48BEB676.90705@sprunk.org>

michael.dillon at bt.com wrote:
>> A liberalized transfer policy does nothing to increase ease of moving 
>> to IPv6, all it does is make it easier to stay on IPv4.
>>     
>
> It forces companies to spend money on IP addresses thus reducing
> the amount they have available for capex and opex. How does this
> make it easier to stay on IPv4? In particular, in all but the 
> smallest ISPs, it now forces the addressing people to ask for
> money that they did not have to ask for before. It is one thing
> to have a recurring budget item for up to $18,000 per year
> for ARIN subscription fees. It is quite another thing to ask
> for a one-time figure which is probably quite a bit higher, to
> buy something that used to be free and included in the annual fee.
>
> Just explaining it all to management is going to be one
> big pain in the rear.
>   

I don't see it as being that difficult if you apply appropriate metaphors:

"IP address space is allocated under homesteading rules: you must prove 
you need it before you can get it.  The amount of unclaimed IPv4 space 
is running out, which means soon we'll need to buy it from someone else, 
though the homesteading rules will still apply.  However, there's a new 
continent out there called IPv6, which has all the land we need for 
cheap, but it's on the other side of the ocean so we'd need ships called 
'NAT-PT devices' for our customers to get back and forth until everyone 
else has migrated over too.  Or, we can build taller buildings, using 
NAT construction, here on the IPv4 mainland to house more customers on 
less land, but those buildings are more expensive to buy and maintain, 
fall down frequently, and one day we'll need those same NAT-PT ships to 
get to all the folks over on the IPv6 continent."

That took me all of 30 seconds to read out loud, and anyone with a 
decent understanding of American history and basic business practices 
will understand the broad strokes.  Yes, it has holes like any metaphor 
does, but it's good enough to explain to a non-techie the various 
problems and options available -- and their costs.

S


From stephen at sprunk.org  Wed Sep  3 12:11:15 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 03 Sep 2008 11:11:15 -0500
Subject: [arin-ppml] IPv4 is depleted today - unrealistic
 statements	about IPv6 inevitability
In-Reply-To: <20080903135705.GA19327@vacation.karoshi.com.>
References: <48BC99EE.9010509@firstpr.com.au>	<369EB04A0951824ABE7D8BAC67AF9BB40B203F8F@CL-S-EX-1.stanleyassociates.com>	<3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>	<48BE16DA.6040707@sprunk.org>	<3c3e3fca0809030653m542be62fn89b201875fd02a6a@mail.gmail.com>
	<20080903135705.GA19327@vacation.karoshi.com.>
Message-ID: <48BEB723.4050000@sprunk.org>

bmanning at vacation.karoshi.com wrote:
>  can't speak for the 30k ASN's out there, but the couple dozen I have
> touched in the past decade or so are perfectly willing to take a /25 
> from me... most will not transit it though.
>   

I think most of us would be willing to take a /25 (or even a /31) from 
_you_ or other well-known folks, but the same would not apply to random 
customers or peers' customers.  Even ignoring the issue of routing table 
growth, just look back a few ARIN meetings at all the folks that shot 
down lowering the PI bar to /24 due to fear of spammers being able to 
more easily get address space...

S


From bill at herrin.us  Wed Sep  3 12:15:01 2008
From: bill at herrin.us (William Herrin)
Date: Wed, 3 Sep 2008 12:15:01 -0400
Subject: [arin-ppml] IPv4 is depleted today - unrealistic statements
	about IPv6 inevitability
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>
References: <3c3e3fca0809021611n34304bb2jc660da68e1334278@mail.gmail.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>
Message-ID: <3c3e3fca0809030915y2f0887f6t6ed9f75477e548bb@mail.gmail.com>

On Wed, Sep 3, 2008 at 8:00 AM, Eliot Lear <lear at cisco.com> wrote:
> Let us agree that there is no "one size fits all" approach, and
> then we can apply some assumptions that argue in favor of geographically
> assigned addresses (which is really where your proposal leads).  There
> is a reasonable argument that such addressing is scalable from a routing
> system standpoint, if you can get to that state.  To the best of my
> knowledge, nobody has gotten to that state.

Eliot,

We explored the geographic approaches very thoroughly on RRG. The
bottom line is that while origin-only ASes can get some mild benefit
from better geographic aggregation, transit ASes get bupkis. There's
no way to drop the long prefixes from a transit-AS RIB without
damaging its reliability, even when they're adjacent and apparently
aggregable.

Further geographic aggregation beyond the RIRs is a blind alley.


On Wed, Sep 3, 2008 at 10:11 AM, Paul Vixie <vixie at isc.org> wrote:
> does parallelism at the node level get us to the point where the speed of
> light isn't enough for route propagation among the number of routes and
> nodes we can have, and the whole thing gets to what reciprocating engine
> people call "valve float" where convergence never occurs?

Paul,

I believe we've passed that point already. The table as a whole
doesn't converge, doesn't reach a state where everybody agrees where
each route should go. But the individual routes in the table do
converge.

The issue isn't where the table as a whole doesn't converge, its where
do we reach a point where we can't build a cost-effective machine that
can recover in a timely fashion from a nearby link failure that churns
a large number of routes. That's where parallelism gains us at least
an order of magnitude just by moving today's COTS server technology
into the routers.

Cost-effective. Timely. These are soft limits. There's no definable
point at which the system simply collapses; path outages just slowly
get a hair longer and routers slowly get more expensive. Ever so
slowly leading us up the garden path.


> note that if RRG has dissenting views, then someone who disagrees with tony
> li's views from denver, could ask for a speaking slot in los angeles.  the
> community ought to be open to well reasoned arguments from many perspectives.

I'd take you up on that but I plan to go to Minneapolis this year and
I can only do a limited amount of globe trotting.


On Wed, Sep 3, 2008 at 10:17 AM, Howard, W. Lee
<Lee.Howard at stanleyassociates.com> wrote:
> [good work is being done on routing scalability] > They don't
>> buy growth forever, but they buy a lot more than Tony thinks.
>
> Great!  Can I (if I were a major ISP) buy 10 routers using this
> architecture in time to design, test, and deploy before the
> inflation of the routing table presumed in this thread?

Lee,

Given that we're two full product cycles away from having 2M routes in
the table even at the worst case, the shipping equipment already
handles 1M routes, and I don't think we need to handle more than 8M
IPv4 routes even at the endgame, I'm going to say yes: hardware will
be available on time. It will tend to disrupt IPv6 deployment however
because the time frame is short and IPv6 routes consume the same kind
of resources as IPv4 routes.


>> As long as the /24 lower boundary on
>> routability holds, IPv4 will stay on a logarithmic growth
>> curve that flattens out somewhere around 7M or 8M routes.
>
> Is that a fair assumption?  The argument I thought I was
> reading said that aggressive deaggregation was easier and
> cheaper than deploying IPv6.

Ubiquitous change is expensive. Making prefixes longer than /24
globally routable requires a ubiquitous change. Hence it'll happen
slowly if at all.

Adding /24 routes requires no change. It's the path of least resistance.


>> IPv6 migration has a cost
>> function and so does IPv4 growth. Where do the cost lines
>> cross? When does it become less expensive to deploy IPv6 and
>> exert the push that brings
>> IPv4 to a close?
>>
>> The plain truth is that we don't have enough data to do
>> better than guess at the answer to that question.
>
> I agree with your question.  What data would we need?  Is it
> possible to get such data, so network operators will be able
> to make well-informed design and purchasing decisions?

We'll need to get to 1% to 2% usable and used deployment of IPv6
before we'll be able to get a realistic idea of its cost curve. The
IPv6-first fallback to IPv4 design error in IPv6 prevents  an accurate
read until there's enough deployment for it to show its impact. As I
recall, current deployment is around two hundreds or two thousandths
of a percent.

For IPv4, we'd have to make some assumptions which won't be well
grounded until after free pool exhaustion. How much does an IP address
have to cost before its worthwhile to sell it? Is it worthwhile to
sell addresses at $1 each? I doubt it. $10? Maybe. We won't know what
an IPv4 address is worth until a market tells us and it won't tell us
until the free pool is gone.


>  I saw
> in another post you believe it could go from 8:1 to 2:1, which
> gain is largely removed be the address space overhead.  I still
> think deaggregation is a stupid way to do TE, and that BGP needs
> another knob for that purpose, but I understand the difficulty
> in getting that knob adopted

How do you do TE with a BGP knob? Attach a maximum distance so the
more-specific doesn't propagate far? Propagate only the aggregate but
with a stochastic function which distant routers are expected to use
when they have more than one path available? I'm sure if someone
actually comes up with a way to implement a BGP knob for the kind of
TE we do with disaggregation, it'll find itself on the implementation
fast track.

Between TE and the equivalent of "/24 for multihoming" you're not
going to get better than 2:1. That IPv6 is currently at 1.2:1 only
reflects its lack of deployment.


> (unless somebody important decides
> to suppress more-specifics where an aggregate is announced and
> otherwise override deaggregation TE).

Can't do it in a transit AS. More-specifics are not necessarily TE;
they're also downstream multihoming. Dropping them lowers your
standard of reliability. If you're Cogent, maybe that's not a problem
but if you're Verizon it sinks your ship.


> You know, if all that happens with IPv6 is that it generates
> enough innovation in IPv4 to keep the Internet largely intact
> and stable, I'd be happy.
>
> I understand your points, and you're largely right, but where
> we have insufficient data it still looks to me that
> when comparing cost and risk, sticking with
> IPv4 is higher on both in the long run.

Call me a pessimist but I foresee a future in which folks choose the
immediate path of least resistance 99% of the time. The other 1% isn't
enough to shift the IPv6 cost line under the IPv4 cost line and IPv6
doesn't move below the IPv4 cost line without a lot of help.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From iljitsch at muada.com  Wed Sep  3 12:20:36 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 3 Sep 2008 18:20:36 +0200
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <357FB042-CCFB-4674-B2F3-BE9ECECDA2F4@istaff.org>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>
	<E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>
	<357FB042-CCFB-4674-B2F3-BE9ECECDA2F4@istaff.org>
Message-ID: <46E08DDF-4ECB-4562-B13F-52F8B72217E8@muada.com>

On 3 sep 2008, at 18:08, John Curran wrote:

> Okay, I'm holding a very different set of assumptions...
> where am I mistaken in the list below?

No problems with 1 - 4. If v4 trading becomes possible, then 5 - 7. I  
don't think 8 - 9 are too relevant, other mechanisms will make ISPs  
route address space. (I.e., the ability to bill customers.)

I think the place where our views differ is that I have assumed that  
there are two classes of end-users: ones that require a very small  
amount of address space from their ISP (1 address or less) and ones  
bringing their own address space. (There are other classes as well but  
I'm not sure if those exist in large enough numbers to be relevant.)

Your assumption seems to be that for an individual customer, address  
space will be obtained somehow.

In my model, the number of people bringing their own address space (=  
the 90% of allocations and 10% of address space given out each year  
currently) won't change when we "run out" of IPv4 space because small  
blocks can presumably be obtained somehow, there's enough scraps  
laying around and/or being returned to the RIRs to make this continue.  
But the people that need to get space from their ISP aren't going to  
go out and find address space themselves (otherwise they'd be in the  
other category) and ISPs aren't going to do this on their behalf  
because it's too time consuming and too expensive, and is a dead end:  
every year it will be harder and more expensive. Might as well put in  
the big NAT boxes immediately.


From jcurran at istaff.org  Wed Sep  3 12:30:35 2008
From: jcurran at istaff.org (John Curran)
Date: Wed, 3 Sep 2008 12:30:35 -0400
Subject: [arin-ppml] DNSSEC
In-Reply-To: <OF13BE9FE0.01AA8799-ON852574B9.00514BDC-852574B9.005294A8@ios.doi.gov>
References: <OF13BE9FE0.01AA8799-ON852574B9.00514BDC-852574B9.005294A8@ios.doi.gov>
Message-ID: <9643DE4F-61A2-4F4D-8CB4-E385877900E7@istaff.org>

Mr. Mitchell -

    While perhaps not the ideal place, asking the PPML mailing list  
certainly works.

    The topic has not been discussed at before the ARIN membership,  
but the ARIN
    Board has discussed this topic and has directed staff to make  
those preparations
    necessary for signing those reverse zones contained in-addr  
records for space
    under ARIN's administration.  Note that the actual effectiveness  
in security that
    results is rather limited until both .arpa and the DNS root zone  
are also signed.

/John

John Curran
Chairman
ARIN Board of Trustees



On Sep 3, 2008, at 11:01 AM, Stu_Mitchell at ios.doi.gov wrote:

>
> Hello,
>
> Pardon me, if this isn't the right place to ask....
>
> OMB issued OMB memo 08-23, which requires federal agencies to deploy  
> DNSSEC to the second level domains under "dot gov" by December 2009.  
> I was wondering about the reverse records. Are there plans to sign  
> the reverse domains?
>
> Thanks
>
> Stu Mitchell
> Dept. of the Interior
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080903/388e9006/attachment.htm>

From tvest at pch.net  Wed Sep  3 13:35:41 2008
From: tvest at pch.net (Tom Vest)
Date: Wed, 3 Sep 2008 13:35:41 -0400
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <C433A554-873E-41C6-92C8-3B01E4DE1256@muada.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>
	<E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>
	<662B99F1-F15B-47FF-9A7B-917D83B2E5A4@pch.net>
	<C433A554-873E-41C6-92C8-3B01E4DE1256@muada.com>
Message-ID: <B003E055-80E0-49FA-985A-BF1BC14169A7@pch.net>


On Sep 3, 2008, at 11:57 AM, Iljitsch van Beijnum wrote:

> On 3 sep 2008, at 17:32, Tom Vest wrote:
>
>>> It's not the cost: it's the benefits. If it costs $50 to implement  
>>> v4
>>> and you can reach 500 sites out of the Alexa top 500, that's $0.10  
>>> per
>>> destination. If v6 is only $40 but you can only reach the 0.4% of  
>>> the
>>> Alexa top 500 sites that have IPv6 that's $5 per destination.
>
>> The question is, what mechanisms will contribute to increasing that  
>> benefit number?
>
> I don't think being able to reach IPv6 destinations in the immediate  
> future will drive IPv6 adoption.


I agree -- which is what makes me wonder how, post-runout, when  
presumably all future new entrants will be either pure IPv6 or  
absolutely dependent on transfer mechanisms, we're going to be able to  
continue looking like an open industry to both inside and outside  
critics. The way the political winds are blowing, that could easily  
become a real concern in the near future, even in the US.


> The driver will be the lack of IPv4 space for ISPs. They will then  
> have to choose a mechanism to get content (which will presumably  
> still be predominately on v4) to their users. One way is to do NAT  
> in the ISP network. Another is NAT-PT (well, probably NAT64,  
> (hopefully) its successor) and yet another "dual stack lite".
>
> I'll assume the first familiar, the second is IPv6 clients talking  
> to IPv4 servers through a v6-v4 translator + NAT and the third IPv4  
> clients talking through an IPv6 cloud and an IPv4 NAT to an IPv4  
> server.
>
> The last two both have the advantage that an ISP can support many  
> customers behind a big fat NAT box without having to do routing/ 
> addressing trickery and there's just the one NAT box. With the first  
> solution internal routing and management becomes a nightmare and if  
> there are additional NATs peer-to-peer becomes REALLY hard.


As the risk of erring on the cynical side, I suspect that such  
solutions will be deployable just as easily in non-transparent/ 
asymmetrical as in symmetric/transparent (i.e., transparently  
accessible to externally-initiated connections) mode. Given how the  
endless wrangling between content-oriented and access-oriented  
providers has heated up lately, it's easy to imagine how normal good  
hygiene, complexity aversions, et al. might not be sufficient to  
assure that internal fixes have the same kind of beneficial external/ 
inter-domain side-effects that we might otherwise expect.


> So NAT64 and/or dual stack light, along with futureproofness, may be  
> what gets IPv6 in the door at ISPs. Then, when the number of IPv6  
> eyeballs is sufficiently large, it becomes interesting for content  
> providers to talk to those people directly over v6, this helps them  
> track people more easily, among other things.
>
>> 1. Incumbent IPv4-based operators altruistically make their own  
>> content and services transparently accessible to remote IPv6-only  
>> networks,
>
> 0.4% of the Alexa top 500...

I understand the point you're trying to make here, but sometimes the  
elephants have ideas their own. Unless we introduce some contradictory  
altruism assumptions in here, it's not clear why the elephants -- most  
of whom have big interests in both access and content -- will be  
inclined to automatically empower the legions of mice, given the  
option of not empowering them.

> Note that once we're at about 10% or so IPv6 use, it really doesn't  
> matter all that much if it grows beyond that, until we reach 50/50  
> and then, 90%. At that point, people will start turning off IPv4.  
> Between 10% and 90% we'll have a de facto dual stack internet.


Agreed, my concerns are all about the path between those two  
milestones -- whether it's relatively straight or twisty turny with  
cycles, and how we're going to know where we are once we get in the  
middle and there's no turning back.


>> 2. Topologically adjacent IPv6-only networks grow and proliferate,  
>> driven solely by IPv6-based demand for IPv6-based content and  
>> services,
>
> Peer-to-peer. I already have IPv6 bittorrent peers regularly these  
> days.
>
>> 3. IPv4 transfer prices and/or outsourced v4/v6 translation  
>> services remain low enough so that otherwise IPv6-only networks can  
>> exchange traffic with each other remotely without being  
>> substantially / differentially disadvantaged relative to IPv4-based  
>> incumbents.
>
> I don't understand.

> On Sep 3, 2008, at 10:42 AM, Iljitsch van Beijnum wrote:

>> It's not the cost: it's the benefits. If it costs $50 to implement v4
>> and you can reach 500 sites out of the Alexa top 500, that's $0.10  
>> per
>> destination. If v6 is only $40 but you can only reach the 0.4% of the
>> Alexa top 500 sites that have IPv6 that's $5 per destination.



I was just suggesting that post-runout, aspiring new entrants will  
have to use very different denominator(s) to calculate the benefits of  
any/all IPv4 reachability. Maybe being a dedicated customer will  
remain just as competitive as it is now, but I don't think that will  
fact make for a very compelling defense if the price of becoming a new  
PI self-provider or entering the market as a new IPv4 routing services  
provider goes astronomical.

I just can't see what will prevent that outcome, short of the sort of  
unrealistic assumptions of altruism or coordinated action plans that  
have been ruled out of bounds.

TV



From pschopis at oar.net  Wed Sep  3 13:53:13 2008
From: pschopis at oar.net (Paul Schopis)
Date: Wed, 3 Sep 2008 13:53:13 -0400
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <F8EFE8FE-94FC-48BB-8893-2859C51C0FF2@isoc.org>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<F8EFE8FE-94FC-48BB-8893-2859C51C0FF2@isoc.org>
Message-ID: <969722F5-2754-4A4E-93F3-563D4563B41F@oar.net>

John,
Your number 4 resonates with me. I think I keep hearing arguments that  
are self satisfying, ie gives "me" a strategic and/or economic  
advantage. The perceived benefit can all be undone for many if not the  
community at large by 'breaking" the basic function of that we are  
trying to extend.

David,
Thanks for your proposal. It is down right rational.

paul

On Sep 3, 2008, at 9:48 AM, John Schnizlein wrote:

> 4. How much burden on the routing infrastructure (DFZ) would be
> produced by the de-aggregation that would result from a transfer
> policy?  For example, is the constraint that transfers must be within
> the space administered by a single RIR necessary?



From farmer at umn.edu  Wed Sep  3 14:00:30 2008
From: farmer at umn.edu (David Farmer)
Date: Wed, 03 Sep 2008 13:00:30 -0500
Subject: [arin-ppml] DFZ Table Size (was: the Transfer Policy Argument
	Space)
In-Reply-To: <969722F5-2754-4A4E-93F3-563D4563B41F@oar.net>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>,
	<F8EFE8FE-94FC-48BB-8893-2859C51C0FF2@isoc.org>,
	<969722F5-2754-4A4E-93F3-563D4563B41F@oar.net>
Message-ID: <48BE8A6E.6415.3FAA62B@farmer.umn.edu>

This is on the verge of begin a discussion of the merits of the argument, it is 
an important discussion, but let's make it a separate thread please

Thanks.

On 3 Sep 2008 Paul Schopis wrote:

> John,
> Your number 4 resonates with me. I think I keep hearing arguments that
>  are self satisfying, ie gives "me" a strategic and/or economic 
> advantage. The perceived benefit can all be undone for many if not the
>  community at large by 'breaking" the basic function of that we are 
> trying to extend.
> 
> David,
> Thanks for your proposal. It is down right rational.

Thanks.

> paul
> 
> On Sep 3, 2008, at 9:48 AM, John Schnizlein wrote:
> 
> > 4. How much burden on the routing infrastructure (DFZ) would be
> > produced by the de-aggregation that would result from a transfer
> > policy?  For example, is the constraint that transfers must be
> > within the space administered by a single RIR necessary?
> 



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From farmer at umn.edu  Wed Sep  3 14:04:33 2008
From: farmer at umn.edu (David Farmer)
Date: Wed, 03 Sep 2008 13:04:33 -0500
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <20080903134800.GA19106@vacation.karoshi.com.>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>,
	<20080903134800.GA19106@vacation.karoshi.com.>
Message-ID: <48BE8B61.4361.3FE5931@farmer.umn.edu>

On 3 Sep 2008 bmanning at vacation.karoshi.com wrote:

> > 1. IPv6 is a failure and can not succeed, therefore we must extend
> > the life of IPv4 indefinitely beyond free poll exhaustion, a
> > transfer policy is part of that;
> > 
> > 2. IPv6 will eventually succeed, however we need to keep IPv4 viable
> > until the transiton is complete, a transfer policy will help keep
> > IPv4 viable beyond  free poll exhaustion;
> > 
> > 3. IPv6 will eventually succeed, but only if there is a forcing
> > function to move people from IPv4, free poll exhaustion is this
> > forcing function;
> > 
> > 
> 
> David,
> 
>  how about lets leave IPv6 (mostly) out of the discussion?

IPv6 has been a big part of the arguments I've seen, so I'm not sure I've will 
to eliminate it from the argument space, but I'm more that happy to have 
IPv4 only argumnets in the argument space.  And I like this one, are there 
more?

> ) IPv4 will continue to be used/useful for the next N years
> (N==10-20). 
> 
> ) Demand for IPv4 has outstripped supply.
> 
> ) Until viable alternatives become available, the trend will be to
> find 
>   more efficent ways to use the IPv4 pool.
> 
> 
> --bill



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From farmer at umn.edu  Wed Sep  3 14:09:29 2008
From: farmer at umn.edu (David Farmer)
Date: Wed, 03 Sep 2008 13:09:29 -0500
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <394C44B0-EBF8-4DFD-9A91-BC0E594F7623@muada.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>,
	<394C44B0-EBF8-4DFD-9A91-BC0E594F7623@muada.com>
Message-ID: <48BE8C89.22367.402DD9F@farmer.umn.edu>

I think I'll recompile and send out a renumber consolidated list later this 
evening.  Please send in any additional ideas you have.

Thanks and keep the ideas coming.

On 3 Sep 2008 Iljitsch van Beijnum wrote:

> On 3 sep 2008, at 15:20, David Farmer wrote:
> 
> 4. There will be a painful transition from IPv4 to IPv6. This pain is 
> minimized if the time that people realize that the transition is 
> inevitable and the time IPv6 is working is maximized, so new policies 
> that make the moment we run out of IPv4 address space less predictable
>  are harmful, as are policies that make IPv4 address space harder to 
> obtain;



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From tedm at ipinc.net  Wed Sep  3 14:18:17 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 3 Sep 2008 11:18:17 -0700
Subject: [arin-ppml] Privacy rights & IP number whois
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9018841DE@SUEXCL-02.ad.syr.edu>
Message-ID: <8B694E85E39A4372A75527B556BC1491@tedsdesk>


-----Original Message-----
From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
>That is a poor example since it's absolutely false.  DMV record
>availability is set by the state governments in the US not feds
>and it differs from state to state.


>>About 6-8 years ago in my
>>state there were no restrictions at all, none whatsoever and it
>>WAS perfectly legal to do this.

>I'd like to verify. Please name the state.

For starters, please do a favor and use plain text posting, it is
a pain to respond to htmlized mail. Thanks!

Here is the info:

In 1996 a  computer "consultant" named Aaron Nabil bought, for $222,
a full list of the State of Oregon's auto registrations and posted
it to his website.  He put in a lookup that was anonymous, anyone
could view a license registration.  At the time this was perfectly
legal.  Complaints streamed in.  Nabil took it offline when then-Governor
John Kitzhaber personally called him, and promised to issue some
executive rules that would restrict this in the future.  (I think
that what they did was today you can still buy the CD but you have
to agree to restrictions on posting it)

And yes I was off a bit on the years, it was more like 11-12 years
ago.

> Also: Where there were "no restrictions at all" was the access
> available anonymously via Internet?

Yes

>Was the data subject notified?

No

>Was a purpose requested? 

No

>Was the requestor's information recorded?

No

>If the answer to the first question was "no" and to all the others "yes",
>then my assertion is verified, not refuted by your example.

Sorry.  This is the problem with using off-the-cuff sweeping
generalizations, as I am well aware of, having been caught myself.

That is why I use auto analogies when possible since I am very familiar
with the automotive market, and such analogies are easy for most
people to grasp.

>If the answer to the first question is "yes," do you think it
>unreasonable that they stopped doing that?
>Can you appreciate why they might have stopped doing that?
>These are honest, not rhetorical questions. I want to know
>why you would feel that it is important for Internet users not
>to be anonymous but you would support anonymous downloading and
>use of sensitive information.

Well, primarily I was pointing out the holes in the analogy,
but if you want to have a discussion then here it is.

>From an ideal standpoint I do
not support the idea that automotive license numbers should have
any restrictions whatsoever.  If someone is on a public road that
is paid by my tax dollars then I feel the public has a right to
know who they are.  If people don't like this they can just take
the bus.

However, realistically I do support some restrictions, on the local
level.  In short, I absolutely support the idea that a DMV clerk 
should be able to have the authority to deny access to license data
to anyone who walks in the door, with no requirement for justification.

Meaning, if a DMV clerk is sitting there and some guy walks up and
demands to know who owns MGV800 then if the clerk has a gut feeling
that he is up to no good, then I think she should be able to tell him
"sorry, I'm not giving you that data" and if he starts to make a stink
about it, then he can be thrown out by the security people.

You have to realize that if someone is up to no good and they are
persistent, they can get the data.  For example, if some kook gets
into a fit of road rage because he thinks I cut him off, then all
he really has to do is follow me until I get where I'm going, then
park and wait me out, then keep following me.  Eventually I will end
up at home and then he has my home address, and if he's going to
stuff a stink bomb in my mail slot in retaliation, or key my car, 
or dump my garbage cans all over the front lawn, well frankly I
can't really stop him.  He does not need to walk into the DMV with
my license number to "get me"  That is why I do not see the value
or need to totally lock down vehicle license numbers from public
access.  There is value to putting up some really weak barriers so
that someone who is drunk or is in a fit of passion cannot do
something that they would later regret, but ultimately, if your
driving a car on a public road, and someone wants to know who you
are, you cannot really stop them from finding out.

>I have done so recently in fact.  And this is if the vehicle is
>a privately owned car.  If it is commercially owned then yes,
>you absolutely have the right for this information, no questions
>asked, and the DMV in my state will give it to you, no questions
>asked.

>But that's the legal person / natural person distinction. That's
>grounded in privacy law. And in either case, the DMV still has to
>verify who the owner is before you get any data, right?

No.  I can see you probably never bought a car other than through
the tender ministrations of a car dealer.

In the particular recent case of mine, I bought a vehicle with
no title, from a guy who was not the listed owner and therefore
could not give me a bill of sale which would be of any use.
Naturally I am not stupid and so before paying the guy
I called the VIN into the cops, who ran it and verified it
was not stolen.  So I bought it and needed to title it.  To
do that I had to send a certified letter to the actual owner,
asking for a title signoff.  IF and when the letter is returned
invalid recipient, I can then take that letter with the postal
stamps all over it to the DMV who will then issue the title.
But to send the letter I of course have to have all the data on
the vehicle, name, address, etc.  It was no problem getting that
from the DMV.  And of course, they did not notify the actual 
vehicle owner that I was getting the data.

The letter was returned invalid recipient, by the way.

>But ARIN's address Whois does not -- and, I hope you agree, should not
> -- tell anyone in the world who wants to know what Ted Middlstaedt's phone
> number is and what he did on the Internet last night, simply because
> they somehow got hold of your IP address number. 

Well it likely couldn't because it's Mittelstaedt, not Middlstaedt,
But seriously, I'm in the white pages and don't have an unlisted number
and I use my real name when posting - Google me up and I'm sure you
will get lots of likely boring information about me.  I know and I
frankly don't give a crap.

Issac Asimov when he was still alive also specifically did not maintain
an unlisted phone number in the NYC telephone directory.  He used to
occasionally get calls from fans and told a humorous story once about
a young woman who called him, crying and heartbroken that the Universe was
going to eventually explode in 12 billion years or whatever time period
it was, wanting to know what the point of life was if it was all going
to come to an end.  She called at something like 4 am, unaware of the
time zone difference.

He knew, as do I, and, apparently as you do not, that only the nobodies
who do absolutely nothing in this world of any value are the ones who
cannot be found.  There really is no privacy other than what people give
to each other.  It really is like when you go camping with a group
and someone needs to change clothes, so everyone else simply looks the
other way.  Because, when it is their turn, they want everyone else to
look away from them as well.  (well, most of them do I guess)

>As Verizon claimed at the time, the RIAA's position "opens the door for
>any person claiming to own a copyright to submit a one-page form to a clerk
>of a court and obtain the unlimited ability to collect private subscriber
>information" based on the collection of an IP address from a p2p site.

The fact of the matter here is that as everyone knows, the real issue
is people buying CD's then ripping tracks off them and either e-mailing
or otherwise making them publicly available.  It is unfortunately a
shame that the EFF and all the privacy advocates took the position
that people should be allowed to do this behind anonymous IP addresses,
because what that forced the RIAA to do is to go by the book and
work through the courts.  As a result, nowadays when they catch
someone doing this, they have spend so damn much money and time that
the person they catch is going to pay them money, come hell or high
water.  The option of simply telling the 16 year old that yeah, we
know you ripped that track and gave it to your friends last night,
and if you do it again your going to juvenile hall, that option isn't
open to the RIAA anymore.

So while perhaps you might have gained something so that you can
post your pro-wiccan website without me knowing who you are right
off the bat, there's a lot of people out there fighting multi-thousand
dollar lawsuits because they have dumbass teenagers as a result
of this.

We lost a community and gained an uncaring, anonymous city.  And
this is a good thing?

>The legislatures, courts and constitutions of different countries
>in the world all differ greatly on this, and what laws there are
>out there differ widely.  This kind of issue is what the United
>Nations was created to solve.  And so far the UN has not issued
>guidelines and directives on this for IP addresses.

>Are you inviting the UN to intervene in address policy? Shall I
>forward this message to the ITU and tell them that an ARIN ppml
>member really wants them to get involved? 

THEY don't WANT to get involved.  If they did, they would have
got involved years ago.  What they are all hoping for is that we,
the technologists, can come up with a semi-fair solution that
keeps the complaints down to a tolerable level.  The only reason
they stepped in on the DNS system is that the technologists
running that were too effing stupid to recognize that your not
going to be able to let Joe Sixpack register the DNS name
mcdonalds.com, just because his uncle on his mother's side lived
in ye 'ol British Isles, a century ago.

Ted



From farmer at umn.edu  Wed Sep  3 14:21:22 2008
From: farmer at umn.edu (David Farmer)
Date: Wed, 03 Sep 2008 13:21:22 -0500
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <F8EFE8FE-94FC-48BB-8893-2859C51C0FF2@isoc.org>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>,
	<F8EFE8FE-94FC-48BB-8893-2859C51C0FF2@isoc.org>
Message-ID: <48BE8F52.20397.40DC03E@farmer.umn.edu>

On 3 Sep 2008 John Schnizlein wrote:

> Mapping the space is a good start.  Thank you for proposing it.
> 
> Keeping the dimensions of this as nearly orthogonal as possible should
>  help. I propose factoring your #2 and #3 into these two:
>
> 2. IPv6 will eventually succeed, because of the inadequacy of IPv4 
> addressing to support the growth of the Internet.

Do you intend this to replace the old #2, I'm not sure it captures everything 
that was in it, but I do like this  

> 3. How should the resulting scarcity of routable IPv4 addresses be 
> managed, with arbitrary administrative rules, or with constrained 
> transfers?

This is in the form of a questions with two choices, I believe arguments are 
better in the form of declarative sentences. And again I'm not sure it covers 
everything that was in my original #3
 
> I would also add, because it seems to be the elephant in the room,
>
> 4. How much burden on the routing infrastructure (DFZ) would be 
> produced by the de-aggregation that would result from a transfer 
> policy?  For example, is the constraint that transfers must be within 
> the space administered by a single RIR necessary?

I like this, but again it is in the form of a question(s) and not an argument.
 
> John
> 
> On 2008Sep3, at 9:20 AM, David Farmer wrote:
> 
> > ... Therefore, in this thread I would like some help to map out the 
> > argument space we are working with. ...
> >
> > So to that end, I'm going try to start, this is only a start, please
> >  help by adding or refining the arguments, but argue them in
> > different  threads please:
> >
> > 1. IPv6 is a failure and can not succeed, therefore we must extend 
> > the life of IPv4 indefinitely beyond free poll exhaustion, a
> > transfer policy is  part of that;
> >
> > 2. IPv6 will eventually succeed, however we need to keep IPv4 viable
> >  until the transiton is complete, a transfer policy will help keep
> > IPv4  viable beyond free poll exhaustion;
> >
> > 3. IPv6 will eventually succeed, but only if there is a forcing 
> > function to move people from IPv4, free poll exhaustion is this
> > forcing function;
> >
> 



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From michael.dillon at bt.com  Wed Sep  3 15:00:26 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 3 Sep 2008 20:00:26 +0100
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <B003E055-80E0-49FA-985A-BF1BC14169A7@pch.net>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC07DAC3A5@E03MVZ2-UKDY.domain1.systemhost.net>

> > 0.4% of the Alexa top 500...
> 
> I understand the point you're trying to make here, but sometimes the  
> elephants have ideas their own. Unless we introduce some 
> contradictory  
> altruism assumptions in here, it's not clear why the 
> elephants -- most  
> of whom have big interests in both access and content -- will be  
> inclined to automatically empower the legions of mice, given the  
> option of not empowering them.

It's also not the way the world works. We want exponential growth
of the IPv6 Internet. To achieve this, paradoxically, we do NOT
want big content providers to enable v6 in droves. Instead we want
lots and lots of mice, more each month than the month before. That
will build momentum over a period of years, and then suddenly, 
when we are barely ready for it, the big leap of the exponential
curve will hit us as big content sites start switching on IPv6.
The fact is, that in nature, which is where we exist, an exponential
curve starts with a long run-up which slowly gathers momentum for
a considerable period of time. During that run-up, measurements
of growth are confusing because they only show a small uplift
over linear growth and this could be the result of measurement 
error. But the factors behind the numbers, are working towards
the big leap. Hundreds of elephants dipping their toes in the water
don't register much more impact than thousands of mice diving in
headfirst. But when the elephant is comfy and strides forward,
you will notice it.

People are spending entirely too much time on side issues to IPv6
deployment as *THE* public Internet protocol. It *WILL* happen, it
*WILL* be a lot of work, there will be some false starts (already have
been for that matter), but it is going to happen, because there is
nothing else out there competing with IPv6.

Also, consider this. It is now clear that the American empire which
grew during the early years of the 20th century, is now in decline.
The future will be a much more multipolar world in which the USA
does not dictate the way forward. The BRIC countries, Brazil, Russia,
India, China, and their partner states, are a lot more economically
powerful and influential than the pure numbers would suggest. China
has a lot of effort going into IPv6, and this will find its way into
a lot more devices and software going forward. The past few years have
seen a real flourishing of innovation, not just imitation, in China.
At the same time, Russia, has a strong government that is steadily
growing its economy and standard of living. Internet access is a
keystone
of that development. They definitely have the brainpower to make
the IPv6 Internet more secure than the IPv4 one was. India is no longer
just a place where you send menial clerical work. It is now becoming an
IT powerhouse that is attracting highly skilled and experienced Indian
immigrants back home. Big pipes are going into India to support this
network-centric working. And Brazil has always intervened to support
it's own internal IT industry. Sooner or later, it will do so again.

In particular, Russia, India and China have very UNDERdeveloped IPv4
Internet
infrastructure, and they are close together, practically neighbors, so
one
can expect to see various kinds of Internet deployment joint projects in
the
next few years to pull this off. They will have to do it with IPv6
because
there ain't enough IPv4 addresses left. The writing is on the wall.

The Alexa 500 are irrelevant to these countries. They build their own
anyway,
such as Baidu in China, Rambler in Russia, and so on. The non-English
Internet, which most of you will never see, is becoming a far bigger
factor
in how we transition to IPv6.

--Michael Dillon
 


From cgrundemann at gmail.com  Wed Sep  3 15:46:16 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 3 Sep 2008 13:46:16 -0600
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <48BE48BB.29942.2FA0005@farmer.umn.edu>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
Message-ID: <443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>

Great idea David, I agree 100% that defining / mapping the argument
space will help everyone to better understand their own position as
well as the positions of others.

Maybe I am making this more complicated than it needs to be but for me
to really wrap my head around the entire argument space, I had to take
a graphical approach. For those interested, it can be found here:
http://odin.chrisgrundemann.com/Do_I_Support_A_Liberalized_Transfer_Policy.jpg

I am open to suggestions on how this drawing could be improved,
utilized, discarded, and/or converted to text to complement the list
you are generating in this thread.

~Chris



On Wed, Sep 3, 2008 at 7:20 AM, David Farmer <farmer at umn.edu> wrote:
> I'm hearing many different arguments related to the transfer policy.  I've
> come to the conclusion that this is a very complicated argument space we
> are dealing with and I don't think everyone is seeing the whole argument
> landscape, I know I'm having problems with this.  As things exist currently,
> I'm not sure we can come to any consensus, not even a consensus to drop
> the issue.
>
> Therefore, in this thread I would like some help to map out the argument
> space we are working with.  I would like us to intentionally simplify the
> arguments and gloss over many of the nuances.  What I'm asking for us to
> do is map out the breath and shape of the argument space we are dealing
> with here, rather than to perfectly capture the nuances of each argument.
>
> If you want to argue the merits of some part of the argument, please do that
> as part of another thread.  If possible I would like help in this thread to
> clearly and dispassionately state the various parts of the argument, not to
> argue it.
>
> So to that end, I'm going try to start, this is only a start, please help by
> adding or refining the arguments, but argue them in different threads please:
>
> 1. IPv6 is a failure and can not succeed, therefore we must extend the life of
> IPv4 indefinitely beyond free poll exhaustion, a transfer policy is part of that;
>
> 2. IPv6 will eventually succeed, however we need to keep IPv4 viable until
> the transiton is complete, a transfer policy will help keep IPv4 viable beyond
> free poll exhaustion;
>
> 3. IPv6 will eventually succeed, but only if there is a forcing function to move
> people from IPv4, free poll exhaustion is this forcing function;
>
>
>
> =======================================================
> David Farmer                                 Email:     farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota                      Phone:     612-626-0815
> 2218 University Ave SE                       Cell:              612-812-9952
> Minneapolis, MN 55414-3029                   FAX:       612-626-1818
> =======================================================
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
Chris Grundemann
www.linkedin.com/in/cgrundemann


From tvest at pch.net  Wed Sep  3 15:47:01 2008
From: tvest at pch.net (Tom Vest)
Date: Wed, 3 Sep 2008 15:47:01 -0400
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC07DAC3A5@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC07DAC3A5@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <6F90839E-4737-4C70-B582-820EC57FFC1F@pch.net>


On Sep 3, 2008, at 3:00 PM, <michael.dillon at bt.com> wrote:

>>> 0.4% of the Alexa top 500...
>>
>> I understand the point you're trying to make here, but sometimes the
>> elephants have ideas their own. Unless we introduce some
>> contradictory
>> altruism assumptions in here, it's not clear why the
>> elephants -- most
>> of whom have big interests in both access and content -- will be
>> inclined to automatically empower the legions of mice, given the
>> option of not empowering them.
>
> It's also not the way the world works. We want exponential growth
> of the IPv6 Internet. To achieve this, paradoxically, we do NOT
> want big content providers to enable v6 in droves. Instead we want
> lots and lots of mice, more each month than the month before. That
> will build momentum over a period of years, and then suddenly,
> when we are barely ready for it, the big leap of the exponential
> curve will hit us as big content sites start switching on IPv6.
> The fact is, that in nature, which is where we exist, an exponential
> curve starts with a long run-up which slowly gathers momentum for
> a considerable period of time. During that run-up, measurements
> of growth are confusing because they only show a small uplift
> over linear growth and this could be the result of measurement
> error. But the factors behind the numbers, are working towards
> the big leap. Hundreds of elephants dipping their toes in the water
> don't register much more impact than thousands of mice diving in
> headfirst. But when the elephant is comfy and strides forward,
> you will notice it.
>
> People are spending entirely too much time on side issues to IPv6
> deployment as *THE* public Internet protocol. It *WILL* happen, it
> *WILL* be a lot of work, there will be some false starts (already have
> been for that matter), but it is going to happen, because there is
> nothing else out there competing with IPv6.
>
> Also, consider this. It is now clear that the American empire which
> grew during the early years of the 20th century, is now in decline.
> The future will be a much more multipolar world in which the USA
> does not dictate the way forward. The BRIC countries, Brazil, Russia,
> India, China, and their partner states, are a lot more economically
> powerful and influential than the pure numbers would suggest. China
> has a lot of effort going into IPv6, and this will find its way into
> a lot more devices and software going forward. The past few years have
> seen a real flourishing of innovation, not just imitation, in China.
> At the same time, Russia, has a strong government that is steadily
> growing its economy and standard of living. Internet access is a
> keystone
> of that development. They definitely have the brainpower to make
> the IPv6 Internet more secure than the IPv4 one was. India is no  
> longer
> just a place where you send menial clerical work. It is now becoming  
> an
> IT powerhouse that is attracting highly skilled and experienced Indian
> immigrants back home. Big pipes are going into India to support this
> network-centric working. And Brazil has always intervened to support
> it's own internal IT industry. Sooner or later, it will do so again.
>
> In particular, Russia, India and China have very UNDERdeveloped IPv4
> Internet
> infrastructure, and they are close together, practically neighbors, so
> one
> can expect to see various kinds of Internet deployment joint  
> projects in
> the
> next few years to pull this off. They will have to do it with IPv6
> because
> there ain't enough IPv4 addresses left. The writing is on the wall.
>
> The Alexa 500 are irrelevant to these countries. They build their own
> anyway,
> such as Baidu in China, Rambler in Russia, and so on. The non-English
> Internet, which most of you will never see, is becoming a far bigger
> factor
> in how we transition to IPv6.
>
> --Michael Dillon

Interesting story Michael, but I think you've got the causality  
backwards.

IPv4 is incapable of having a *direct, significant, positive* impact  
on growth and innovation in places where only one or at most a handful  
of institutions can satisfy the sort of needs-based tests that have  
been the benchmark for RIR allocations. In environments where it's  
possible and economically feasible for multiple institutions to build,  
or buy, rent, or enjoy some other form of beneficial control over the  
inputs required, e.g., to multihome and/or assemble and maintain  
distributed network infrastructure, the presence of those conditions  
is revealed by widening and deepening demand (i.e., initial and  
subsequent allocations) of IPv4. Under those conditions, IPv4 actually  
has the use value that it was designed for. Maybe IPv(x) is the  
indispensable glue required for economies to realize the benefits that  
such environments provide.

In any case, until very recently (at least), China, Russia, and India  
did not exhibit such conditions, and that's the *only* thing you can  
infer -- or predict -- based on their relative IPv4 underdevelopment  
to date.

+96 bits: no more magic, but no less. If IPv4 were around forever,  
then the moment that the economies you referenced really did/do  
change, then the results would be visible in the delegated files and  
the routing table. With IPv6 we'll never have an equally fine-grained  
view, so we may never know for sure about changes "under the hood"  
that happen in the IPv6 future.

Working in Europe does give one a keen sense of the practical  
indivisibility of domestic and cross-border networks/traffic/ 
relationships, etc. But Michael, how much stronger would you say that  
indivisibility is today, as compared to c. 2000?

Things may never go back in Europe, but much of the rest of the world  
doesn't look much so much like Europe right now , and I'm not  
fatalistic enough to accept the idea that a brighter future is  
predetermined for either regardless of how things shake out over the  
next few years.

TV







From randy at psg.com  Wed Sep  3 16:12:27 2008
From: randy at psg.com (Randy Bush)
Date: Thu, 04 Sep 2008 08:12:27 +1200
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <357FB042-CCFB-4674-B2F3-BE9ECECDA2F4@istaff.org>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>	<E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>
	<357FB042-CCFB-4674-B2F3-BE9ECECDA2F4@istaff.org>
Message-ID: <48BEEFAB.7040601@psg.com>

> 10. This model works "successfully" (although without any real
>     of hierarchical aggregation due to extensive PI reuse) and
>     provides us a small number of additional year of growth
>     before collapsing due to departure from RFC 2008/BCP 7.

while i am not claiming the bgp sky is not falling, we actually have no
good measurements or experiments to substantiate the arguments that we
have a particularly low ceiling.

my guess is that, with current routers, it is the multi-homed enterprise
edge that is likely to hit any wall before the big isps.  the latter may
just see an increase in the rate of needing to appease their line card
addiction.  wuzza wuzza.

randy


From stephen at sprunk.org  Wed Sep  3 16:23:35 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 03 Sep 2008 15:23:35 -0500
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <48BEEFAB.7040601@psg.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>	<E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com>	<357FB042-CCFB-4674-B2F3-BE9ECECDA2F4@istaff.org>
	<48BEEFAB.7040601@psg.com>
Message-ID: <48BEF247.7040201@sprunk.org>

Randy Bush wrote:
>> 10. This model works "successfully" (although without any real
>>     of hierarchical aggregation due to extensive PI reuse) and
>>     provides us a small number of additional year of growth
>>     before collapsing due to departure from RFC 2008/BCP 7.
>>     
>
> while i am not claiming the bgp sky is not falling, we actually have no good measurements or experiments to substantiate the arguments that we have a particularly low ceiling.
>
> my guess is that, with current routers, it is the multi-homed enterprise edge that is likely to hit any wall before the big isps.  the latter may just see an increase in the rate of needing to appease their line card addiction.  wuzza wuzza.
>   

However, any leaf network (enterprise or otherwise) that is feeling the 
pinch can add a default (if they don't already have one) and drop 
however many routes are necessary to get down to their hardware's 
capacity.  IMHO, the real pinch is going to happen in the DFZ, where 
that isn't an option, and the most logical approach is that folks with 
long prefixes are going to find their reachability gradually decreasing 
over time.

As it stands, it seems most folks aren't filtering even at RIR minima 
yet.  That is the first step and a relatively painless one (Got a 
problem?  Quit announcing your /20 as 16 /24s!).  However, the step 
after that is be necessity going to be really painful, and the Swamp is 
the most obvious and annoying target...

S


From kkargel at polartel.com  Wed Sep  3 16:25:28 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 3 Sep 2008 15:25:28 -0500
Subject: [arin-ppml] Routing table growth,
	was Re:  IPv4 is depleted today
In-Reply-To: <48BEEFAB.7040601@psg.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284279@CL-S-EX-1.stanleyassociates.com>	<E0EE4AD4-C3C0-44D9-AA57-C63179626798@muada.com><357FB042-CCFB-4674-B2F3-BE9ECECDA2F4@istaff.org>
	<48BEEFAB.7040601@psg.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AB9@mail>

 The sky may be falling, but not necessarily for the tier>2 types..  

There are already multi-homed enterprises running on tiny routers exchanging
virtually no router tables and using primarily static route-maps to
distribute traffic..  I know of at least one ISP who is very happily
surviving accepting only VERY short (/8 or two AS hop) BGP advertisements
and letting his upstreams sort out return traffic..  From that perspective
the big iron is only needed at the transit ISP's who can better afford it.

The little guy is not under the gun if he is willing to rethink the way of
doing things.

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Randy Bush
Sent: Wednesday, September 03, 2008 3:12 PM
To: John Curran
Cc: ppml at arin.net
Subject: Re: [arin-ppml] Routing table growth,was Re: IPv4 is depleted today

> 10. This model works "successfully" (although without any real
>     of hierarchical aggregation due to extensive PI reuse) and
>     provides us a small number of additional year of growth
>     before collapsing due to departure from RFC 2008/BCP 7.

while i am not claiming the bgp sky is not falling, we actually have no good
measurements or experiments to substantiate the arguments that we have a
particularly low ceiling.

my guess is that, with current routers, it is the multi-homed enterprise
edge that is likely to hit any wall before the big isps.  the latter may
just see an increase in the rate of needing to appease their line card
addiction.  wuzza wuzza.

randy
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public
Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080903/b3d911be/attachment.bin>

From bmanning at vacation.karoshi.com  Wed Sep  3 16:52:23 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 3 Sep 2008 20:52:23 +0000
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <48BE8B61.4361.3FE5931@farmer.umn.edu>
References: <20080903134800.GA19106@vacation.karoshi.com.>
	<48BE8B61.4361.3FE5931@farmer.umn.edu>
Message-ID: <20080903205223.GC23395@vacation.karoshi.com.>

On Wed, Sep 03, 2008 at 01:04:33PM -0500, David Farmer wrote:
> On 3 Sep 2008 bmanning at vacation.karoshi.com wrote:
> > 
> > David,
> > 
> >  how about lets leave IPv6 (mostly) out of the discussion?
> 
> IPv6 has been a big part of the arguments I've seen, so I'm not sure I've will 
> to eliminate it from the argument space, but I'm more that happy to have 
> IPv4 only argumnets in the argument space.  And I like this one, are there 
> more?
> 
> > ) IPv4 will continue to be used/useful for the next N years
> > (N==10-20). 
> > 
> > ) Demand for IPv4 has outstripped supply.
> > 
> > ) Until viable alternatives become available, the trend will be to
> > find 
> >   more efficent ways to use the IPv4 pool.
> > 
> > 
> > --bill

	actually, if you can live with these lemas, then the crux of the 
	arguements boil down to two items (from the last lema), e.g.

	) what are the viable alternatives?

	) what are the "more efficent" ways to use the pool?


a transfer policy is a/one way to gain efficent use of the pool.

--bill


From Lee.Howard at stanleyassociates.com  Wed Sep  3 16:53:09 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Wed, 3 Sep 2008 16:53:09 -0400
Subject: [arin-ppml] maintenance fees for legacy space holders
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B284A1C@CL-S-EX-1.stanleyassociates.com>

Last week, there was a lot of discussion over the $100 maintenance fee, 
and whether it was a fair amount for legacy address space holders to 
pay.   In between my day job and PPML, I've tried to pull together some 
numbers.  

There are potentially 18,000 legacy OrgIDs who could sign up to pay 
the $100 maintenance fee.  I see $885k in maintenance fees last year, 
so call it 8,850 organizations currently paying maintenance fees.  
Many more OrgIDs exist, since multiple OrgIDs can fall under one 
maintenance fee, and since many pay registration renewals instead 
of maintenance.

ARIN's audited financial statements for 2007 show $3.7 million in 
engineering expenses, out of $9.8 million in total expenses.  Roughly 
38% of ARIN's expenses are engineering expenses.  Even if all of the 
possible 18,000 legacy organizations pay $100 per year, that's less 
than 15% of ARIN's total 2008 budget, and less than half of ARIN's 
engineering expenses alone.

So, what do you get for the money?  Not just the benefits of 
engineering:
*	IP address (IPv4 and IPv6) space allocation, transfer, and 
record maintenance 
*	ASN allocation, transfer, and record maintenance 
*	Maintain WHOIS database 
*	Maintain Internet Routing Registry 
*	Maintain reverse DNS 
*	Facilitate the public policy development process, including: 
	o	Maintaining mailing lists 
	o	Facilitating elections 
	o	Holding at least two public policy meetings per year
*	Publishing, disseminating information 
*	Education and training 
*	Working with other organizations, like the other RIRs and IANA 
*	Outreach to other organizations, like ITU and IGF 
*	Outreach at other industry events, like NANOG, IETF, and various

conventions
*	R&D on potential new services like a RPKI, Project X, etc.

I believe we're being fair.  We didn't ask for anything from 2002 to 
2007, when engineering expenses totaled $14.4 million.  Some 9,000 
organizations did pay maintenance fees last year, half as many as there
are legacy organizations.  For ISPs who are legacy holders, we're asking

for a small maintenance fee, not a registration renewal.  And after 
all of that, it's still voluntary-we're not strong-arming you into 
signing the LRSA. 

While I can't make predictions about the future, I will note that we
have tried to keep revenues and expenses as close as possible, and 
may actually end up in the red this year.  If there's too much money
coming in, fees are likely to come down.

Disclaimer:  I am the Treasurer of ARIN, and that hat doesn't come 
off when I post to PPML.  But I did not have the FinCom, Board, or
staff review this post before sending it, so if they override, it's
likely that I goofed up.

Lee


From narten at us.ibm.com  Wed Sep  3 17:25:45 2008
From: narten at us.ibm.com (Thomas Narten)
Date: Wed, 03 Sep 2008 17:25:45 -0400
Subject: [arin-ppml] The LRSA $100 fee...
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E5AE@SUEXCL-02.ad.syr.edu>
References: <48B82BBE.80907@bogomips.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu>
	<03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu>
	<99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E5AE@SUEXCL-02.ad.syr.edu>
Message-ID: <200809032125.m83LPjUp022983@cichlid.raleigh.ibm.com>

"Milton L Mueller" <mueller at syr.edu> writes:

> What we were discussing, if you will recall, is whether Whois accuracy
> in 2008 is better than it was in 1999, when competition was instituted.
> Are you able to credibly contest this claim? Or not? If not, what
> exactly is your point, Tom?

Can you cite data to support the claim that DNS whois compliance is
"better" than it was in 1999? I suspect there are statistics that
could be used to support either case (think the adage that "there are
lies, damn lies, and statistics"). And it probably depends quite a lot
on how you define "accurate" (e.g., is it "accurate" if the whois data
points to a third party rather than the actual owner?).

I say this because I have regularly heard (on the ICANN side) that
whois data is becoming increasingly inaccurate, and that this is
problematic (to some).

Thomas


From stephen at sprunk.org  Wed Sep  3 18:13:27 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 03 Sep 2008 17:13:27 -0500
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B284A1C@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284A1C@CL-S-EX-1.stanleyassociates.com>
Message-ID: <48BF0C07.9020602@sprunk.org>

Howard, W. Lee wrote:
> Last week, there was a lot of discussion over the $100 maintenance fee, 
> and whether it was a fair amount for legacy address space holders to 
> pay.   In between my day job and PPML, I've tried to pull together some 
> numbers.  
>
> There are potentially 18,000 legacy OrgIDs who could sign up to pay 
> the $100 maintenance fee.  I see $885k in maintenance fees last year, 
> so call it 8,850 organizations currently paying maintenance fees.  
> Many more OrgIDs exist, since multiple OrgIDs can fall under one 
> maintenance fee, and since many pay registration renewals instead 
> of maintenance.
>
> ARIN's audited financial statements for 2007 show $3.7 million in 
> engineering expenses, out of $9.8 million in total expenses.  Roughly 
> 38% of ARIN's expenses are engineering expenses.  Even if all of the 
> possible 18,000 legacy organizations pay $100 per year, that's less 
> than 15% of ARIN's total 2008 budget, and less than half of ARIN's 
> engineering expenses alone.
>
> So, what do you get for the money?  Not just the benefits of 
> engineering:
> *	IP address (IPv4 and IPv6) space allocation, transfer, and 
> record maintenance 
> *	ASN allocation, transfer, and record maintenance 
> *	Maintain WHOIS database 
> *	Maintain Internet Routing Registry 
> *	Maintain reverse DNS 
> *	Facilitate the public policy development process, including: 
> 	o	Maintaining mailing lists 
> 	o	Facilitating elections 
> 	o	Holding at least two public policy meetings per year
> *	Publishing, disseminating information 
> *	Education and training 
> *	Working with other organizations, like the other RIRs and IANA 
> *	Outreach to other organizations, like ITU and IGF 
> *	Outreach at other industry events, like NANOG, IETF, and various
>
> conventions
> *	R&D on potential new services like a RPKI, Project X, etc.
>   

Lee,

Thanks for the numbers, as well as the list of services.  I have two 
questions:

1. Is there any way to break out new allocation/assignment/transfer 
expenses vs. general maintenance, so that we can determine the share of 
expenses attributable to folks who are doing nothing other than holding 
on to legacy resources, not getting anything new, as well as making sure 
that the fees for new resources adequately cover the costs of evaluating 
justification that policy requires?

2. What would the fees need to be if they were per-object instead of 
per-org?  IMHO, this is the key to the whole "a domain only costs 
$10/yr" argument.

S


From owen at delong.com  Wed Sep  3 18:35:39 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Sep 2008 15:35:39 -0700
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
Message-ID: <7D6AE3E0-D5C5-45D8-A810-4048CFC5C236@delong.com>

Referencing:

http://odin.chrisgrundemann.com/Do_I_Support_A_Liberalized_Transfer_Policy.jpg



It took me a while to wrap my head around the graph, but, once I  
managed,
I realized that this is an EXCELLENT summary of the questions.

I think that falling out to (2) from "Are liberalized address transfers
helpful to maintain the/a IPv4 internet?" is premature and that this
should, instead, drop to the entry point to "Will speculators and
profiteers..."

Otherwise, I think it pretty much reflects the current reality.

I will also point out that this can be summarized as "A transfer  
policy is
only a good idea if you answer in exactly the correct way through a very
long series of vary uncertain variables."


I, for one, would very much love to hear a direct answer to 4e and
the subsequent opposing question from Steve Ryan.  My impression
so far is that they are approximately equal, but, I do not feel like
I have received any clear indication from Steve on this.

OTOH, I suspect that it may be very hard for Steve to do so as these
could be very uncertain.

Owen

Disclaimer: I'm a member of the AC, but, this message is not from the
AC.  Opinions contained are strictly mine. The other 14 members
each have their own opinions. I am not sure to what extent they
overlap or not.

Apology: Steve, sorry if I put you on the spot with this.



From mueller at syr.edu  Wed Sep  3 18:41:31 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 3 Sep 2008 18:41:31 -0400
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD902215108@SUEXCL-02.ad.syr.edu>

An impressive effort, Chris! Took a quick scan but will review it more
carefully tomorrow. will make suggestions if appropriate.

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
 
> Maybe I am making this more complicated than it needs to be but for me
> to really wrap my head around the entire argument space, I had to take
> a graphical approach. For those interested, it can be found here:
> http://odin.chrisgrundemann.com/Do_I_Support_A_Liberalized_Tra
> nsfer_Policy.jpg
> 
> I am open to suggestions on how this drawing could be improved,
> utilized, discarded, and/or converted to text to complement the list
> you are generating in this thread.
> 
>


From jcurran at istaff.org  Wed Sep  3 20:14:28 2008
From: jcurran at istaff.org (John Curran)
Date: Wed, 3 Sep 2008 20:14:28 -0400
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <7D6AE3E0-D5C5-45D8-A810-4048CFC5C236@delong.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
	<7D6AE3E0-D5C5-45D8-A810-4048CFC5C236@delong.com>
Message-ID: <04631C10-2CD2-47D5-AE3D-EFC349E74E53@istaff.org>

On Sep 3, 2008, at 6:35 PM, Owen DeLong wrote:
> I, for one, would very much love to hear a direct answer to 4e and
> the subsequent opposing question from Steve Ryan.  My impression
> so far is that they are approximately equal, but, I do not feel like
> I have received any clear indication from Steve on this.
>
> OTOH, I suspect that it may be very hard for Steve to do so as these
> could be very uncertain.

Owen -

   I'm not Steve Ryan (and he's thankful of that :-), but let
   me pose a thought exercise which may provide some insight
   into question 4e and its converse...

   At a point in time when ARIN has effectively no remaining
   available space to satisfy requests under the current IPv4
   policy space, how should ARIN best fulfill its incorporation
   duties to "to enhance the growth of the Internet .. by
   encouraging the exploration and implementation of solutions
   to Internet Protocol number scarcity issues"?  For instance,
   how would two parties seeking to transfer IPv4 address space
   (e.g. an address holder who could free up significant address
   space through consolidation efforts, and an ISP constrained by
   their inability to obtain additional IPv4 number resources)
   view ARIN's fulfillment of its duties if there is neither a
   more relaxed transfer policy nor a clear community statement
   of why such a policy is undesirable?

/John
(my views alone; this message was prepared in 100% deaggregate-
  free route announcements ;-)



From owen at delong.com  Wed Sep  3 20:36:42 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Sep 2008 17:36:42 -0700
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <04631C10-2CD2-47D5-AE3D-EFC349E74E53@istaff.org>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
	<7D6AE3E0-D5C5-45D8-A810-4048CFC5C236@delong.com>
	<04631C10-2CD2-47D5-AE3D-EFC349E74E53@istaff.org>
Message-ID: <CD292BCC-658A-4A59-A64B-C9C6FE05FB99@delong.com>


On Sep 3, 2008, at 5:14 PM, John Curran wrote:

> On Sep 3, 2008, at 6:35 PM, Owen DeLong wrote:
>> I, for one, would very much love to hear a direct answer to 4e and
>> the subsequent opposing question from Steve Ryan.  My impression
>> so far is that they are approximately equal, but, I do not feel like
>> I have received any clear indication from Steve on this.
>>
>> OTOH, I suspect that it may be very hard for Steve to do so as these
>> could be very uncertain.
>
> Owen -
>
>  I'm not Steve Ryan (and he's thankful of that :-), but let
>  me pose a thought exercise which may provide some insight
>  into question 4e and its converse...
>
True.  Worse yet, to the best of my knowledge, you, like me,
do not have a JD and so we're both somewhat underqualified
to answer the question at hand which is why I put Steve
on the spot.

>  At a point in time when ARIN has effectively no remaining
>  available space to satisfy requests under the current IPv4
>  policy space, how should ARIN best fulfill its incorporation
>  duties to "to enhance the growth of the Internet .. by
>  encouraging the exploration and implementation of solutions
>  to Internet Protocol number scarcity issues"?  For instance,
>  how would two parties seeking to transfer IPv4 address space
>  (e.g. an address holder who could free up significant address
>  space through consolidation efforts, and an ISP constrained by
>  their inability to obtain additional IPv4 number resources)
>  view ARIN's fulfillment of its duties if there is neither a
>  more relaxed transfer policy nor a clear community statement
>  of why such a policy is undesirable?
>
1.	I'm all for a clear community statement of why such a policy
	is undesirable. I would argue that if a relaxed transfer policy
	fails to achieve consensus, then, that's a clear statement
	from the community THAT such a thing is undesirable, all
	that is left is to fill in the why.  There have been a number of
	reasons posted to this list, many of which are quite legitimate.
	I'm not necessarily hard opposed to a transfer policy, but, the
	more we delve into the attempts to compensate for the downsides
	to such a thing, the more convinced I have become that it is
	a quagmire and a slippery slope leading to the quagmire.

2.	I think ARIN could best fulfill its role through good stewardship
	and an outreach program which provided encouragement
	and viable incentives/assistance/etc. to get people with excess
	IP available to return it to the free pool for ARIN to properly
	exercise stewardship in recycling it rather than to allow
	an ad-hoc transfer environment that assures money becomes
	the sole mechanism by which we regulate who gets IPv4 address
	space in the future.


Owen




From jcurran at istaff.org  Wed Sep  3 21:45:03 2008
From: jcurran at istaff.org (John Curran)
Date: Wed, 3 Sep 2008 21:45:03 -0400
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <CD292BCC-658A-4A59-A64B-C9C6FE05FB99@delong.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
	<7D6AE3E0-D5C5-45D8-A810-4048CFC5C236@delong.com>
	<04631C10-2CD2-47D5-AE3D-EFC349E74E53@istaff.org>
	<CD292BCC-658A-4A59-A64B-C9C6FE05FB99@delong.com>
Message-ID: <61FF7410-CF14-4433-A008-90BB6910A57E@istaff.org>

On Sep 3, 2008, at 8:36 PM, Owen DeLong wrote:
>
> True.  Worse yet, to the best of my knowledge, you, like me,
> do not have a JD and so we're both somewhat underqualified
> to answer the question at hand which is why I put Steve
> on the spot.

Understood; as Chair, I'll ask for Steve to look into both
questions, but to be clear, the questions ask about "risk"
to ARIN, not specifically legal risk.  I presume you're
looking for the latter since you indicate that counsel is
best qualified to answer here.

/John
Chairman
ARIN Board of Trustees




From baptista at publicroot.org  Wed Sep  3 22:04:18 2008
From: baptista at publicroot.org (Joe Baptista)
Date: Wed, 3 Sep 2008 22:04:18 -0400
Subject: [arin-ppml] DNSSEC
In-Reply-To: <9643DE4F-61A2-4F4D-8CB4-E385877900E7@istaff.org>
References: <OF13BE9FE0.01AA8799-ON852574B9.00514BDC-852574B9.005294A8@ios.doi.gov>
	<9643DE4F-61A2-4F4D-8CB4-E385877900E7@istaff.org>
Message-ID: <874c02a20809031904i52d8fabekd9cba892401d2290@mail.gmail.com>

On Wed, Sep 3, 2008 at 12:30 PM, John Curran <jcurran at istaff.org> wrote:

> Mr. Mitchell -
>
>    While perhaps not the ideal place, asking the PPML mailing list
> certainly works.
>
>    The topic has not been discussed at before the ARIN membership, but the
> ARIN
>    Board has discussed this topic and has directed staff to make
> those preparations
>    necessary for signing those reverse zones contained in-addr records
> for space
>    under ARIN's administration.  Note that the actual effectiveness in
> security that
>    results is rather limited until both .arpa and the DNS root zone are
> also signed.
>

I think the U.S. Government should be congratulated on its use of DNSSEC to
secure the zone.  It's a bold experiment, if not an act of faith to use the
USG .gov to test an untested experimental protocol.  Tip of my hat to you
all on that.

But I nor the world is convinced we want to be a part of it.  First imho
DNSSEC is a colossal fraud.  1) It does nothing to secure the DNS (any
kiddie with a bot net can crack it - so can governments, military and large
corporations that have the resources to do it), 2) it remains vulnerable to
man in the middle attacks, and 3) incurs significant costs on infrastructure
maintenance.

But the most repulsive aspects of DNSSEC is what I suspect is its true
purpose is to take over control of the technical function of root.  The
whole scheme is based on chains of trust up the dns tree right to the root
that has full control over the signatures.   This is a lot of power to give
to the gruesome thirteen.

 http://www.root-servers.org/

Obviously the U.S. Government trusts these people to run the root.  I do
not.  Neither does the Chinese Government or any government that has been
properly briefed on the control aspects behind DNSSEC.

Stu if I may make a presumptive suggestion.  When your boys at the USG
figure out DNSSEC is not up to snuff in the security department may I
suggest you start today investigating the operation of a secure system using
the following technology:

 http://dnscurve.org/

I've also included some slide show documentation for you to read on it.

enjoy
joe baptista


> On Sep 3, 2008, at 11:01 AM, Stu_Mitchell at ios.doi.gov wrote:
>
>
> Hello,
>
> Pardon me, if this isn't the right place to ask....
>
> OMB issued OMB memo 08-23, which requires federal agencies to deploy DNSSEC
> to the second level domains under "dot gov" by December 2009. I was
> wondering about the reverse records. Are there plans to sign the reverse
> domains?
>
> Thanks
>
> Stu Mitchell
> Dept. of the Interior
>
>
>

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080903/5dcf9447/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DNSCurve-presentation-guide-slides-1.pdf
Type: application/pdf
Size: 91723 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080903/5dcf9447/attachment.pdf>

From cgrundemann at gmail.com  Wed Sep  3 22:32:43 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 3 Sep 2008 20:32:43 -0600
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <61FF7410-CF14-4433-A008-90BB6910A57E@istaff.org>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
	<7D6AE3E0-D5C5-45D8-A810-4048CFC5C236@delong.com>
	<04631C10-2CD2-47D5-AE3D-EFC349E74E53@istaff.org>
	<CD292BCC-658A-4A59-A64B-C9C6FE05FB99@delong.com>
	<61FF7410-CF14-4433-A008-90BB6910A57E@istaff.org>
Message-ID: <443de7ad0809031932q68025beep9aaf1839528fdff2@mail.gmail.com>

Owen,

I like / agree with your suggestion for the "...maintain the/a IPv4
Internet" question progression.  I am updating the chart now to
reflect that change.  Thank you!  I also agree that most if not all of
these variables are still VERY uncertain.  Hopefully if we can all
come to a consensus on the questions, we can start really finding
answers to them as well; instead of just rehashing our own opinions on
the ppml (speaking very generally - not about you, or anyone,
specifically :)).

John,

I don't presume to speak for Owen who proposed that Steve take a look
but I do agree that this would be helpful.  For my part, I was
intentionally vague with my wording, leaving it at just 'risk' because
I fear that there are possibly more potential issues here than I can
imagine.  Although I do assume that the vast majority would fall under
the legal risk category, at least eventually.  When crafting the last
two questions I was thinking specifically of direct legal implications
on the 'liberalized transfer policy' side (could ARIN somehow be
entangled if a transfer involved fraud or other wrong doings) and more
of less directly legal, possibly more perception issues on the 'keep
the policy the same' side (basically in line with what you stated
previously about fulfillment of duties) but this could also become a
legal or political / outside intervention issue if it went far enough.

~Chris


On Wed, Sep 3, 2008 at 7:45 PM, John Curran <jcurran at istaff.org> wrote:
> On Sep 3, 2008, at 8:36 PM, Owen DeLong wrote:
>>
>> True.  Worse yet, to the best of my knowledge, you, like me,
>> do not have a JD and so we're both somewhat underqualified
>> to answer the question at hand which is why I put Steve
>> on the spot.
>
> Understood; as Chair, I'll ask for Steve to look into both
> questions, but to be clear, the questions ask about "risk"
> to ARIN, not specifically legal risk.  I presume you're
> looking for the latter since you indicate that counsel is
> best qualified to answer here.
>
> /John
> Chairman
> ARIN Board of Trustees
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
Chris Grundemann
www.linkedin.com/in/cgrundemann


From iljitsch at muada.com  Thu Sep  4 03:52:14 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Thu, 4 Sep 2008 09:52:14 +0200
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <443de7ad0809031932q68025beep9aaf1839528fdff2@mail.gmail.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
	<7D6AE3E0-D5C5-45D8-A810-4048CFC5C236@delong.com>
	<04631C10-2CD2-47D5-AE3D-EFC349E74E53@istaff.org>
	<CD292BCC-658A-4A59-A64B-C9C6FE05FB99@delong.com>
	<61FF7410-CF14-4433-A008-90BB6910A57E@istaff.org>
	<443de7ad0809031932q68025beep9aaf1839528fdff2@mail.gmail.com>
Message-ID: <F25BAC0B-24F2-42E0-9588-225889185672@muada.com>

On 4 sep 2008, at 4:32, Chris Grundemann wrote:

> "...maintain the/a IPv4 Internet"

The IP version that we end up running should be determined as a result  
of the real requirements of the users. It shouldn't be the starting  
point of any discussion.


From BillD at cait.wustl.edu  Thu Sep  4 05:21:56 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 4 Sep 2008 04:21:56 -0500
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <04631C10-2CD2-47D5-AE3D-EFC349E74E53@istaff.org>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu><443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com><7D6AE3E0-D5C5-45D8-A810-4048CFC5C236@delong.com>
	<04631C10-2CD2-47D5-AE3D-EFC349E74E53@istaff.org>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran
> Sent: Wednesday, September 03, 2008 7:14 PM
> To: Owen DeLong
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] the Transfer Policy Argument Space
> 
> On Sep 3, 2008, at 6:35 PM, Owen DeLong wrote:
> > I, for one, would very much love to hear a direct answer to 
> 4e and the 
> > subsequent opposing question from Steve Ryan.  My 
> impression so far is 
> > that they are approximately equal, but, I do not feel like I have 
> > received any clear indication from Steve on this.
> >
> > OTOH, I suspect that it may be very hard for Steve to do so 
> as these 
> > could be very uncertain.
> 
> Owen -
> 
>    I'm not Steve Ryan (and he's thankful of that :-), but let
>    me pose a thought exercise which may provide some insight
>    into question 4e and its converse...
> 
>    At a point in time when ARIN has effectively no remaining
>    available space to satisfy requests under the current IPv4
>    policy space, how should ARIN best fulfill its incorporation
>    duties to "to enhance the growth of the Internet .. by
>    encouraging the exploration and implementation of solutions
>    to Internet Protocol number scarcity issues"?  For instance,
>    how would two parties seeking to transfer IPv4 address space
>    (e.g. an address holder who could free up significant address
>    space through consolidation efforts, and an ISP constrained by
>    their inability to obtain additional IPv4 number resources)
>    view ARIN's fulfillment of its duties if there is neither a
>    more relaxed transfer policy nor a clear community statement
>    of why such a policy is undesirable?
> 
> /John
> (my views alone; this message was prepared in 100% deaggregate-
>   free route announcements ;-)

John,

In answer the question you pose to Owen... I believe that ARIN has a
duty to loosen its policy IF the circumstances require it to do so.  I
agree with Owen that ARIN's first role is to act as it was incorporate
and does today.  ARIN should encourage entities with free space to
return it.  It should encourage those that can free up some space and
return it to do so...all this as a community response to the anticipated
ending of the free pools of IANA and ARIN.

To the extent that this effort fails, then that failure is not ARIN's
failure in duty, but that of the community holding resources they don't
need.  At some point ARIN should extend the 'emergency' policy of
loosened transfer to nudge the holders and eliminate all but the most
basic administrative overhead to those transfers in order to accommodate
the emergency addressing needs.  That is why I proposed the Emergency
Transfer Policy for IP Addresses which puts the decision to enact in the
hands of the Board of Trustees, but limits its application  to 3 years.
The sunset is meant to compliment ARIN's education and outreach efforts
to encourage the industry to transition to a protocol environment with
greater address space (presumably IPv6).

In this way, ARIN preserves the integrity and the tradition of past
operations under policy, helps to alleviate short-term addressing
concerns, but in no way advocates or by action encourages the delay of
the industry movement away from IPv4.

Bill


> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From Lee.Howard at stanleyassociates.com  Thu Sep  4 10:01:03 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Thu, 4 Sep 2008 10:01:03 -0400
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <48BF0C07.9020602@sprunk.org>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>

> 1. Is there any way to break out new 
> allocation/assignment/transfer expenses vs. general 
> maintenance, so that we can determine the share of expenses 
> attributable to folks who are doing nothing other than 
> holding on to legacy resources, not getting anything new, as 
> well as making sure that the fees for new resources 
> adequately cover the costs of evaluating justification that 
> policy requires?

I don't think it's possible.  I'm not sure how we would measure
the number of IN-ADDR lookups on legacy records only, or how 
many participants on the mailing list only hold legacy resources,
or how much outreach benefits that segment of the community 
alone.  I don't mean to be intractable, but I can't figure out 
how to frame the question in a specific enough way to get a 
meaningful answer.

> 2. What would the fees need to be if they were per-object 
> instead of per-org?  IMHO, this is the key to the whole "a 
> domain only costs $10/yr" argument.

Also a little tough to figure out.  Currently, we allow all 
objects to be rolled up into a single maintenance fee.  I 
haven't examined the records closely, but let's assume that
all Class A and B assignments are classful, and that the
average assignment size in Class C space is a /21 (there are
many Class Cs, but also a good number of CIDR /18 - /20).
let's say there are 90 Class A holders,
36*255=9000 Class B holders, and 
7*255*32=57,000 legacy objects in Class C space.

Approaching 67000 discrete legacy objects, so that's your
denominator.  You can do the math: 67k * $10 is $670,000.
That's 5% of ARIN's 2008 budget.

Would this be fairer?  

We could debate whether that's a fair share, but it would be
a matter of opinion of "fair."

It would mean that those with a single allocation (say, a 
Class A) pay a single low fee, while those with multiple
CIDR allocations pay several times as much.

It would increase the number of invoices and processing ARIN
has to do, but we don't have a way to track our cost-per-
transaction (it's still a fairly small organization).  Plus
the additional work tracking overdue fees, where it's easy
to imagine that tracking late payments could be multiples of
the fee itself.

Another note:  if you can return 25% of your address space,
we'll discount your fees under section 10(a) of the LRSA.

Once more, I'm trying to avoid defending the status quo 
merely because it's quo.  These are legitimate questions that
I think the Treasurer should hear and respond to.  It's true
that I'm prejudiced toward the openness and transparency and
level of service that ARIN provides, but you get to respond
to that prejudice directly, on this list and by voting.

Lee


From Lee.Howard at stanleyassociates.com  Thu Sep  4 10:15:49 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Thu, 4 Sep 2008 10:15:49 -0400
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>


Owen DeLong and Bill Darte said:
> ARIN should encourage entities with free space to return it. 


What form should that encouragement take?

1.  "The ARIN Board of Trustees encourages those entities with
free address space to return it to ARIN."
2.  "The ARIN Board of Trustees offers one large, chewy 
chocolate chip cookie to any entity with free address space 
who returns it to ARIN."
3.  ARIN reduces fees on remaining space.
4.  ARIN offers publicity for those who return space.
5.  ARIN offers prizes to those who return space.  What prizes?
6.  ARIN offers cash to those who return space.  How much?
7.  Fill in the blank _____________________

In case anyone sitting on big chunks of addresses is feeling
discouraged, I encourage you to return space to ARIN.

Not to be pessimistic, but I don't think there's enough unused
address space to matter, unless we also reduce the rate at which
we assign IPv4 address space.

Lee


From lear at cisco.com  Thu Sep  4 10:22:39 2008
From: lear at cisco.com (Eliot Lear)
Date: Thu, 04 Sep 2008 16:22:39 +0200
Subject: [arin-ppml] TPRC Paper on IP Addresses and Transfer Markets:
 "Running on Empty: the Challenge of Managing Internet Addresses"
Message-ID: <48BFEF2F.40108@cisco.com>

Dear all,

We would like to bring to your attention a paper that Bill Lehr, Tom 
Vest, and I wrote for the upcoming TPRC conference, at the end of this 
month, the title of which is "Running on Empty: The Challenge of 
managing Internet addresses".  The paper looks at transfer markets and 
specific proposals from the RIRs and provides pluses and minuses to the 
theoretical space, as well as some commentary on specific proposals.  
The authors concur that the results of the proposed market initiatives 
will likely depend on variety of identifiable parameters (e.g., specific 
transfer policy mechanisms, possible IPv4 reservation policies, secure 
inter-domain routing initiatives, etc.), but do not agree on the 
appropriate weighting of risks.

In talking about specific RIR proposals we note extreme differences in 
what we presume to be the assumptions of the authors about ability to 
enforce regulations and the priorities that an RIR should have.  We also 
look at the impact of transfer markets on IPv6 adoption, and to a lesser 
extent, on the interdependency between addressing and routing.

We hope this paper is useful to continuing a dialog that leads to 
appropriate evolution of RIR policies.  You can find it here 
<http://tprcweb.com/files/Lehr%20Vest%20Lear%20Internet%20Address%20TPRC%208_15_08.pdf> 
or by going to www.tprc.org and looking at the detailed agenda for 
Saturday, along with several other interesting and related papers.

Yours,

Bill Lehr
Tom Vest
Eliot Lear

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080904/9e27c40b/attachment.htm>

From jr at jrw.org  Thu Sep  4 10:44:35 2008
From: jr at jrw.org (J. R. Westmoreland)
Date: Thu, 4 Sep 2008 08:44:35 -0600
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
References: <48BF0C07.9020602@sprunk.org>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
Message-ID: <001601c90e9c$c308ca30$491a5e90$@org>

See below.

--------------------
J. R. Westmoreland
E-mail: jr at jrw.org


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Howard, W. Lee
Sent: Thursday, September 04, 2008 8:01 AM
To: Stephen Sprunk
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] maintenance fees for legacy space holders

> 1. Is there any way to break out new 
> allocation/assignment/transfer expenses vs. general 
> maintenance, so that we can determine the share of expenses 
> attributable to folks who are doing nothing other than 
> holding on to legacy resources, not getting anything new, as 
> well as making sure that the fees for new resources 
> adequately cover the costs of evaluating justification that 
> policy requires?

I don't think it's possible.  I'm not sure how we would measure
the number of IN-ADDR lookups on legacy records only, or how 
many participants on the mailing list only hold legacy resources,
or how much outreach benefits that segment of the community 
alone.  I don't mean to be intractable, but I can't figure out 
how to frame the question in a specific enough way to get a 
meaningful answer.

> 2. What would the fees need to be if they were per-object 
> instead of per-org?  IMHO, this is the key to the whole "a 
> domain only costs $10/yr" argument.

Also a little tough to figure out.  Currently, we allow all 
objects to be rolled up into a single maintenance fee.  I 
haven't examined the records closely, but let's assume that
all Class A and B assignments are classful, and that the
average assignment size in Class C space is a /21 (there are
many Class Cs, but also a good number of CIDR /18 - /20).
let's say there are 90 Class A holders,
36*255=9000 Class B holders, and 
7*255*32=57,000 legacy objects in Class C space.

Approaching 67000 discrete legacy objects, so that's your
denominator.  You can do the math: 67k * $10 is $670,000.
That's 5% of ARIN's 2008 budget.

Would this be fairer?  

[J. R. W. >] Yes. I'd go along with that. In fact, not wanting to be a real
problem, I'd be willing to pay $20 per year. That would be almost 1.3m. I
only hold a class C /24 and have always asked myself about the class A
people getting such a good deal but if legacy space was $20 or $25, being a
small consultant, I'd be much happier and be willing to jump on board.

We could debate whether that's a fair share, but it would be
a matter of opinion of "fair."

It would mean that those with a single allocation (say, a 
Class A) pay a single low fee, while those with multiple
CIDR allocations pay several times as much.

It would increase the number of invoices and processing ARIN
has to do, but we don't have a way to track our cost-per-
transaction (it's still a fairly small organization).  Plus
the additional work tracking overdue fees, where it's easy
to imagine that tracking late payments could be multiples of
the fee itself.

Another note:  if you can return 25% of your address space,
we'll discount your fees under section 10(a) of the LRSA.

Once more, I'm trying to avoid defending the status quo 
merely because it's quo.  These are legitimate questions that
I think the Treasurer should hear and respond to.  It's true
that I'm prejudiced toward the openness and transparency and
level of service that ARIN provides, but you get to respond
to that prejudice directly, on this list and by voting.

Lee
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



From tvest at pch.net  Thu Sep  4 11:02:18 2008
From: tvest at pch.net (Tom Vest)
Date: Thu, 4 Sep 2008 11:02:18 -0400
Subject: [arin-ppml] Argument Space / solving for 3(x=reject all)
In-Reply-To: <443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
Message-ID: <64F32B46-71A0-4DBF-9F28-64DA4D7D5E6F@pch.net>

(note: the diagram seems to be offline at the moment, so I attached  
below a dated screen capture that I took last night)

Hi Chris,

Great tool, thanks for sharing  this! Now that it's out there, I'd  
like to complicate it a little more ;-)

I think it might be possible to solve for 3(x=all fail) in a way that  
is arguably more "fair," much easier to adopt, revise, and if  
necessary *reverse*, and that would be highly robust against external  
challenges. As such, I think it merits some consideration as an  
alternative to the standing resource transfer proposal.

Start with your node focusing on "additional incentive". It may be be  
that the only additional incentive that some operators need is  
assurance that returning *some* address space and incorporating *some*  
IPv6 over time would not cause them to suffer a major competitive  
disadvantage relative to other operators. If that "additional  
assurance" would be sufficient to motivate enough people to get a  
policy proposal adopted (and/or to attract more support than a  
transfer proposal), then perhaps something a bit like what Stephen  
suggested, i.e., "per-object instead of per-org fees" might do the  
trick.

Imagine that at the end of the free pool, annual renewal fees start  
incrementing per /32, but that ARIN offers a "bounty" equal to 100% of  
the new fees to any signatory that agrees to voluntarily return some  
scale-sensitive quantity of IPv4.* For the sake of "simplicity" I'm  
going to illustrate using $1 per IP, rounded up to the nearest  
classful bit boundary for the renewal fee, and define the address  
return required to earn the "bounty" as equal to the next smallest  
classful address block, but many numbers/ratios would probably work  
equally well.

So, for example, the mechanism I'm imagining would oblige a /8 holder  
to return one /16 per year in order to qualify for the bounty, which  
would also effectively make this approach revenue neutral. ARIN would  
never have to handle one penny more than it does today. To make the  
effects consistent across the smaller end of the address distribution  
spectrum, maybe additional fees and bounties are phased out for  
members that retain a /20 or less, until all members are down to  
roughly equivalent sized IPv4 endowments.

*less any added administrative costs, which should be modest.

What would this approach accomplish?

NEW-1: Incremental, inevitable, but (more) predictable effects - No  
matter what, everyone is facing the same reality of doing more with  
less IPv4, or much much more expensive IPv4, and/or perhaps with some  
IPv6. No one should be imagining that making a windfall on the  
transition, or pushing most or all of the costs of transition onto  
future new entrants are sustainable options; they aren't. By the same  
logic, no one should be significantly harmed by parting with 1/256 of  
their existing IPv4 reserves every year, especially if everyone is  
facing the exact same constraint. Given the mechanism's scale- 
sensitive uniform effects, even operators who grudgingly support the  
idea while still hoping/expecting to NEVER make a full transition to  
IPv6 might find comfort in the knowledge that they could have hundreds  
of years to be proven right. See also New-5, below.

NEW-2: Recovery of liquid legacy IPv4 address space - Nothing in this  
approach requires or assumes that ARIN members will return address  
space that they received directly from ARIN, and everyone is already  
assuming the emergence of some kind of gray market (at least) under  
any/all future scenarios. If quietly purchasing IPv4 in a gray market  
looks like a better deal than returning RSA-covered addresses and  
perhaps adopting some IPv6 on the margin, then nothing would  
explicitly prevent people from doing that. Thus legacy/surplus address  
space holders are not absolutely precluded from capitalizing on their  
early efforts / good fortune, but sales do not have to be formally  
condoned, and the whole system does not have to be jeopardized in  
order for that option to be preserved.

3(a= reject): Nothing short of militarization of the process is likely  
to eliminate all speculation/profiteering, but the policy would define  
an implicit "official price" for IPv4 that could help to establish a  
firm ceiling on speculative pricing.

3(b= reject): By leaving ARIN in place as the sole official mediator  
for IPv4 "recirculation" -- not transfers -- the risk of full  
privatization (intentional or unintentional) is reduced to zero.

3(c= reject): IPv4 recovered by ARIN could be warehoused permanently,  
e.g., to assure an eventual return to address space homogeneity  
somewhere down the line, and to send a signal to non-participants that  
IPv4 *will* be obsolete sooner or later (reinforcing New-2).  
Alternately, the proceeds could be put to other uses (e.g., made  
available for subsequent allocations to those willing to pay the same  
$1 per acquisition and renewal fees, with the proceeds returned as  
dividends to the entire community, or selectively and proportionately,  
e.g., for accelerated IPv4 returns). Also:

New-3: Preservation of industry openness - Regardless of how the  
majority of recovered IPv4 is disposed of, enough will always remain  
available -- ideally through 2008-5 style transitional allocations --  
to clearly demonstrate to all internal and external stakeholders that  
all segments of the industry will remain open to new entry in  
perpetuity. Should also help wrt...

New-4: Mitigation of antitrust risks - In the absence of (New-3) large  
IPv4-based service providers will be perpetually at some risk of  
antitrust action. The proposed policy might conceivable redirect some  
of that risk in the RIR's direction, but it seems to me that given the  
pro-open access orientation, a community consensus-supported approach  
like this would probably provide the strongest possible defense  
against any/all antitrust concerns.

3(d= reject): This approach should help to squelch any bets/ 
competitive strategies that an IPv6 transition will never happen. Once  
people get over the psychological hurdle that IPv6 really *is* coming,  
and understand that the transition is not going to be complicated by  
radical uncertainties,  high risk second guessing, or any other new  
competitive traps, expectations about the future will be aligned in  
ways that might accelerate the pace and reduce everyone's pain of  
migration.

3(e= reject): This approach would assure that at, over time,  
progressively more growth will be accommodated by IPv6 rather than  
through de-aggregation. Doesn't solve the IPv6 routing scalability  
issue, but it does preserve the RIR as a potentially self-sustaining  
administrator for any ongoing/future number resource-related needs  
verification, as maintainer of the registration database, provider of  
whois, and a potential anchor for resource certification, et al. --  
and as a viable mechanism for continuing policy deliberation in the  
event that future routing scalability requirements require the same  
kind of coordinated action that helped to mitigate the last such crisis.

New-5: Clean, easiest possible reversability - Unlike the transfer  
proposal, if this approach turns out to have perverse unanticipated  
consequences, it could be terminated or even reversed with a  
(relative) minimum of disruption.

Potential Downside: if IPv4 is permanently warehoused, then any  
potential revenue arising from IPv4 sales would be foregone. If IPv4  
prices are expected to be modest (e.g., modest enough to avoid  
antitrust scrutiny), then perhaps any loss would be equally modest.  
Alternately, the foregone one-time sales revenues could be thought of  
as investments toward a better, NAT free (or NAT-vonlutary-only)  
future. If those future payoffs are deemed to be insufficient,  
returned address space along with cash proceeds from ongoing IPv4  
"recirculation" could be redistributed to community members, but this  
would probably impose substantial new administrative burdens and risks  
on ARIN. However, the second option is neither required nor recommended.

It may sound crazy, but I think it might be among the least crazy  
options open to us at this point.


Reactions? Perhaps others would like to walk 2008-2 through the same  
kind of explanatory process?


TV, speaking for self alone

On Sep 3, 2008, at 3:46 PM, Chris Grundemann wrote:

> Great idea David, I agree 100% that defining / mapping the argument
> space will help everyone to better understand their own position as
> well as the positions of others.
>
> Maybe I am making this more complicated than it needs to be but for me
> to really wrap my head around the entire argument space, I had to take
> a graphical approach. For those interested, it can be found here:
> http://odin.chrisgrundemann.com/Do_I_Support_A_Liberalized_Transfer_Policy.jpg
>
> I am open to suggestions on how this drawing could be improved,
> utilized, discarded, and/or converted to text to complement the list
> you are generating in this thread.
>
> ~Chris


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Grundeman_Argument_Space_080903.jpg
Type: image/jpeg
Size: 186879 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080904/79aa8160/attachment.jpg>

From cgrundemann at gmail.com  Thu Sep  4 11:09:58 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 4 Sep 2008 09:09:58 -0600
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <F25BAC0B-24F2-42E0-9588-225889185672@muada.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
	<7D6AE3E0-D5C5-45D8-A810-4048CFC5C236@delong.com>
	<04631C10-2CD2-47D5-AE3D-EFC349E74E53@istaff.org>
	<CD292BCC-658A-4A59-A64B-C9C6FE05FB99@delong.com>
	<61FF7410-CF14-4433-A008-90BB6910A57E@istaff.org>
	<443de7ad0809031932q68025beep9aaf1839528fdff2@mail.gmail.com>
	<F25BAC0B-24F2-42E0-9588-225889185672@muada.com>
Message-ID: <443de7ad0809040809r3cc09550q90a850f40a9340a7@mail.gmail.com>

On Thu, Sep 4, 2008 at 1:52 AM, Iljitsch van Beijnum <iljitsch at muada.com> wrote:
> On 4 sep 2008, at 4:32, Chris Grundemann wrote:
>
>> "...maintain the/a IPv4 Internet"
>
> The IP version that we end up running should be determined as a result of
> the real requirements of the users. It shouldn't be the starting point of
> any discussion.
>
I was not attempting to determine the version to run, merely including
all the options.  I think it is an important part of this discussion
and should be included in any argument for or against a liberalized
transfer policy.  If you believe that IPv6 is a joke and that IPv4
will continue as the dominant Internet protocol for the foreseeable
future; that is going to be a major influence on how you approach the
ltp argument, no?


-- 
Chris Grundemann
www.linkedin.com/in/cgrundemann


From cgrundemann at gmail.com  Thu Sep  4 11:29:50 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 4 Sep 2008 09:29:50 -0600
Subject: [arin-ppml] Argument Space / solving for 3(x=reject all)
In-Reply-To: <64F32B46-71A0-4DBF-9F28-64DA4D7D5E6F@pch.net>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
	<64F32B46-71A0-4DBF-9F28-64DA4D7D5E6F@pch.net>
Message-ID: <443de7ad0809040829k67410e46tfe463818464ee0fc@mail.gmail.com>

On Thu, Sep 4, 2008 at 9:02 AM, Tom Vest <tvest at pch.net> wrote:
> (note: the diagram seems to be offline at the moment, so I attached below a
> dated screen capture that I took last night)

Diagram back online - Thanks Tom!
~Chris


From BillD at cait.wustl.edu  Thu Sep  4 12:05:24 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 4 Sep 2008 11:05:24 -0500
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>

My personal opinion is:

"The ARIN Board of Trustees on behalf of ARIN and the community at large
requests that as a service to that community, holders of address space
which is available to return, or which they are willing to make
available for return, should do so at their earliest convenience.  On
behalf of the community that will need these addresses as the industry
transitions to IPv6, ARIN thanks you."

bd

 

> -----Original Message-----
> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] 
> Sent: Thursday, September 04, 2008 9:16 AM
> To: Bill Darte; John Curran; Owen DeLong
> Cc: arin-ppml at arin.net
> Subject: RE: [arin-ppml] the Transfer Policy Argument Space
> 
> 
> Owen DeLong and Bill Darte said:
> > ARIN should encourage entities with free space to return it. 
> 
> 
> What form should that encouragement take?
> 
> 1.  "The ARIN Board of Trustees encourages those entities 
> with free address space to return it to ARIN."
> 2.  "The ARIN Board of Trustees offers one large, chewy 
> chocolate chip cookie to any entity with free address space 
> who returns it to ARIN."
> 3.  ARIN reduces fees on remaining space.
> 4.  ARIN offers publicity for those who return space.
> 5.  ARIN offers prizes to those who return space.  What prizes?
> 6.  ARIN offers cash to those who return space.  How much?
> 7.  Fill in the blank _____________________
> 
> In case anyone sitting on big chunks of addresses is feeling 
> discouraged, I encourage you to return space to ARIN.
> 
> Not to be pessimistic, but I don't think there's enough 
> unused address space to matter, unless we also reduce the 
> rate at which we assign IPv4 address space.
> 
> Lee
> 


From llynch at civil-tongue.net  Thu Sep  4 12:15:38 2008
From: llynch at civil-tongue.net (Lucy Lynch)
Date: Thu, 4 Sep 2008 09:15:38 -0700 (PDT)
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
Message-ID: <alpine.BSF.1.10.0809040908520.17102@hiroshima.bogus.com>

+1

Simple, elegant, in the spirit of the "old Internet", and
polite! How often do we see that these days?

- Lucy

On Thu, 4 Sep 2008, Bill Darte wrote:

> My personal opinion is:
>
> "The ARIN Board of Trustees on behalf of ARIN and the community at large
> requests that as a service to that community, holders of address space
> which is available to return, or which they are willing to make
> available for return, should do so at their earliest convenience.  On
> behalf of the community that will need these addresses as the industry
> transitions to IPv6, ARIN thanks you."
>
> bd
>
>
>
>> -----Original Message-----
>> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com]
>> Sent: Thursday, September 04, 2008 9:16 AM
>> To: Bill Darte; John Curran; Owen DeLong
>> Cc: arin-ppml at arin.net
>> Subject: RE: [arin-ppml] the Transfer Policy Argument Space
>>
>>
>> Owen DeLong and Bill Darte said:
>>> ARIN should encourage entities with free space to return it.
>>
>>
>> What form should that encouragement take?
>>
>> 1.  "The ARIN Board of Trustees encourages those entities
>> with free address space to return it to ARIN."
>> 2.  "The ARIN Board of Trustees offers one large, chewy
>> chocolate chip cookie to any entity with free address space
>> who returns it to ARIN."
>> 3.  ARIN reduces fees on remaining space.
>> 4.  ARIN offers publicity for those who return space.
>> 5.  ARIN offers prizes to those who return space.  What prizes?
>> 6.  ARIN offers cash to those who return space.  How much?
>> 7.  Fill in the blank _____________________
>>
>> In case anyone sitting on big chunks of addresses is feeling
>> discouraged, I encourage you to return space to ARIN.
>>
>> Not to be pessimistic, but I don't think there's enough
>> unused address space to matter, unless we also reduce the
>> rate at which we assign IPv4 address space.
>>
>> Lee
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From farmer at umn.edu  Thu Sep  4 12:43:46 2008
From: farmer at umn.edu (David Farmer)
Date: Thu, 04 Sep 2008 11:43:46 -0500
Subject: [arin-ppml] rETRUN iNCENTIVES (WAS: the Transfer Policy
	Argument Space)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>,
	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>,
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
Message-ID: <48BFC9F2.14211.225A912@farmer.umn.edu>

This is really truning into a sperated discussion from figuring out the 
Argument Space, into a discussion of issues, a good Discussion, but it 
should be a separate thread please.

------

Comments below;

On 4 Sep 2008 Bill Darte wrote:

> My personal opinion is:
> 
> "The ARIN Board of Trustees on behalf of ARIN and the community at
> large requests that as a service to that community, holders of address
> space which is available to return, or which they are willing to make
> available for return, should do so at their earliest convenience.  On
> behalf of the community that will need these addresses as the industry
> transitions to IPv6, ARIN thanks you."
> 
> bd

So why do you think this will be anymore effective than RFC 1917?

I also think 4.1 of RFC1917 is interesting, in a previous thread I asked why a 
transfer policy isn't more desirable than what is suggested there?


> > -----Original Message-----
> > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] Sent:
> > Thursday, September 04, 2008 9:16 AM To: Bill Darte; John Curran;
> > Owen DeLong Cc: arin-ppml at arin.net Subject: RE: [arin-ppml] the
> > Transfer Policy Argument Space
> > 
> > 
> > Owen DeLong and Bill Darte said:
> > > ARIN should encourage entities with free space to return it. 
> > 
> > 
> > What form should that encouragement take?
> > 
> > 1.  "The ARIN Board of Trustees encourages those entities 
> > with free address space to return it to ARIN."
> > 2.  "The ARIN Board of Trustees offers one large, chewy 
> > chocolate chip cookie to any entity with free address space 
> > who returns it to ARIN."
> > 3.  ARIN reduces fees on remaining space.
> > 4.  ARIN offers publicity for those who return space.
> > 5.  ARIN offers prizes to those who return space.  What prizes? 6. 
> > ARIN offers cash to those who return space.  How much? 7.  Fill in
> > the blank _____________________
> > 
> > In case anyone sitting on big chunks of addresses is feeling 
> > discouraged, I encourage you to return space to ARIN.
> > 
> > Not to be pessimistic, but I don't think there's enough 
> > unused address space to matter, unless we also reduce the 
> > rate at which we assign IPv4 address space.
> > 
> > Lee
> > 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From farmer at umn.edu  Thu Sep  4 12:50:17 2008
From: farmer at umn.edu (David Farmer)
Date: Thu, 04 Sep 2008 11:50:17 -0500
Subject: [arin-ppml] Retrun Incentives (WAS: the Transfer Policy
	Argument Space)
In-Reply-To: <48BFC9F2.14211.225A912@farmer.umn.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>,
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>,
	<48BFC9F2.14211.225A912@farmer.umn.edu>
Message-ID: <48BFCB79.19498.22BA174@farmer.umn.edu>

Sorry, about the Caps Lock state table problem in the subject line; :-(

While I'm here FYI RFC 1917 is also known as BCP 4

On 4 Sep 2008 David Farmer wrote:

> This is really truning into a sperated discussion from figuring out
> the Argument Space, into a discussion of issues, a good Discussion,
> but it should be a separate thread please.
> 
> ------
> 
> Comments below;
> 
> On 4 Sep 2008 Bill Darte wrote:
> 
> > My personal opinion is:
> > 
> > "The ARIN Board of Trustees on behalf of ARIN and the community at
> > large requests that as a service to that community, holders of
> > address space which is available to return, or which they are
> > willing to make available for return, should do so at their earliest
> > convenience.  On behalf of the community that will need these
> > addresses as the industry transitions to IPv6, ARIN thanks you."
> > 
> > bd
> 
> So why do you think this will be anymore effective than RFC 1917?
> 
> I also think 4.1 of RFC1917 is interesting, in a previous thread I
> asked why a transfer policy isn't more desirable than what is
> suggested there?
> 
> 
> > > -----Original Message-----
> > > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com]
> > > Sent: Thursday, September 04, 2008 9:16 AM To: Bill Darte; John
> > > Curran; Owen DeLong Cc: arin-ppml at arin.net Subject: RE:
> > > [arin-ppml] the Transfer Policy Argument Space
> > > 
> > > 
> > > Owen DeLong and Bill Darte said:
> > > > ARIN should encourage entities with free space to return it. 
> > > 
> > > 
> > > What form should that encouragement take?
> > > 
> > > 1.  "The ARIN Board of Trustees encourages those entities 
> > > with free address space to return it to ARIN."
> > > 2.  "The ARIN Board of Trustees offers one large, chewy 
> > > chocolate chip cookie to any entity with free address space 
> > > who returns it to ARIN."
> > > 3.  ARIN reduces fees on remaining space.
> > > 4.  ARIN offers publicity for those who return space.
> > > 5.  ARIN offers prizes to those who return space.  What prizes? 6.
> > > ARIN offers cash to those who return space.  How much? 7.  Fill in
> > > the blank _____________________
> > > 
> > > In case anyone sitting on big chunks of addresses is feeling
> > > discouraged, I encourage you to return space to ARIN.
> > > 
> > > Not to be pessimistic, but I don't think there's enough 
> > > unused address space to matter, unless we also reduce the 
> > > rate at which we assign IPv4 address space.
> > > 
> > > Lee
> > > 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> 
> 
> =======================================================
> David Farmer				     Email:	farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota			     Phone:	612-626-0815
> 2218 University Ave SE			     Cell:		612-812-9952
> Minneapolis, MN 55414-3029		     FAX:	612-626-1818
> =======================================================
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From stephen at sprunk.org  Thu Sep  4 12:54:51 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Thu, 04 Sep 2008 11:54:51 -0500
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
Message-ID: <48C012DB.2040707@sprunk.org>

Bill Darte wrote:
> My personal opinion is:
>
> "The ARIN Board of Trustees on behalf of ARIN and the community at large
> requests that as a service to that community, holders of address space
> which is available to return, or which they are willing to make
> available for return, should do so at their earliest convenience.  On
> behalf of the community that will need these addresses as the industry
> transitions to IPv6, ARIN thanks you."
>   

I think that's a great statement.  However, playing Devil's Advocate for 
a moment, how are you going to get past the argument that those orgs, 
rather than return space for free today, may be able to wait a few years 
and sell that space to the highest bidder?  Unless one believes that the 
odds of a liberalized transfer policy being adopted are exactly zero, 
it's in the org's selfish interest _not_ to return space.

S


From owen at delong.com  Thu Sep  4 13:07:49 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Sep 2008 10:07:49 -0700
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
Message-ID: <3CD0FFF0-8AA2-45BD-8D7A-0724B245EAFD@delong.com>


On Sep 4, 2008, at 7:15 AM, Howard, W. Lee wrote:

>
> Owen DeLong and Bill Darte said:
>> ARIN should encourage entities with free space to return it.
>
>
> What form should that encouragement take?
>
> 1.  "The ARIN Board of Trustees encourages those entities with
> free address space to return it to ARIN."

This is a no-brainer, and, should be done regardless of whatever
else we do or not in this regard.
>
> 2.  "The ARIN Board of Trustees offers one large, chewy
> chocolate chip cookie to any entity with free address space
> who returns it to ARIN."

With or without nuts? Seriously, cookies, I don't think so, but,
I think that some form of "carrot" (no, I don't mean literal
carrots) is not necessarily a bad idea.
>
> 3.  ARIN reduces fees on remaining space.

This would not be a bad start and as you point out in your
previous message, this has already been done on the
LRSA to some extent.
>
> 4.  ARIN offers publicity for those who return space.

Probably not a bad idea for those that want the publicity.
>
> 5.  ARIN offers prizes to those who return space.  What prizes?

I think this is a duplicate of item 2, but, I could be wrong.
I'm not sure what kind of prizes could be effective in this area,
but, I think it is worthy of some research.
>
> 6.  ARIN offers cash to those who return space.  How much?

To me, cash is just a different form of prize/reward/carrot.
I would consolidate 2, 5, and 6 in this case.  However, the
fact that 3 of your 7 suggestions revolve around ARIN
providing carrots would seem to indicate that it is worthy
of consideration.

>
> 7.  Fill in the blank _____________________
>
If I come up with something, I'll definitely let you know.

> In case anyone sitting on big chunks of addresses is feeling
> discouraged, I encourage you to return space to ARIN.
>
> Not to be pessimistic, but I don't think there's enough unused
> address space to matter, unless we also reduce the rate at which
> we assign IPv4 address space.
>
Not at all.  However, thought exercise... If you think a liberalized
transfer policy would help, but, address returns would not... What
is it about the transfer policy that is more effective than an incentive
program for returns?  Would it be possible to make the return
incetives as effective?

Owen



From mksmith at adhost.com  Thu Sep  4 13:26:24 2008
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Thu, 4 Sep 2008 10:26:24 -0700
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <48C012DB.2040707@sprunk.org>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com><EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
	<48C012DB.2040707@sprunk.org>
Message-ID: <17838240D9A5544AAA5FF95F8D52031604903BD1@ad-exh01.adhost.lan>

> 
> Bill Darte wrote:
> > My personal opinion is:
> >
> > "The ARIN Board of Trustees on behalf of ARIN and the community at large
> > requests that as a service to that community, holders of address space
> > which is available to return, or which they are willing to make
> > available for return, should do so at their earliest convenience.  On
> > behalf of the community that will need these addresses as the industry
> > transitions to IPv6, ARIN thanks you."
> >
> 
> I think that's a great statement.  However, playing Devil's Advocate for
> a moment, how are you going to get past the argument that those orgs,
> rather than return space for free today, may be able to wait a few years
> and sell that space to the highest bidder?  Unless one believes that the
> odds of a liberalized transfer policy being adopted are exactly zero,
> it's in the org's selfish interest _not_ to return space.
> 
> S

I love the statement, particularly because it doesn't address the sale of IP's at all, nor should it have to.  This is a PSA, not a policy, IMO.

Regards,

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080904/3e334809/attachment.sig>

From farmer at umn.edu  Thu Sep  4 13:39:27 2008
From: farmer at umn.edu (David Farmer)
Date: Thu, 04 Sep 2008 12:39:27 -0500
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>,
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
Message-ID: <48BFD6FF.1976.258A477@farmer.umn.edu>

On 3 Sep 2008 Chris Grundemann wrote:

> Great idea David, I agree 100% that defining / mapping the argument
> space will help everyone to better understand their own position as
> well as the positions of others.

Actually, I think what you created is closer to what is known as a Decision 
Tree, rather than an Argument Map, but they serve much the same purpose.  
And if people are more comfortable with the Question/Option(Answer) form 
rather than a Premis/Conclusion form that is fine with me.

For a little refereance see:
http://en.wikipedia.org/wiki/Argument_map
http://en.wikipedia.org/wiki/Decision_tree

Note: Maybe a Decision Tree is the way to go you can put probabilities on 
the options and crank out an answer if you want to do that kind of thing

> Maybe I am making this more complicated than it needs to be but for me
> to really wrap my head around the entire argument space, I had to take
> a graphical approach. 

No this is complicated, that was my point.  I wanted to do something 
graphically, but I wanted to get input on the parts first, and I wasn't quite 
sure how I wanted to represent it.  But, since you did that work I'm happy to 
go with what you got. 

> For those interested, it can be found here:
> http://odin.chrisgrundemann.com/Do_I_Support_A_Liberalized_Transfer_Po
> licy.jpg

What did you use to make it?  Could you make the native form available?  If 
people think it would help, I'm happy to make some large format printouts 
and bring them to LA to put up as a posters on a couple walls, to facilitate 
discussion.  (It is really nice to have the CAD guys down the hall with their 
large format printer :-))  

> I am open to suggestions on how this drawing could be improved,
> utilized, discarded, and/or converted to text to complement the list
> you are generating in this thread.

Rather that attaching the yes output of "Are liberlized Address transfers 
helpful to maintain the/a IPv4 Internet" to "will speculators ....." I would attach 
it to "will address holders return unused space without additional incentives"

I think some of Lee Howard's comments are interesting too, maybe try 
incorporating some of them too.

> ~Chris

Thanks and happy to have you run with the idea, let me know if you need to 
hand it back.  I don't want it to drop, but I don't have the me the one that 
runs with it. 


=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From BillD at cait.wustl.edu  Thu Sep  4 13:47:21 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 4 Sep 2008 12:47:21 -0500
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <48C012DB.2040707@sprunk.org>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
	<48C012DB.2040707@sprunk.org>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030877AD37E@ex1.cait.wustl.edu>

Apparently it has always been so...to wait and not return the space.
Nothing has changed in that.

I also think that it is not in the interest of the industry for ARIN to
advocate for a 'paid' transfer market.
Indeed, I think it is in the interest of the industry for ARIN to abhor
it.

If people to not want to play nice in the sandbox, then someone else may
end up making the rules. Those that want to profit by not making excess
resources available run the very real risk (IMO) that the governance
model will change. 

The rules are what they are, the tradition is what it has been,.... that
self-governance model and working together has been very successful.  

bd



> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
> Sent: Thursday, September 04, 2008 11:55 AM
> To: Bill Darte
> Cc: Howard, W. Lee; John Curran; Owen DeLong; arin-ppml at arin.net
> Subject: Re: [arin-ppml] the Transfer Policy Argument Space
> 
> Bill Darte wrote:
> > My personal opinion is:
> >
> > "The ARIN Board of Trustees on behalf of ARIN and the community at 
> > large requests that as a service to that community, holders 
> of address 
> > space which is available to return, or which they are 
> willing to make 
> > available for return, should do so at their earliest 
> convenience.  On 
> > behalf of the community that will need these addresses as 
> the industry 
> > transitions to IPv6, ARIN thanks you."
> >   
> 
> I think that's a great statement.  However, playing Devil's 
> Advocate for a moment, how are you going to get past the 
> argument that those orgs, rather than return space for free 
> today, may be able to wait a few years and sell that space to 
> the highest bidder?  Unless one believes that the odds of a 
> liberalized transfer policy being adopted are exactly zero, 
> it's in the org's selfish interest _not_ to return space.
> 
> S
> 


From cliffb at cjbsys.bdb.com  Thu Sep  4 13:56:11 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Thu, 4 Sep 2008 13:56:11 -0400 (EDT)
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <alpine.BSF.1.10.0809040908520.17102@hiroshima.bogus.com> from
	"Lucy Lynch" at Sep 04, 2008 09:15:38 AM
Message-ID: <200809041756.m84HuCAH010208@cjbsys.bdb.com>

+2

Cliff
> 
> +1
> 
> Simple, elegant, in the spirit of the "old Internet", and
> polite! How often do we see that these days?
> 
> - Lucy
> 
> On Thu, 4 Sep 2008, Bill Darte wrote:
> 
> > My personal opinion is:
> >
> > "The ARIN Board of Trustees on behalf of ARIN and the community at large
> > requests that as a service to that community, holders of address space
> > which is available to return, or which they are willing to make
> > available for return, should do so at their earliest convenience.  On
> > behalf of the community that will need these addresses as the industry
> > transitions to IPv6, ARIN thanks you."
> >
> > bd
> >
> >
> >
> >> -----Original Message-----
> >> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com]
> >> Sent: Thursday, September 04, 2008 9:16 AM
> >> To: Bill Darte; John Curran; Owen DeLong
> >> Cc: arin-ppml at arin.net
> >> Subject: RE: [arin-ppml] the Transfer Policy Argument Space
> >>
> >>
> >> Owen DeLong and Bill Darte said:
> >>> ARIN should encourage entities with free space to return it.
> >>
> >>
> >> What form should that encouragement take?
> >>
> >> 1.  "The ARIN Board of Trustees encourages those entities
> >> with free address space to return it to ARIN."
> >> 2.  "The ARIN Board of Trustees offers one large, chewy
> >> chocolate chip cookie to any entity with free address space
> >> who returns it to ARIN."
> >> 3.  ARIN reduces fees on remaining space.
> >> 4.  ARIN offers publicity for those who return space.
> >> 5.  ARIN offers prizes to those who return space.  What prizes?
> >> 6.  ARIN offers cash to those who return space.  How much?
> >> 7.  Fill in the blank _____________________
> >>
> >> In case anyone sitting on big chunks of addresses is feeling
> >> discouraged, I encourage you to return space to ARIN.
> >>
> >> Not to be pessimistic, but I don't think there's enough
> >> unused address space to matter, unless we also reduce the
> >> rate at which we assign IPv4 address space.
> >>
> >> Lee
> >>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20740
cliffb at cjbsys.bdb.com http://www.bdb.com
Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/


From owen at delong.com  Thu Sep  4 13:52:52 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Sep 2008 10:52:52 -0700
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <001601c90e9c$c308ca30$491a5e90$@org>
References: <48BF0C07.9020602@sprunk.org>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
	<001601c90e9c$c308ca30$491a5e90$@org>
Message-ID: <F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>

>
> Approaching 67000 discrete legacy objects, so that's your
> denominator.  You can do the math: 67k * $10 is $670,000.
> That's 5% of ARIN's 2008 budget.
>
> Would this be fairer?
>
> [J. R. W. >] Yes. I'd go along with that. In fact, not wanting to be  
> a real
> problem, I'd be willing to pay $20 per year. That would be almost  
> 1.3m. I
> only hold a class C /24 and have always asked myself about the class A
> people getting such a good deal but if legacy space was $20 or $25,  
> being a
> small consultant, I'd be much happier and be willing to jump on board.
>
But, to meet ARIN's current budget, everyone would need to go to
$200 per object... ($10 got you to 5% of the budget, so, you need
20 times that to meet the budget)

> We could debate whether that's a fair share, but it would be
> a matter of opinion of "fair."
>
The problem with this theory is that it ends up treating
assignments and allocations the same.  Allocations have
a disproportionately higher impact on ARIN registration
services than do assignments.  Assignments are made,
then enter a maintenance mode.  Allocations, OTOH,
involve SWIPs, RWHOIS, and churn of the way they
are carved, reclaimed, re-carved, etc. into sub-allocations.

> It would mean that those with a single allocation (say, a
> Class A) pay a single low fee, while those with multiple
> CIDR allocations pay several times as much.
>
It would mean that large mega-ISPs would pay a few
object fees while consuming a very large fraction of the
IP address space, often paying less than mid-size
multi-homed enterprises who got many different
blocks over time.  This could lead to substantially
increased use of the recently adopted aggregation
policy, but, that would lead to an increase in fees
if it did.

Owen



From cliffb at cjbsys.bdb.com  Thu Sep  4 13:40:43 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Thu, 04 Sep 2008 13:40:43 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
Message-ID: <48C01D9B.10400@cjbsys.bdb.com>

Having been reading this group for approaching a year or so now, I think
I've seen the problem with adopting IPv6.  Nobody really wants it.
There is no CEO in the world sitting around saying "Boy I can't wait to
get us on IPv6" and there is no Joe Sixpack sitting at home who gives a
rats a** about IPv6 vs IPv4.  They want to get to Google or ESPN or 
their favorite porn site or their favorite gaming site or gambling site.

The problem:  There is no compatibility bit in IPv6 that says I'm just
like IPv4 but I have 96 more address bits.  Lacking this, I think the
only way to get IPv6 going is to develop a transparent IPv6 to IPv4
translator and convert the entire "Internet backbone" to IPv6.  If I'm
reading stuff correctly, something like NAT64 is a good starting point
but there is more required.  The backbone for the Internet will have to
be IPv6, DNS will have to be IPv6 and IPv4 will be treated as IPv6 on
the Internet and translated through the "converter box (CB)".  This
means that the CB will have to do both translation and DNS lookups for
the v4 hosts.  Since there are 64 bits per subnet in IPv6, there will
never be a subnet that can't split off IPv4 addresses through the CB for
translation.

That's a short summary of a big problem but I think it's obvious that
there has been little real adoption of IPv6.  We really need a program
that accomplishes what the US HDTV program did.  Tell people that "on
MM/DD/YY, the Internet backbone will be IPv6 only.  If you want to run
IPv4, you will need one(or more) of the converter boxes for your IPv4
addresses.  If you don't do this, you will lose Internet connectivity"

Advantages to this include

1.  All IPv4 space effectively becomes PI space since you can tuck your
IPv4 into any IPv6 subnet and not have to change anything but the
address of your CB(s).

2.  Routing tables should shrink since IPv4 can be removed and there
should be better aggregation.

3.  You don't throw out all the old IPv4 only systems/software.  Old
games work.  Old PCs work

4.  IPv4 local networks can still talk to IPv4 local networks across the
world "transparently". Any IPv4 browser should be able to go through the
CB and get to Google or any other web server.

5  Those who want to take advantage of the fancy parts of IPv6 can still
do so.

6.  No tunneling only translation.

7.  As time goes by, more and more of the Internet will become native
IPv6 and the conversion boxes can be retired but it should always be
possible to have that converter box to allow running some oddball old
software.  (I still have a 386 in my basement that runs DOS with packet
drivers and can telnet to any host that lets me have an account.)

I'm sure people can come up with  all kinds of reasons why this won't
work but let's face it; right now IPv6 is a dud.  Sure it works but it
can't talk to IPv4 simply and transparently and if the converter box
discussed above is technically impossible, IPv6 doesn't deserve to be
the next generation of IP addressing.  If the converter box works (and
it has to work with all of IPv4) then the only way to get people to IPv6
is to do something similar to what is discussed above.  I'm not
particularly pro or con re IPv6, I just see it not working in the
present method of rolling it out.  The U. S. government mandate of using
IPv6 is very reminiscent of the great GOSIP debacle of the 1990s and if
something doesn't change in how we do this, I frankly see IPv6 dying out
and a smaller group of good engineers will come up with something that
works instead of a protocol designed by an overly large committee that
wants everything but the kitchen sink.

Look at the successful conversions of the past.  The latest Pentium will
run MS DOS.  I can watch HDTV on my old TV, I believe it was IBM 360s
which ran "an older machine"(somebody here will remember) in emulation
mode.  The latest DVD drive can still play a CD.  People will adopt
something because it works for them without a lot of fuss or it is a
disruptive technology that offers something worth the conversion to
something new (think iPod).  I don't see IPv6 as ever being a disruptive
technology so it is going to have to be backward compatible in some way
or it will die.

Cliff








From stephen at sprunk.org  Thu Sep  4 14:01:43 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Thu, 04 Sep 2008 13:01:43 -0500
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
Message-ID: <48C02287.8040702@sprunk.org>

Howard, W. Lee wrote:
>> 1. Is there any way to break out new allocation/assignment/transfer expenses vs. general maintenance, so that we can determine the share of expenses attributable to folks who are doing nothing other than holding on to legacy resources, not getting anything new, as well as making sure that the fees for new resources adequately cover the costs of evaluating justification that policy requires?
>>     
>
> I don't think it's possible.  I'm not sure how we would measure the number of IN-ADDR lookups on legacy records only, or how many participants on the mailing list only hold legacy resources, or how much outreach benefits that segment of the community alone.  I don't mean to be intractable, but I can't figure out how to frame the question in a specific enough way to get a meaningful answer.
>   

I see how that is a difficult question to answer.  What about limiting 
it to this:

"What portion of ARIN's expenses are for (a) processing new 
applications, (b) maintaining existing registrations, and (c) providing 
other 'free' services to the community."

I expect (b) would include DNS and WHOIS expenses, while (c) would 
include meetings, mailing lists, outreach, etc.  I understand ARIN 
doesn't track things this way so you won't have the exact numbers, but 
your rough estimates would be more useful than my uninformed guesses :)

>> 2. What would the fees need to be if they were per-object instead of per-org?  IMHO, this is the key to the whole "a domain only costs $10/yr" argument.
>>     
>
> Also a little tough to figure out.  Currently, we allow all objects to be rolled up into a single maintenance fee.  I haven't examined the records closely, but let's assume that all Class A and B assignments are classful, and that the average assignment size in Class C space is a /21 (there are many Class Cs, but also a good number of CIDR /18 - /20).  let's say there are 90 Class A holders, 36*255=9000 Class B holders, and 7*255*32=57,000 legacy objects in Class C space.
>
> Approaching 67000 discrete legacy objects, so that's your denominator.  You can do the math: 67k * $10 is $670,000.  That's 5% of ARIN's 2008 budget.
>   

Okay, so assuming 100% of legacy holders signed the LRSA, to get the 
same revenue as $100/org we'd need to set the fee at $13.21/object.  Or, 
to put it another way, $100/org assumes an average of 7.5 objects/org.  
Obviously, orgs with fewer than 7.5 objects would prefer the per-object 
fee model...

Of course, one side effect of setting the fee structure that way is that 
some orgs would attempt to reduce the number of objects they held in 
order to reduce their fees.  These might be outright returns, which 
would push out exhaustion slightly, or they might be aggregation 
requests, which would pull it in.  I have no clue which effect would be 
stronger, but I'm guessing it'd be minimal either way since the cost of 
renumbering will far outweigh the savings in fees for most orgs.

Also, that ignores the effect that a per-object fee structure would have 
on the willingness of orgs with many objects to sign an LRSA in the 
first place.

> Would this be fairer?  
>
> We could debate whether that's a fair share, but it would be a matter of opinion of "fair."
>
> It would mean that those with a single allocation (say, a Class A) pay a single low fee, while those with multiple CIDR allocations pay several times as much.
>   

It's definitely an interesting definition of "fair" where one registrant 
holding a single /8 would pay less than another holding two /24s, but 
we're already partway down that path today by charging them the same 
amount...

S


From narten at us.ibm.com  Thu Sep  4 14:36:13 2008
From: narten at us.ibm.com (Thomas Narten)
Date: Thu, 04 Sep 2008 14:36:13 -0400
Subject: [arin-ppml] Pros and Cons of a liberalized transfer policy
In-Reply-To: <48BE48BB.29942.2FA0005@farmer.umn.edu>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
Message-ID: <200809041836.m84IaDlw009567@cichlid.raleigh.ibm.com>

> Therefore, in this thread I would like some help to map out the argument 
> space we are working with.  I would like us to intentionally simplify the 
> arguments and gloss over many of the nuances.  What I'm asking for us to 
> do is map out the breath and shape of the argument space we are dealing 
> with here, rather than to perfectly capture the nuances of each
> argument.

Here is my summary based on what I have seen in the last 2 weeks
(and I don't think arguments have changed much in a VERY long time):

Is there anything I am missing?

To be helpful, it is probably not useful to expand on these in a lot
of detail. I think many of the frequent posters have made their
positions clear many times over. What I am interested in hearing is
whether there is another argument (pro or con) that is not covered
adequately below.

Why a revised transfer policy is needed:

 - buy/selling/trading of address blocks already happens
   today. Sometimes directly (recent Ebay sale attempt), sometimes
   less directly (i.e., as an "asset" in a larger merger/acquisition).

   To the degree that ARIN can step in and bring clarity to the market
   (i.e., legitimize true ownership of a block, record transfers in
   whois, in-addr.arpa, etc.), this helps/benefits the community at
   large

 - provide incentive to holders to return underutlized blocks. (there
   is non-zero cost associated with doing this), and holders that have
   space to return today have no incentive to do the work (spend the
   $$) if they get nothing in return, not even cost recovery. 

 - we will exhaust the IPv4 free pool; transfer policies will increase
   (perhaps only slightly) the availability of unused address blocks
   to sites after ARIN runs out

     - unclear who will sell and who will buy. Big users (large ISPs)
       need large blocks, which will be in the most short supply.

 - ARIN will become increasingly irrelevant if trading/selling goes on
   and it has no role (e.g., with WHOIS, impacting minimum prefix
   sizes, etc.). But since market pressures will cause buy/selling to
   happen no matter what, ARIN will make itself irrelevent if it has
   no role. When an ISP/enterprise needs space, and one way to get it
   is to shell out $$, if the price is right (compared to other
   options), they will do so.

   Today, ARIN does have influence over block sizes and deaggration
   and such. Not complete influence, but some. If transfers happen
   outside of ARIN's influence, ARIN's ability to influence/curb
   undesirable behavior decreases. In the worst case, ARIN has no role
   whatsoever.

 - The broader community not served by having whois/in-addr.arpa data
   increasingly wrong. It is not the actual owner of the block that
   suffers when such information is wrong, it is the rest of the
   community. ARIN should be doing all that it can to maintain
   accurate information. 

 - other RIRs will have a transfer policy doing it, and ARIN will
   stick out if it does not. There is only one global internet after
   all...

 - IPv6 is not deployed today and won't be before exhaustion. Public
   IPv4 addresses will still be needed for transition. A revised
   transfer policy is part of ensuring such address space remains
   available.

 - Roughly 50% of the assigned space is "legacy", meaning it was
   assigned before the RIRs existed. Moreover, the vast majority of
   underutilized space is in the legacy area, when larger blocks were
   given out to the early adopters.  The vast number of legacy holders
   also happen to be in the ARIN region
   (http://www.nro.net/documents/presentations/jointstats.v1.0608.pdf). With
   ARIN responsible for so much of the legacy space, ARIN's transfer
   policy (or lack thereof) will have the most impact across all the
   RIRs

 - one of the key hindrances today with IPv6 deployment (or lack
   thereof) is the unclear ROI. Having addressing markets - with clear
   costs associated with obtaining IPv4 addresses helps externalize
   the actual cost of IPv4 address exhaustion. Having a market with
   real $$ amounts associated with IPv4 addresses will help justify
   the cost of moving to IPv4.

 - IPv4 is not going away anytime soon, regardless of IPv6
   uptake. Even when/if IPv6 becomes widely used, there will still be
   legacy usages. Prudent stewardship of those IPv4 addresses will
   still be relevant.

 - clear ownership titles for address blocks will become increasingly
   important in the future. We can't secure routing, without being
   able to identify who is is authorized to speak on behalf of
   particular address blocks. Today, RIRs provide such information via
   WHOIS and in-addr.arpa delegations. In the future, via signed
   certificates. This is needed to keep to keep the internet running
   securely and stably (i.e, track down spam/abuse/law
   enforcement/etc.). Of course, this sort of info is only useful if
   it reflects is accurate and reflects reality.
 

Cons:

 - address trading/buying/selling doesn't happen. So, there is no
   reason to do this. [yes, some people still say this.]
   
 - nothing is needed. addresses are not property. The current system
   is working just fine. (buy/selling of addresses does not happen
   today) [although perhaps an extreme view, I have seen this view
   expressed repeatedly]

 - Liberalizing the transfer policy will cause a market to develop. We
   would be facilite creation of a system that has many
   downsides. Best not to go there at all.

 - Legitimizing address markets will increase fragmentation of address
   space, contributing to routing table bloat (which potentially
   serious consequences). Note that fragementation is a result of
   transfering pieces of larger address blocsk. This will happen if
   trading happens on the black market. But a transfer policy may
   increase the amount of transfers that take place, exacerbating the
   problem.

 - Not "fair" to end sites to have to pay for address space; not fair
   for holders of underutilized blocks to recieve a "windfall" when
   they sell addresses

   related issue: roughly half of the assigned space is "legacy" and
   the vast majority of underutilized space is in the legacy area.
   These legacy holders reside disproportionately in developed
   economies, meaning that the "windfall" would benefit developed
   economies at the expense of those less able to pay (i.e, the less
   developed economies, which came to the Internet after the
   newcomers).

 - anything that extends IPv4 lifetime delays IPv6 uptake. We should
   do everything possible to encourage fast deployment of IPv6, since
   that is the best overall strategy.

 - the rate of address consumption is so large (dozen /8s per year)
   that a market of address available via transfers is unlikely to
   come anywhere near matching demand. so why bother.

 - Changing the transfer policy won't really change much, so there is
   no need to do anything. We will only cause ourselves grief by doing
   this.


From michael.dillon at bt.com  Thu Sep  4 15:09:35 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 4 Sep 2008 20:09:35 +0100
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC07E340CC@E03MVZ2-UKDY.domain1.systemhost.net>

> "The ARIN Board of Trustees on behalf of ARIN and the 
> community at large requests that as a service to that 
> community, holders of address space which is available to 
> return, or which they are willing to make available for 
> return, should do so at their earliest convenience.  On 
> behalf of the community that will need these addresses as the 
> industry transitions to IPv6, ARIN thanks you."

In general, I agree with this approach, although I feel that 
the last sentence needs a bit more explanation like "to cover
the shortfall" or else the statement needs to be accompanied
by some text, and maybe a diagram, to explain this to executives
who have never heard of IP addresses or of ARIN.

On the one hand a statement needs to be direct enough that it
spurs the recipient to send it to senior management for a 
decision, and on the other hand, the statement needs to 
be both informative and convincing when the senior management
reads it.

--Michael Dillon


From bmanning at vacation.karoshi.com  Thu Sep  4 15:10:19 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 4 Sep 2008 19:10:19 +0000
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C01D9B.10400@cjbsys.bdb.com>
References: <48C01D9B.10400@cjbsys.bdb.com>
Message-ID: <20080904191019.GA3443@vacation.karoshi.com.>

On Thu, Sep 04, 2008 at 01:40:43PM -0400, Cliff Bedore wrote:
> The problem:  There is no compatibility bit in IPv6 that says I'm just
> like IPv4 but I have 96 more address bits.  Lacking this, I think the
> only way to get IPv6 going is to develop a transparent IPv6 to IPv4
> translator and convert the entire "Internet backbone" to IPv6.  If I'm
> reading stuff correctly, something like NAT64 is a good starting point
> but there is more required.  The backbone for the Internet will have to
> be IPv6, DNS will have to be IPv6 and IPv4 will be treated as IPv6 on
> the Internet and translated through the "converter box (CB)".  This
> means that the CB will have to do both translation and DNS lookups for
> the v4 hosts.  Since there are 64 bits per subnet in IPv6, there will
> never be a subnet that can't split off IPv4 addresses through the CB for
> translation.
> 

	translation is going to be key.

	NAT64 is one choice, another is "dualstack-lite" and the one
	I'm using is  IVI.


	http://tools.ietf.org/id/draft-xli-behave-ivi-00.txt 
	http://www.ietf.org/proceedings/08jul/slides/opsarea-4.pdf 


--bill


From michael.dillon at bt.com  Thu Sep  4 15:15:30 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 4 Sep 2008 20:15:30 +0100
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <48C012DB.2040707@sprunk.org>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC07E340D1@E03MVZ2-UKDY.domain1.systemhost.net>

> how are you going to get past the 
> argument that those orgs, rather than return space for free 
> today, may be able to wait a few years and sell that space to 
> the highest bidder? 

This issue should be addressed head on. Firstly, IP address selling
is not part of the organizations core business, secondly the revenue
from selling addresses will be insignificant compared to the core
revenue sources of the organization and thirdly, there will be a 
cost to getting it sold which could wipe out all or most of the
expected profit. 

This is like when Kimberly-Clarke sold off all their paper mills
to get rid of distractions to their core business which was
selling paper products to consumers, not manufacturing. Or when
Walgreens, the inventors of the malted milkshake got out of the
restaurant business even though they had 500 profitable restaurants
nationwide. They wanted to be a drugstore chain, not a restaurant
chain.

--Michael Dillon


From cgrundemann at gmail.com  Thu Sep  4 15:21:02 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 4 Sep 2008 13:21:02 -0600
Subject: [arin-ppml] the Transfer Policy Argument Space
In-Reply-To: <443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
References: <48BE48BB.29942.2FA0005@farmer.umn.edu>
	<443de7ad0809031246s5e55872eo343fdde09046abe9@mail.gmail.com>
Message-ID: <443de7ad0809041221r56d5312dx96530f3ba231435@mail.gmail.com>

I have posted an updated version of the Decision Tree:
http://odin.chrisgrundemann.com/Do_I_Support_A_Liberalized_Transfer_Policy.jpg


On Thu, Sep 4, 2008 at 10:36 AM, Howard, W. Lee
<Lee.Howard at stanleyassociates.com> wrote:
[...]
> I do think your questions on 4b presume that IPv6 is desirable.
> I don't think it's desirable per se, merely better than the
> alternatives.

Yes, I let my prejudice slip in there :).  I have added some notes to
the newest version for the 'IPv4 only' path on the top right and the
'not IPv4 or IPv6' path on the top left.  They instruct the user to
skip the v6 questions or replace v6 with whatever other solution is
decided upon, respectively.

> I think the question "Will any holders of large IP blocks actually
> 'sell' a significant amount" would be better phrased as, "Would
> address holders 'sell' enough IPv4 space to meet demand?"
> If yes, go to the speculators question.
> If no:
> "Can demand be reduced enough to fit within suppy?"
>  If yes, we have to ask how, but we can go back to the green path.
>  If no, we may need to ask whether it'll stall disaster long
>  enough to matter, but we end up at the Big Red One.

Great suggestion, thank you.  I have modified the drawing to reflect it.



On Thu, Sep 4, 2008 at 11:39 AM, David Farmer <farmer at umn.edu> wrote:
[...]
> What did you use to make it?  Could you make the native form available?  If
> people think it would help, I'm happy to make some large format printouts
> and bring them to LA to put up as a posters on a couple walls, to facilitate
> discussion.  (It is really nice to have the CAD guys down the hall with their
> large format printer :-))

I used Visio 2003 - I know that Visio has many compatibility issues
but I am more than willing to make it available.  Is there a better
format that more folks could work with (.vdx, .svg, .dwg, etc)?  Or
should I just post the .vsd?  I think it would be great to have some
printouts of the final version available at the meeting (but I think
my kids are great too ;)).

> Rather that attaching the yes output of "Are liberlized Address transfers
> helpful to maintain the/a IPv4 Internet" to "will speculators ....." I would attach
> it to "will address holders return unused space without additional incentives"

Agreed, I made this change in the updated the diagram.

> I think some of Lee Howard's comments are interesting too, maybe try
> incorporating some of them too.

Agreed and done.

> Thanks and happy to have you run with the idea, let me know if you need to
> hand it back.  I don't want it to drop, but I don't have the me the one that
> runs with it.

Thank you!


~Chris



 --
 Chris Grundemann
 www.linkedin.com/in/cgrundemann


From jr at jrw.org  Thu Sep  4 15:27:16 2008
From: jr at jrw.org (J. R. Westmoreland)
Date: Thu, 4 Sep 2008 13:27:16 -0600
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>
References: <48BF0C07.9020602@sprunk.org>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
	<001601c90e9c$c308ca30$491a5e90$@org>
	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>
Message-ID: <000301c90ec4$40d416f0$c27c44d0$@org>

>
> Approaching 67000 discrete legacy objects, so that's your
> denominator.  You can do the math: 67k * $10 is $670,000.
> That's 5% of ARIN's 2008 budget.
>
> Would this be fairer?
>
> [J. R. W. >] Yes. I'd go along with that. In fact, not wanting to be  
> a real
> problem, I'd be willing to pay $20 per year. That would be almost  
> 1.3m. I
> only hold a class C /24 and have always asked myself about the class A
> people getting such a good deal but if legacy space was $20 or $25,  
> being a
> small consultant, I'd be much happier and be willing to jump on board.
>
But, to meet ARIN's current budget, everyone would need to go to
$200 per object... ($10 got you to 5% of the budget, so, you need
20 times that to meet the budget)

[J. R. W. >] I thought we were talking about legacy. Did I miss something?
Are the numbers above for all address space?

> We could debate whether that's a fair share, but it would be
> a matter of opinion of "fair."
>
The problem with this theory is that it ends up treating
assignments and allocations the same.  Allocations have
a disproportionately higher impact on ARIN registration
services than do assignments.  Assignments are made,
then enter a maintenance mode.  Allocations, OTOH,
involve SWIPs, RWHOIS, and churn of the way they
are carved, reclaimed, re-carved, etc. into sub-allocations.

> It would mean that those with a single allocation (say, a
> Class A) pay a single low fee, while those with multiple
> CIDR allocations pay several times as much.
>
It would mean that large mega-ISPs would pay a few
object fees while consuming a very large fraction of the
IP address space, often paying less than mid-size
multi-homed enterprises who got many different
blocks over time.  This could lead to substantially
increased use of the recently adopted aggregation
policy, but, that would lead to an increase in fees
if it did.

Owen



From michael.dillon at bt.com  Thu Sep  4 15:54:28 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 4 Sep 2008 20:54:28 +0100
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C01D9B.10400@cjbsys.bdb.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC07E340E9@E03MVZ2-UKDY.domain1.systemhost.net>

> The U. S. government mandate of using
> IPv6 is very reminiscent of the great GOSIP debacle of the 
> 1990s and if something doesn't change in how we do this, I 
> frankly see IPv6 dying out and a smaller group of good 
> engineers will come up with something that works instead of a 
> protocol designed by an overly large committee that wants 
> everything but the kitchen sink.

Nothing could be further from the truth. GOSIP was an attempt
by government to design a network protocol suite and then impose
it before it had actually been developed. This spurred deployment
of IP because people wanted to get the end benefits promised
by GOSIP deployment, but GOSIP was not running code and could
not be deployed for love or money.

In addition, IPv6 has been around for 10 years or so. During that
time it has been implemented several times and deployed on thousands
of networks. Lots of bugs have been fixed, and the design has been 
adjusted several times. IPv6 is now a mature protocol. There is nothing
on the drawing boards that could conceivably be ready for full Internet
production use within the timeframe of IPv4 exhaustion. In the end,
somebody may create something better, but we will have at minimum, 
20 years of an IPv6 Internet before that is possible.

> Look at the successful conversions of the past.  The latest 
> Pentium will run MS DOS. 

And Macintosh System 7 applications, Cisco IOS images for 2600s
and even IBM System\360 OS\MVS

> I can watch HDTV on my old TV, I 
> believe it was IBM 360s which ran "an older machine"(somebody 
> here will remember) in emulation mode.

It was common for all the newer commercial IBM computers of the
50's and 60'5 to emulate the model they would replace. In the 
1970s I remember hearing of a payroll system written for the 
1401 that ran on 7090's in 1401 emulation mode, and then on the
System\360 in 7090 emulation mode.

You do have a point that the IPv6 Internet transition has
to be seamless to the user meaning that IPv4 users can 
access IPv6 sites and IPv6 users can access IPv4 sites. 
The ARIN wiki <http://www.getipv6.info> has info about some
of the technical odds and ends that Internet operators will
have to implement to make it work this way.

--Michael Dillon


From owen at delong.com  Thu Sep  4 16:17:07 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Sep 2008 13:17:07 -0700
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <000301c90ec4$40d416f0$c27c44d0$@org>
References: <48BF0C07.9020602@sprunk.org>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
	<001601c90e9c$c308ca30$491a5e90$@org>
	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>
	<000301c90ec4$40d416f0$c27c44d0$@org>
Message-ID: <6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>


On Sep 4, 2008, at 12:27 PM, J. R. Westmoreland wrote:

>>
>> Approaching 67000 discrete legacy objects, so that's your
>> denominator.  You can do the math: 67k * $10 is $670,000.
>> That's 5% of ARIN's 2008 budget.
>>
>> Would this be fairer?
>>
>> [J. R. W. >] Yes. I'd go along with that. In fact, not wanting to be
>> a real
>> problem, I'd be willing to pay $20 per year. That would be almost
>> 1.3m. I
>> only hold a class C /24 and have always asked myself about the  
>> class A
>> people getting such a good deal but if legacy space was $20 or $25,
>> being a
>> small consultant, I'd be much happier and be willing to jump on  
>> board.
>>
> But, to meet ARIN's current budget, everyone would need to go to
> $200 per object... ($10 got you to 5% of the budget, so, you need
> 20 times that to meet the budget)
>
> [J. R. W. >] I thought we were talking about legacy. Did I miss  
> something?
> Are the numbers above for all address space?

OK... Perhaps my bad.  For legacy, I'm not really concerned about
the amount. Any money collected is an improvement over the current
situation.  In my opinion, in the legacy case, the purpose of the fee
is to ensure that someone stands up once a year and says to
ARIN "Yes, I'm still using that resource and it still has meaning
to me. My contact information is still correct, thank you."

I think that $10 would be too low to accomplish anything but
the last part. (If the contact information lapsed, the $10 would
stop arriving). However, for amounts less than $50, in my
experience, many individuals and organizations will just
keep paying it once a year without even really looking at
it in detail or thinking about whether they still need to.

However, I agree that $100 is more than is necessary solely
for that purpose.

The problem comes in trying to justify why you have a different
pricing model for Legacy than for everyone else who is (and has
been) paying the standard fees for years.

If we're going to drop the annual maintenance fee to some lower
level, I'd like to see that happen across the board rather than
just for legacy holders.  Thus, we'd need to calculate it
in those terms.

Owen



From jr at jrw.org  Thu Sep  4 16:29:31 2008
From: jr at jrw.org (J. R. Westmoreland)
Date: Thu, 4 Sep 2008 14:29:31 -0600
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
References: <48BF0C07.9020602@sprunk.org>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
	<001601c90e9c$c308ca30$491a5e90$@org>
	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>
	<000301c90ec4$40d416f0$c27c44d0$@org>
	<6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
Message-ID: <000401c90ecc$f2ee23a0$d8ca6ae0$@org>

>>
>> Approaching 67000 discrete legacy objects, so that's your
>> denominator.  You can do the math: 67k * $10 is $670,000.
>> That's 5% of ARIN's 2008 budget.
>>
>> Would this be fairer?
>>
>> [J. R. W. >] Yes. I'd go along with that. In fact, not wanting to be
>> a real
>> problem, I'd be willing to pay $20 per year. That would be almost
>> 1.3m. I
>> only hold a class C /24 and have always asked myself about the  
>> class A
>> people getting such a good deal but if legacy space was $20 or $25,
>> being a
>> small consultant, I'd be much happier and be willing to jump on  
>> board.
>>
> But, to meet ARIN's current budget, everyone would need to go to
> $200 per object... ($10 got you to 5% of the budget, so, you need
> 20 times that to meet the budget)
>
> [J. R. W. >] I thought we were talking about legacy. Did I miss  
> something?
> Are the numbers above for all address space?

OK... Perhaps my bad.  For legacy, I'm not really concerned about
the amount. Any money collected is an improvement over the current
situation.  In my opinion, in the legacy case, the purpose of the fee
is to ensure that someone stands up once a year and says to
ARIN "Yes, I'm still using that resource and it still has meaning
to me. My contact information is still correct, thank you."

[J. R. W. >] I think I understand that one. For my part I'd even jump on
board if I could do it for half of the current fee.

I think that $10 would be too low to accomplish anything but
the last part. (If the contact information lapsed, the $10 would
stop arriving). However, for amounts less than $50, in my
experience, many individuals and organizations will just
keep paying it once a year without even really looking at
it in detail or thinking about whether they still need to.

[J. R. W. >] I know I personally don't. If I see a recorring fee on my
credit card I ALWAYS check it. If for nothing else than to make sure that
I'm not being scammed. <grin>

However, I agree that $100 is more than is necessary solely
for that purpose.

[J. R. W. >] So, if they said something like: If you have had your address
space since before 1995, or some reasonable date like that, then your fee
will be $50, or whatever, and you sign the RSA. If you then let your status
lapse then you wil be able to reinstate your RSA but at the current rate.

The problem comes in trying to justify why you have a different
pricing model for Legacy than for everyone else who is (and has
been) paying the standard fees for years.

[J. R. W. >] I don't see why any justification is needed. It happens in many
businesses all the time. Original customers will get a special rate if they
fit into a certain class.

If we're going to drop the annual maintenance fee to some lower
level, I'd like to see that happen across the board rather than
just for legacy holders.  Thus, we'd need to calculate it
in those terms.

Owen



From owen at delong.com  Thu Sep  4 17:14:11 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Sep 2008 14:14:11 -0700
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <000401c90ecc$f2ee23a0$d8ca6ae0$@org>
References: <48BF0C07.9020602@sprunk.org>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
	<001601c90e9c$c308ca30$491a5e90$@org>
	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>
	<000301c90ec4$40d416f0$c27c44d0$@org>
	<6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
	<000401c90ecc$f2ee23a0$d8ca6ae0$@org>
Message-ID: <8A88E17E-7180-4A1B-81BC-CA2D5F381C75@delong.com>

>
> The problem comes in trying to justify why you have a different
> pricing model for Legacy than for everyone else who is (and has
> been) paying the standard fees for years.
>
> [J. R. W. >] I don't see why any justification is needed. It happens  
> in many
> businesses all the time. Original customers will get a special rate  
> if they
> fit into a certain class.

As a clarification, ARIN is not a business... It's a non-profit Member- 
centric
organization.  Fee policies at least need to be justified to the  
members,
if not the community at large.

Owen



From arin-ppml at westbrook.com  Thu Sep  4 17:40:02 2008
From: arin-ppml at westbrook.com (Eric Westbrook)
Date: Thu, 4 Sep 2008 15:40:02 -0600
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
References: <48BF0C07.9020602@sprunk.org>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>
	<001601c90e9c$c308ca30$491a5e90$@org>
	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>
	<000301c90ec4$40d416f0$c27c44d0$@org>
	<6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
Message-ID: <6905ba860809041440m3f9ea427h3a6245f4c8b6348@mail.gmail.com>

On Thu, Sep 4, 2008 at 2:17 PM, Owen DeLong <owen at delong.com> wrote:

> In my opinion, in the legacy case, the purpose of the fee
> is to ensure that someone stands up once a year and says to
> ARIN "Yes, I'm still using that resource and it still has meaning
> to me. My contact information is still correct, thank you."


If the LRSA was written to that effect and nothing else (except perhaps
acknowledgement of the whois/rdns services et al as consideration), I'd
already have signed up.  I think I could very quickly get over the $100/yr
fee, even if it does feel a little high for the load a single-/24 guy like
me represents.

As it is, though, the LRSA contains provisions for potential seizure of the
resource's ultimate destiny.  That's what makes it unattractive.  I'm
speaking just for myself, of course, but I have been seeing others in my
situation posting to this list in apparent agreement.

So for me, it's not so much the monetary costs.  I'd love to pay.  Really, I
would.  I'd just rather not hand over the house's deed in order to pay the
electric bill.

$0.02,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080904/796fcc7b/attachment.htm>

From jmorrison at bogomips.com  Thu Sep  4 17:53:06 2008
From: jmorrison at bogomips.com (John Paul Morrison)
Date: Thu, 04 Sep 2008 14:53:06 -0700
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
References: <48BF0C07.9020602@sprunk.org>	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>	<001601c90e9c$c308ca30$491a5e90$@org>	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>	<000301c90ec4$40d416f0$c27c44d0$@org>
	<6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
Message-ID: <48C058C2.7050606@bogomips.com>

On 9/4/2008 1:17 PM, Owen DeLong wrote:
> The problem comes in trying to justify why you have a different
> pricing model for Legacy than for everyone else who is (and has
> been) paying the standard fees for years.
>   
This isn't that hard.

First of all, there was no fee specified at the time they were given. 
And IP addresses were given out, no strings attached, with no 
expectation that they would come back, so why would there be any 
expectation of a recurring charge? If an item was given away for free 
with no terms of service, how can one argue that a "service" whether 
it's whois/DNS, or PPML, be tacked on later and then charged for? Under 
that light, $10/year seems fair, even charitable of Legacy holders to 
pay, given there's likely been little change since the original 
assignments.

Second, there's no real justification for any costs to Legacy holders. 
The addresses were given out while the administration of the Internet 
was publicly funded, by the NSF, CA*Net (in Canada) etc., so any real 
work has already been paid out of tax dollars. The allocation is simply 
an entry in a database, or back of a napkin for that matter. It's great 
that it's recorded in Whois, but it's not a requirement that it be that way.

For the sake of argument, someone could document all the Legacy 
allocations and publish an RFC and say 'that's the historical record' 
and do away with any whois, other requirements, or ARIN's involvement 
with all of Legacy space for that matter, and that would be the 
historical record for all time, unless anyone cared enough to make minor 
revisions as a courtesy. What's to distinguish one Legacy assignment 
from another? 127.0.0.0/8 is assigned in an RFC, so are the Class E 
addresses and many others. I'm pretty sure the RFC process pre-dates 
whois, especially since 811 prior RFCs were published before they got 
around to publishing the one for Whois, but I could be wrong. (And if 
this Legacy holders RFC were published on April 1, I think that would 
definitely absolve the Legacy holders of any obligation to chip in for 
their 1/5000th share of the costs of hosting and maintaining the RFCs!)

Especially in light of IPv4 address exhaustion, would anyone like to 
reclaim 127.0.0.0/8 or the Class E space, or parts of Legacy space? Yes, 
of course if we had the chance to do it all over, we would do things 
differently, but we can't. If people don't like that, that's too bad. In 
practical terms, IP address assignments are permanent and irrevocable.

> If we're going to drop the annual maintenance fee to some lower
> level, I'd like to see that happen across the board rather than
> just for legacy holders.  Thus, we'd need to calculate it
> in those terms.
>   
It's sounding like it's just not worth the effort to collect a token 
amount.
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   



From cort at kanren.net  Thu Sep  4 18:36:16 2008
From: cort at kanren.net (Cort Buffington)
Date: Thu, 4 Sep 2008 17:36:16 -0500
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C01D9B.10400@cjbsys.bdb.com>
References: <48C01D9B.10400@cjbsys.bdb.com>
Message-ID: <5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>

While I agree that CEOs are generally disinterested, I have  
irrefutable scientific evidence to the contrary:

I am a CEO. I run a non-profit corporation that operates a state-wide  
R&E network consortium. Our backbone network has been in production  
with IPv6 since February 2004. Today, all CPE routers are IPv6's with  
only a couple of very small end-site exceptions. Several members have  
asked us to turn it on to their LANs. This e-mail I'm typing will  
travel to my mail server on an IPv6 socket. The browser that's open to  
google on my desktop right now is open over an IPv6 socket.

Many of you are probably asking whether I take my meds or not. I lived  
through being a lowly technician on a network back in the days when  
management refused to accept that we would really need to stop using  
IPX and AppleTalk in favor of this IP stuff. After all, IPX was  
everywhere. The Internet would most assuredly get IPX support before  
we had to change over to IP to use it -- and if not, we could just run  
through translators. Sure I was working in a shop that was probably  
not the norm and had more strange notions than most, but nonetheless,  
to me, much of this IPv6 discussion sounds very familiar.

I've also worked in commercial two-way radio. I remember when  
frequencies started to become scarce and the FCC started auctioning  
off spectrum to the highest bidder. I talked to the guy (like 10  
minutes ago) I worked for back then. I gave him the choice of running  
out of spectrum and ending up in the auction environment we have  
today, or taking 5 years to replace the majority of his infrastructure  
so that he'd never be unable to get frequencies. Clearly, he'd have  
opted to replace infrastructure. I could make mention of any number of  
limited natural resources here, like oil, but I'm sure you all get my  
point.

So many times, when a resource grows scarce, there is no choice. This  
time we have a choice. The majority seem to think that we'll just keep  
extending IPv4 forever, somehow. Or that some replacement that won't  
require work and a learning curve will come along, somehow. I grant  
you that, the clear majority, may very well be right that IPv6 won't  
be the answer. One day I may have to answer to my board of directors  
about the resources I wasted on IPv6. I really do believe that if IPv6  
is not the answer, it will be because we, as a society, refused to let  
it be the answer. I will remain in the apparent minority that believes  
it is the answer.

If you've actually read this far, thank you for giving me a few  
minutes of your time. I've lurked on this list for some time and said  
very little. I appreciate the opinions and ideas -- even when I don't  
agree with mine.

Regards,
Cort

On Sep 4, 2008, at 12:40 PM, Cliff Bedore wrote:

> There is no CEO in the world sitting around saying "Boy I can't wait  
> to
> get us on IPv6"....



--
Cort Buffington
Executive Director
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206







From cliffb at cjbsys.bdb.com  Thu Sep  4 19:35:12 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Thu, 04 Sep 2008 19:35:12 -0400
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <6905ba860809041440m3f9ea427h3a6245f4c8b6348@mail.gmail.com>
References: <48BF0C07.9020602@sprunk.org>	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>	<001601c90e9c$c308ca30$491a5e90$@org>	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>	<000301c90ec4$40d416f0$c27c44d0$@org>	<6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
	<6905ba860809041440m3f9ea427h3a6245f4c8b6348@mail.gmail.com>
Message-ID: <48C070B0.6090108@cjbsys.bdb.com>

Eric Westbrook wrote:
> On Thu, Sep 4, 2008 at 2:17 PM, Owen DeLong <owen at delong.com 
> <mailto:owen at delong.com>> wrote:
>
>     In my opinion, in the legacy case, the purpose of the fee
>     is to ensure that someone stands up once a year and says to
>     ARIN "Yes, I'm still using that resource and it still has meaning
>     to me. My contact information is still correct, thank you."
>
>
> If the LRSA was written to that effect and nothing else (except 
> perhaps acknowledgement of the whois/rdns services et al as 
> consideration), I'd already have signed up.  I think I could very 
> quickly get over the $100/yr fee, even if it does feel a little high 
> for the load a single-/24 guy like me represents.
>
> As it is, though, the LRSA contains provisions for potential seizure 
> of the resource's ultimate destiny.  That's what makes it 
> unattractive.  I'm speaking just for myself, of course, but I have 
> been seeing others in my situation posting to this list in apparent 
> agreement.

I sent out an alternate LRSA a few weeks ago to address and thus far 
have heard nothing.  I also don't have a real problem with the $100.00 ( 
OK I do but only because I'm cheap. :-) )  I keep hearing that they just 
want to update our records but the LRSA goes much further than that.

John Paul Morrison is a separate email offers reasons about why we 
should never have to pay and they make some sense but I'm still willing 
to cough up the $100.00 or something like it to keep things up to date 
and happy.

Cliff
>
> So for me, it's not so much the monetary costs.  I'd love to pay.  
> Really, I would.  I'd just rather not hand over the house's deed in 
> order to pay the electric bill.
>
> $0.02,
> Eric
> ------------------------------------------------------------------------
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From BillD at cait.wustl.edu  Thu Sep  4 19:59:28 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 4 Sep 2008 18:59:28 -0500
Subject: [arin-ppml] maintenance fees for legacy space holders
References: <48BF0C07.9020602@sprunk.org>	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>	<001601c90e9c$c308ca30$491a5e90$@org>	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>	<000301c90ec4$40d416f0$c27c44d0$@org>
	<6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
	<48C058C2.7050606@bogomips.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531BF7@ex1.cait.wustl.edu>

The services rendered to legacy holders is real and if you don't think it is worth anything then simply say.
Please stop providing any and all services that are rendered on behalf of legacy addresses that have taken effect since the initial allocation.
Fair?
bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of John Paul Morrison
Sent: Thu 9/4/2008 4:53 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] maintenance fees for legacy space holders
 
On 9/4/2008 1:17 PM, Owen DeLong wrote:
> The problem comes in trying to justify why you have a different
> pricing model for Legacy than for everyone else who is (and has
> been) paying the standard fees for years.
>   
This isn't that hard.

First of all, there was no fee specified at the time they were given. 
And IP addresses were given out, no strings attached, with no 
expectation that they would come back, so why would there be any 
expectation of a recurring charge? If an item was given away for free 
with no terms of service, how can one argue that a "service" whether 
it's whois/DNS, or PPML, be tacked on later and then charged for? Under 
that light, $10/year seems fair, even charitable of Legacy holders to 
pay, given there's likely been little change since the original 
assignments.

Second, there's no real justification for any costs to Legacy holders. 
The addresses were given out while the administration of the Internet 
was publicly funded, by the NSF, CA*Net (in Canada) etc., so any real 
work has already been paid out of tax dollars. The allocation is simply 
an entry in a database, or back of a napkin for that matter. It's great 
that it's recorded in Whois, but it's not a requirement that it be that way.

For the sake of argument, someone could document all the Legacy 
allocations and publish an RFC and say 'that's the historical record' 
and do away with any whois, other requirements, or ARIN's involvement 
with all of Legacy space for that matter, and that would be the 
historical record for all time, unless anyone cared enough to make minor 
revisions as a courtesy. What's to distinguish one Legacy assignment 
from another? 127.0.0.0/8 is assigned in an RFC, so are the Class E 
addresses and many others. I'm pretty sure the RFC process pre-dates 
whois, especially since 811 prior RFCs were published before they got 
around to publishing the one for Whois, but I could be wrong. (And if 
this Legacy holders RFC were published on April 1, I think that would 
definitely absolve the Legacy holders of any obligation to chip in for 
their 1/5000th share of the costs of hosting and maintaining the RFCs!)

Especially in light of IPv4 address exhaustion, would anyone like to 
reclaim 127.0.0.0/8 or the Class E space, or parts of Legacy space? Yes, 
of course if we had the chance to do it all over, we would do things 
differently, but we can't. If people don't like that, that's too bad. In 
practical terms, IP address assignments are permanent and irrevocable.

> If we're going to drop the annual maintenance fee to some lower
> level, I'd like to see that happen across the board rather than
> just for legacy holders.  Thus, we'd need to calculate it
> in those terms.
>   
It's sounding like it's just not worth the effort to collect a token 
amount.
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080904/a9b478cb/attachment.htm>

From jmorrison at bogomips.com  Thu Sep  4 20:39:46 2008
From: jmorrison at bogomips.com (John Paul Morrison)
Date: Thu, 04 Sep 2008 17:39:46 -0700
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087531BF7@ex1.cait.wustl.edu>
References: <48BF0C07.9020602@sprunk.org>	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>	<001601c90e9c$c308ca30$491a5e90$@org>	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>	<000301c90ec4$40d416f0$c27c44d0$@org>
	<6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
	<48C058C2.7050606@bogomips.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087531BF7@ex1.cait.wustl.edu>
Message-ID: <48C07FD2.8080904@bogomips.com>

I never said it was worth nothing. Owen  Delong asked how to justify a 
different pricing model and I simply gave some examples.

Maybe it should be $10/year or maybe $10 every time someone changes 
their whois or DNS record, or maybe it's a sunk cost - it's net $0/year 
but that doesn't make it worthless. I don't know if ARIN has an 
endownment, but maybe they have capital assets, software etc. that were 
given to them.  The biggest "Legacy" ARIN inherited is not the Legacy IP 
assignments but rather it is the recurring income they receive from 
fees, derived from administering a database of numbers (the Banks must 
be envious!) -  for a protocol developed and funded largely by 
governments, military, academic and corporate research groups. I'm not 
going to moan here about all the hard work of the legacy holders and how 
they deserve a free ride, but I'm not going to cry about that fact either.

As Cliff Bedore and Eric Westbrook point out though, it isn't just about 
the money.


On 9/4/2008 4:59 PM, Bill Darte wrote:
>
> The services rendered to legacy holders is real and if you don't think 
> it is worth anything then simply say.
> Please stop providing any and all services that are rendered on behalf 
> of legacy addresses that have taken effect since the initial allocation.
> Fair?
> bd
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of John Paul Morrison
> Sent: Thu 9/4/2008 4:53 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] maintenance fees for legacy space holders
>
> On 9/4/2008 1:17 PM, Owen DeLong wrote:
> > The problem comes in trying to justify why you have a different
> > pricing model for Legacy than for everyone else who is (and has
> > been) paying the standard fees for years.
> >  
> This isn't that hard.
>
> First of all, there was no fee specified at the time they were given.
> And IP addresses were given out, no strings attached, with no
> expectation that they would come back, so why would there be any
> expectation of a recurring charge? If an item was given away for free
> with no terms of service, how can one argue that a "service" whether
> it's whois/DNS, or PPML, be tacked on later and then charged for? Under
> that light, $10/year seems fair, even charitable of Legacy holders to
> pay, given there's likely been little change since the original
> assignments.
>
> Second, there's no real justification for any costs to Legacy holders.
> The addresses were given out while the administration of the Internet
> was publicly funded, by the NSF, CA*Net (in Canada) etc., so any real
> work has already been paid out of tax dollars. The allocation is simply
> an entry in a database, or back of a napkin for that matter. It's great
> that it's recorded in Whois, but it's not a requirement that it be 
> that way.
>
> For the sake of argument, someone could document all the Legacy
> allocations and publish an RFC and say 'that's the historical record'
> and do away with any whois, other requirements, or ARIN's involvement
> with all of Legacy space for that matter, and that would be the
> historical record for all time, unless anyone cared enough to make minor
> revisions as a courtesy. What's to distinguish one Legacy assignment
> from another? 127.0.0.0/8 is assigned in an RFC, so are the Class E
> addresses and many others. I'm pretty sure the RFC process pre-dates
> whois, especially since 811 prior RFCs were published before they got
> around to publishing the one for Whois, but I could be wrong. (And if
> this Legacy holders RFC were published on April 1, I think that would
> definitely absolve the Legacy holders of any obligation to chip in for
> their 1/5000th share of the costs of hosting and maintaining the RFCs!)
>
> Especially in light of IPv4 address exhaustion, would anyone like to
> reclaim 127.0.0.0/8 or the Class E space, or parts of Legacy space? Yes,
> of course if we had the chance to do it all over, we would do things
> differently, but we can't. If people don't like that, that's too bad. In
> practical terms, IP address assignments are permanent and irrevocable.
>
> > If we're going to drop the annual maintenance fee to some lower
> > level, I'd like to see that happen across the board rather than
> > just for legacy holders.  Thus, we'd need to calculate it
> > in those terms.
> >  
> It's sounding like it's just not worth the effort to collect a token
> amount.
> > Owen
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >  
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080904/727d0be1/attachment.htm>

From jr at jrw.org  Thu Sep  4 21:11:44 2008
From: jr at jrw.org (J. R. Westmoreland)
Date: Thu, 4 Sep 2008 19:11:44 -0600
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <48C07FD2.8080904@bogomips.com>
References: <48BF0C07.9020602@sprunk.org>	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>	<001601c90e9c$c308ca30$491a5e90$@org>	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>	<000301c90ec4$40d416f0$c27c44d0$@org>	<6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>	<48C058C2.7050606@bogomips.com>	<EACF8B735E9CBA4B8BAF9E4165D03087531BF7@ex1.cait.wustl.edu>
	<48C07FD2.8080904@bogomips.com>
Message-ID: <002401c90ef4$6029efe0$207dcfa0$@org>

John,

 

What you say makes sense. When I got my addresses no one ever said that
fifteen years later we are now going to charge you $100.

I have no problem paying a reasonable fee so ARIN can continue to keep the
intrastructure up-to-date.

I understand that I will have to pay to get a ipv6 block, at least that is
how I understand things.

But, I'm not ready to do that yet since I don't use ipv6.

 

J. R.

 

--------------------

J. R. Westmoreland

E-mail: jr at jrw.org

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of John Paul Morrison
Sent: Thursday, September 04, 2008 6:40 PM
To: Bill Darte
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] maintenance fees for legacy space holders

 

I never said it was worth nothing. Owen  Delong asked how to justify a
different pricing model and I simply gave some examples.

Maybe it should be $10/year or maybe $10 every time someone changes their
whois or DNS record, or maybe it's a sunk cost - it's net $0/year but that
doesn't make it worthless. I don't know if ARIN has an endownment, but maybe
they have capital assets, software etc. that were given to them.  The
biggest "Legacy" ARIN inherited is not the Legacy IP assignments but rather
it is the recurring income they receive from fees, derived from
administering a database of numbers (the Banks must be envious!) -  for a
protocol developed and funded largely by governments, military, academic and
corporate research groups. I'm not going to moan here about all the hard
work of the legacy holders and how they deserve a free ride, but I'm not
going to cry about that fact either.

As Cliff Bedore and Eric Westbrook point out though, it isn't just about the
money.


On 9/4/2008 4:59 PM, Bill Darte wrote: 

The services rendered to legacy holders is real and if you don't think it is
worth anything then simply say.
Please stop providing any and all services that are rendered on behalf of
legacy addresses that have taken effect since the initial allocation.
Fair?
bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of John Paul Morrison
Sent: Thu 9/4/2008 4:53 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] maintenance fees for legacy space holders

On 9/4/2008 1:17 PM, Owen DeLong wrote:
> The problem comes in trying to justify why you have a different
> pricing model for Legacy than for everyone else who is (and has
> been) paying the standard fees for years.
>  
This isn't that hard.

First of all, there was no fee specified at the time they were given.
And IP addresses were given out, no strings attached, with no
expectation that they would come back, so why would there be any
expectation of a recurring charge? If an item was given away for free
with no terms of service, how can one argue that a "service" whether
it's whois/DNS, or PPML, be tacked on later and then charged for? Under
that light, $10/year seems fair, even charitable of Legacy holders to
pay, given there's likely been little change since the original
assignments.

Second, there's no real justification for any costs to Legacy holders.
The addresses were given out while the administration of the Internet
was publicly funded, by the NSF, CA*Net (in Canada) etc., so any real
work has already been paid out of tax dollars. The allocation is simply
an entry in a database, or back of a napkin for that matter. It's great
that it's recorded in Whois, but it's not a requirement that it be that way.

For the sake of argument, someone could document all the Legacy
allocations and publish an RFC and say 'that's the historical record'
and do away with any whois, other requirements, or ARIN's involvement
with all of Legacy space for that matter, and that would be the
historical record for all time, unless anyone cared enough to make minor
revisions as a courtesy. What's to distinguish one Legacy assignment
from another? 127.0.0.0/8 is assigned in an RFC, so are the Class E
addresses and many others. I'm pretty sure the RFC process pre-dates
whois, especially since 811 prior RFCs were published before they got
around to publishing the one for Whois, but I could be wrong. (And if
this Legacy holders RFC were published on April 1, I think that would
definitely absolve the Legacy holders of any obligation to chip in for
their 1/5000th share of the costs of hosting and maintaining the RFCs!)

Especially in light of IPv4 address exhaustion, would anyone like to
reclaim 127.0.0.0/8 or the Class E space, or parts of Legacy space? Yes,
of course if we had the chance to do it all over, we would do things
differently, but we can't. If people don't like that, that's too bad. In
practical terms, IP address assignments are permanent and irrevocable.

> If we're going to drop the annual maintenance fee to some lower
> level, I'd like to see that happen across the board rather than
> just for legacy holders.  Thus, we'd need to calculate it
> in those terms.
>  
It's sounding like it's just not worth the effort to collect a token
amount.
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>  

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080904/483649a6/attachment.htm>

From cliffb at cjbsys.bdb.com  Thu Sep  4 22:18:44 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Thu, 04 Sep 2008 22:18:44 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
References: <48C01D9B.10400@cjbsys.bdb.com>
	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
Message-ID: <48C09704.7050108@cjbsys.bdb.com>

Cort Buffington wrote:
> While I agree that CEOs are generally disinterested, I have  
> irrefutable scientific evidence to the contrary:
>   
> I am a CEO. I run a non-profit corporation that operates a state-wide  
> R&E network consortium. Our backbone network has been in production  
> with IPv6 since February 2004. Today, all CPE routers are IPv6's with  
> only a couple of very small end-site exceptions. Several members have  
> asked us to turn it on to their LANs. This e-mail I'm typing will  
> travel to my mail server on an IPv6 socket. The browser that's open to  
> google on my desktop right now is open over an IPv6 socket.
>   

OK, there's one CEO who can't wait. :-)

Not being funny, Can that IPv6 socket reach www.bdb.com?  If so, how? 

Also not trying to pick on you but non-profits tend to have different 
goals than for-profit entities.
> Many of you are probably asking whether I take my meds or not. I lived  
> through being a lowly technician on a network back in the days when  
> management refused to accept that we would really need to stop using  
> IPX and AppleTalk in favor of this IP stuff. After all, IPX was  
> everywhere. The Internet would most assuredly get IPX support before  
> we had to change over to IP to use it -- and if not, we could just run  
> through translators. Sure I was working in a shop that was probably  
> not the norm and had more strange notions than most, but nonetheless,  
> to me, much of this IPv6 discussion sounds very familiar.
>
> I've also worked in commercial two-way radio. I remember when  
> frequencies started to become scarce and the FCC started auctioning  
> off spectrum to the highest bidder. I talked to the guy (like 10  
> minutes ago) I worked for back then. I gave him the choice of running  
> out of spectrum and ending up in the auction environment we have  
> today, or taking 5 years to replace the majority of his infrastructure  
> so that he'd never be unable to get frequencies. Clearly, he'd have  
> opted to replace infrastructure. I could make mention of any number of  
> limited natural resources here, like oil, but I'm sure you all get my  
> point.
>
> So many times, when a resource grows scarce, there is no choice. This  
> time we have a choice. The majority seem to think that we'll just keep  
> extending IPv4 forever, somehow. Or that some replacement that won't  
> require work and a learning curve will come along, somehow. I grant  
> you that, the clear majority, may very well be right that IPv6 won't  
> be the answer. One day I may have to answer to my board of directors  
> about the resources I wasted on IPv6. I really do believe that if IPv6  
> is not the answer, it will be because we, as a society, refused to let  
> it be the answer. I will remain in the apparent minority that believes  
> it is the answer.
>
> If you've actually read this far, thank you for giving me a few  
> minutes of your time. I've lurked on this list for some time and said  
> very little. I appreciate the opinions and ideas -- even when I don't  
> agree with mine.
>   

I read it and am impressed that you have gone as far as you have.  I 
think you will have to admit you are not a typical CEO in a typical 
for-profit company and are probably in the very small minority of 
entities who have gone gung ho for IPv6.  As you point out, lots of 
people bought Beta video players, HD DVD.  Hell I was a big proponent of 
CPM86/Concurrent CPM/86.  It was a much better system than MSDOS but 
that didn't make it a success.  And don't get me wrong.  I'm not 
particularly anti-IPv6 but it's just NOT happening in most of the 
world.  It doesn't seem like we're going to get a disruptive application 
for IPv6 so we need another hook to get people to buy in.  The only one 
I see is to get IPv6 and IPv4 talking transparently so we don't need 
dual stack and people can keep resources that use IPv4 and get to IPv6 
as progress and funds allow.  No one wants to go to IPv6 by itself 
because there is too much IPv4 they couldn't reach.  Dual stack is a 
kludge(IMO).  We need transparent communication between them and without 
that, I don't believe IPv6 will take off in my lifetime.

Cliff

> Regards,
> Cort
>
> On Sep 4, 2008, at 12:40 PM, Cliff Bedore wrote:
>
>   
>> There is no CEO in the world sitting around saying "Boy I can't wait  
>> to
>> get us on IPv6"....
>>     
>
>
>
> --
> Cort Buffington
> Executive Director
> The Kansas Research and Education Network
> cort at kanren.net
> Office: +1-785-856-9800 x301
> Mobile: +1-785-865-7206
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>   



From cort at kanren.net  Thu Sep  4 23:07:23 2008
From: cort at kanren.net (Cort Buffington)
Date: Thu, 4 Sep 2008 22:07:23 -0500
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C09704.7050108@cjbsys.bdb.com>
References: <48C01D9B.10400@cjbsys.bdb.com>
	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
	<48C09704.7050108@cjbsys.bdb.com>
Message-ID: <A639AE84-0069-4A97-8F06-AE9F400212B2@kanren.net>

Cliff,

You are correct, I am not the typical CEO and you are correct again  
about non-profit. In fact, you really just gave me a nice opening to  
jump through :) And yes, I would agree with many of your comments,  
which I would boil down to something (please forgive a little artistic  
license here) like "we need an easy button to push"... Or at least  
that's how I'd like to interpret some of your original comments,  
because I fear that's what It'll take.

But you all have to look out for the small segment of us IPv6 people.  
Our numbers are growing. The national R&E community is taking this  
very seriously. Yes, I am on Internet2's IPv6 Working Group, which  
makes me a zealot I suppose... But, I'm also seeing an unprecedented  
growth in both interest and adoption. And even folks with huge  
enterprises out there, like Brother Farmer, have been working towards  
it for years already.

So, when a majority of major universities in the US have taken the  
plunge, and the state, regional R&Es are all doing it (many already  
are), and Internet2 is doing it (has for years), and these people are  
connected to major content providers who are doing it (ipv6.google.com  
anyone?), what will be said of it then? Cliff is right in that the  
type of system he describes would be absolutely fantastic to have, and  
probably necessary to move a significant population segment. But I  
submit that it will be a combination of factors the bring IPv6 to  
fruition. There will be the R&E community who by and large DO run dual- 
stack. When enough of us do it to represent a target to the commercial  
world, then perhaps some other technologies for "translation" will be  
available that allow more of the profit-bound world to come on board.

Simply put folks, there will not be a single solution. Be it  
translation, dual-stack, something we've not thought of yet, it will  
take more than one method for this to happen for us all. Perhaps we  
should spend less time viewing the world as a big version of our  
networks -- squabbling about why what worked for someone one work for  
us (me included) -- and begin seeing this transition for what it is: A  
long, multi-faceted change that will have many solutions. Let us  
embrace those who have had the resources to adopt early. Dual-stack  
may be a kludge for many, but if folks like me didn't actually run  
dual-stack networks, we would have no real data about just how kludgey  
it is, only speculation.

In response to the thread from Brother Farmer concerning IPv4  
depletion already being upon us, in his world, with his business  
model, and his networking strategy, it is true. But it isn't true for  
everyone. I know several small ISPs, who will be the last to adopt  
IPv6 and would see folks like Dave Farmer and Cort Buffington as  
raging lunatics. Right now, they're struggling to find the services  
that distinguish them from the AT&Ts and Time Warners of the world,  
IPv6 is the LAST thing on their minds. But someday, the work the rest  
of us do will benefit them as we will most assuredly have made just  
about every major mistake possible trying to implement v6 by then.

Again, I believe that IPv6 is coming. And I believe that it will come  
in due course for each of us at different times and different way.  
Let's focus on getting there together, constructively, as a community  
of leaders and problem solvers. To quote Benjamin Franklin, "We must  
all hand together, or assuredly we shall all hang separately."

With that, ladies and gentlemen, I will conclude my soap-box for a few  
more months :) Thank you to Brother Dave Farmer and Brother Cliff  
Bedore for providing me context to twist to my own needs.

Thanking you for your time and this venue,
Cort

On Sep 4, 2008, at 9:18 PM, Cliff Bedore wrote:

> Cort Buffington wrote:
>> While I agree that CEOs are generally disinterested, I have   
>> irrefutable scientific evidence to the contrary:
>>  I am a CEO. I run a non-profit corporation that operates a state- 
>> wide  R&E network consortium. Our backbone network has been in  
>> production  with IPv6 since February 2004. Today, all CPE routers  
>> are IPv6's with  only a couple of very small end-site exceptions.  
>> Several members have  asked us to turn it on to their LANs. This e- 
>> mail I'm typing will  travel to my mail server on an IPv6 socket.  
>> The browser that's open to  google on my desktop right now is open  
>> over an IPv6 socket.
>>
>
> OK, there's one CEO who can't wait. :-)
>
> Not being funny, Can that IPv6 socket reach www.bdb.com?  If so, how?
> Also not trying to pick on you but non-profits tend to have  
> different goals than for-profit entities.
>> Many of you are probably asking whether I take my meds or not. I  
>> lived  through being a lowly technician on a network back in the  
>> days when  management refused to accept that we would really need  
>> to stop using  IPX and AppleTalk in favor of this IP stuff. After  
>> all, IPX was  everywhere. The Internet would most assuredly get IPX  
>> support before  we had to change over to IP to use it -- and if  
>> not, we could just run  through translators. Sure I was working in  
>> a shop that was probably  not the norm and had more strange notions  
>> than most, but nonetheless,  to me, much of this IPv6 discussion  
>> sounds very familiar.
>>
>> I've also worked in commercial two-way radio. I remember when   
>> frequencies started to become scarce and the FCC started  
>> auctioning  off spectrum to the highest bidder. I talked to the guy  
>> (like 10  minutes ago) I worked for back then. I gave him the  
>> choice of running  out of spectrum and ending up in the auction  
>> environment we have  today, or taking 5 years to replace the  
>> majority of his infrastructure  so that he'd never be unable to get  
>> frequencies. Clearly, he'd have  opted to replace infrastructure. I  
>> could make mention of any number of  limited natural resources  
>> here, like oil, but I'm sure you all get my  point.
>>
>> So many times, when a resource grows scarce, there is no choice.  
>> This  time we have a choice. The majority seem to think that we'll  
>> just keep  extending IPv4 forever, somehow. Or that some  
>> replacement that won't  require work and a learning curve will come  
>> along, somehow. I grant  you that, the clear majority, may very  
>> well be right that IPv6 won't  be the answer. One day I may have to  
>> answer to my board of directors  about the resources I wasted on  
>> IPv6. I really do believe that if IPv6  is not the answer, it will  
>> be because we, as a society, refused to let  it be the answer. I  
>> will remain in the apparent minority that believes  it is the answer.
>>
>> If you've actually read this far, thank you for giving me a few   
>> minutes of your time. I've lurked on this list for some time and  
>> said  very little. I appreciate the opinions and ideas -- even when  
>> I don't  agree with mine.
>>
>
> I read it and am impressed that you have gone as far as you have.  I  
> think you will have to admit you are not a typical CEO in a typical  
> for-profit company and are probably in the very small minority of  
> entities who have gone gung ho for IPv6.  As you point out, lots of  
> people bought Beta video players, HD DVD.  Hell I was a big  
> proponent of CPM86/Concurrent CPM/86.  It was a much better system  
> than MSDOS but that didn't make it a success.  And don't get me  
> wrong.  I'm not particularly anti-IPv6 but it's just NOT happening  
> in most of the world.  It doesn't seem like we're going to get a  
> disruptive application for IPv6 so we need another hook to get  
> people to buy in.  The only one I see is to get IPv6 and IPv4  
> talking transparently so we don't need dual stack and people can  
> keep resources that use IPv4 and get to IPv6 as progress and funds  
> allow.  No one wants to go to IPv6 by itself because there is too  
> much IPv4 they couldn't reach.  Dual stack is a kludge(IMO).  We  
> need transparent communication between them and without that, I  
> don't believe IPv6 will take off in my lifetime.
>
> Cliff
>
>> Regards,
>> Cort
>>
>> On Sep 4, 2008, at 12:40 PM, Cliff Bedore wrote:
>>
>>
>>> There is no CEO in the world sitting around saying "Boy I can't  
>>> wait  to
>>> get us on IPv6"....
>>>
>>
>>
>>
>> --
>> Cort Buffington
>> Executive Director
>> The Kansas Research and Education Network
>> cort at kanren.net
>> Office: +1-785-856-9800 x301
>> Mobile: +1-785-865-7206
>>
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>
>

--
Cort Buffington
Interim Executive Director
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206






From jcurran at istaff.org  Fri Sep  5 01:16:01 2008
From: jcurran at istaff.org (John Curran)
Date: Fri, 5 Sep 2008 01:16:01 -0400
Subject: [arin-ppml] An ARIN request to return address space as a service to
	community?
In-Reply-To: <alpine.BSF.1.10.0809040908520.17102@hiroshima.bogus.com>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
	<alpine.BSF.1.10.0809040908520.17102@hiroshima.bogus.com>
Message-ID: <E1BF45F6-1044-4437-A828-29E8AE637EEE@istaff.org>

Interesting...  I believe that requests like these have been made before
in various forms (e.g. RFC1917/BCP 4) but if folks think that ARIN  
making
such a request is important, I expect it could be done quite easily.

While I agree that it is simple, elegant, and in keeping with the spirit
of "old Internet", is there any chance that the request will also be  
seen
as "quaint" and/or perhaps "out of touch with reality"?  Would that  
matter?

/John
(purely my arrangement of bits
  in ascii-like patterns)


On Sep 4, 2008, at 12:15 PM, Lucy Lynch wrote:

> +1
>
> Simple, elegant, in the spirit of the "old Internet", and
> polite! How often do we see that these days?
>
> - Lucy
>
> On Thu, 4 Sep 2008, Bill Darte wrote:
>
>> My personal opinion is:
>>
>> "The ARIN Board of Trustees on behalf of ARIN and the community at  
>> large
>> requests that as a service to that community, holders of address  
>> space
>> which is available to return, or which they are willing to make
>> available for return, should do so at their earliest convenience.  On
>> behalf of the community that will need these addresses as the  
>> industry
>> transitions to IPv6, ARIN thanks you."
>>
>> bd


From BillD at cait.wustl.edu  Fri Sep  5 07:48:48 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 5 Sep 2008 06:48:48 -0500
Subject: [arin-ppml] An ARIN request to return address space as a
	service to community?
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
	<alpine.BSF.1.10.0809040908520.17102@hiroshima.bogus.com>
	<E1BF45F6-1044-4437-A828-29E8AE637EEE@istaff.org>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531BFB@ex1.cait.wustl.edu>

I think that often it is necessary to deviate from the norm...like it or not. This may be such a time.

But, I think that whenever possible one should state the principles upon which one operates or wishes to do so.

Making a statement like the one I proposed...if the Board actually believed that they wished the outcome of freely returned addresses...would establish how the Board wished the system to operate and would explicitly encouraged appropriate behavior.

Regardless of whether the expression is received as quaint or out of touch, the BoT could proceed based upon whatever outcomes are reached.  Lots of addresses returned, great.  No addresses returned, next option.  Derision and chiding...ask those who do so for a better proposal.

I suspect that the BoT perceives it has done what I propose already implicitly, but I for one would like to see a similar statement issued especially to those who have so much and use so little.... to establish once and for all that the BoT believes the right thing to do is to return those resources to the community.

Again, personally.  I do not request that this statement or another similar be made.  That is for others to decide.  I merely answered Lee's question on how ARIN might ask for addresses to be returned.  In the hierarchy of possibilities he posed, this seemed to be the most simple, straighforward, and consistent with how I perceive the Internet community has/should operate.

bd


-----Original Message-----
From: John Curran [mailto:jcurran at istaff.org]
Sent: Fri 9/5/2008 12:16 AM
To: Lucy Lynch; Bill Darte
Cc: arin-ppml at arin.net
Subject: An ARIN request to return address space as a service to community?
 
Interesting...  I believe that requests like these have been made before
in various forms (e.g. RFC1917/BCP 4) but if folks think that ARIN  
making
such a request is important, I expect it could be done quite easily.

While I agree that it is simple, elegant, and in keeping with the spirit
of "old Internet", is there any chance that the request will also be  
seen
as "quaint" and/or perhaps "out of touch with reality"?  Would that  
matter?

/John
(purely my arrangement of bits
  in ascii-like patterns)


On Sep 4, 2008, at 12:15 PM, Lucy Lynch wrote:

> +1
>
> Simple, elegant, in the spirit of the "old Internet", and
> polite! How often do we see that these days?
>
> - Lucy
>
> On Thu, 4 Sep 2008, Bill Darte wrote:
>
>> My personal opinion is:
>>
>> "The ARIN Board of Trustees on behalf of ARIN and the community at  
>> large
>> requests that as a service to that community, holders of address  
>> space
>> which is available to return, or which they are willing to make
>> available for return, should do so at their earliest convenience.  On
>> behalf of the community that will need these addresses as the  
>> industry
>> transitions to IPv6, ARIN thanks you."
>>
>> bd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080905/e07fb3ff/attachment.htm>

From BillD at cait.wustl.edu  Fri Sep  5 08:32:36 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 5 Sep 2008 07:32:36 -0500
Subject: [arin-ppml] maintenance fees for legacy space holders
References: <48BF0C07.9020602@sprunk.org>	<369EB04A0951824ABE7D8BAC67AF9BB40B284D85@CL-S-EX-1.stanleyassociates.com>	<001601c90e9c$c308ca30$491a5e90$@org>	<F0F560F4-66CC-40EF-ACB2-A93D8FB95C02@delong.com>	<000301c90ec4$40d416f0$c27c44d0$@org>
	<6EC8943E-5A49-406A-B6FD-995BB0D8C17F@delong.com>
	<48C058C2.7050606@bogomips.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087531BF7@ex1.cait.wustl.edu>
	<48C07FD2.8080904@bogomips.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531BFF@ex1.cait.wustl.edu>

Please see Lee Howard's long list of services provided by ARIN in an earlier email.

The simplistic argument that ARIN is a staff of folks who stand around making money while watching a database store bits is specious and disingenuous.

"I'm not going to moan here about all the hard work of the legacy holders and how 
they deserve a free ride,"... I hear moaning from somewhere.

Picture certain /8 legacy holders staring and repetitively sifting through their fingers...large handfuls of IP addresses piled upon a table. 

Still, I'm of the opinion that these legacy holders should maintain control over those addresses if they don't wish to share.

I do object to ARIN purposefully erecting a market that introduces and encourages monetary value of those resources and in the bargain, establishes a more durable use case for those resources rather than encouraging the movement to a new and virtually free substitute.

My personal opinion only.

bd


-----Original Message-----
From: John Paul Morrison [mailto:jmorrison at bogomips.com]
Sent: Thu 9/4/2008 7:39 PM
To: Bill Darte
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] maintenance fees for legacy space holders
 
I never said it was worth nothing. Owen  Delong asked how to justify a 
different pricing model and I simply gave some examples.

Maybe it should be $10/year or maybe $10 every time someone changes 
their whois or DNS record, or maybe it's a sunk cost - it's net $0/year 
but that doesn't make it worthless. I don't know if ARIN has an 
endownment, but maybe they have capital assets, software etc. that were 
given to them.  The biggest "Legacy" ARIN inherited is not the Legacy IP 
assignments but rather it is the recurring income they receive from 
fees, derived from administering a database of numbers (the Banks must 
be envious!) -  for a protocol developed and funded largely by 
governments, military, academic and corporate research groups. I'm not 
going to moan here about all the hard work of the legacy holders and how 
they deserve a free ride, but I'm not going to cry about that fact either.

As Cliff Bedore and Eric Westbrook point out though, it isn't just about 
the money.


On 9/4/2008 4:59 PM, Bill Darte wrote:
>
> The services rendered to legacy holders is real and if you don't think 
> it is worth anything then simply say.
> Please stop providing any and all services that are rendered on behalf 
> of legacy addresses that have taken effect since the initial allocation.
> Fair?
> bd
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of John Paul Morrison
> Sent: Thu 9/4/2008 4:53 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] maintenance fees for legacy space holders
>
> On 9/4/2008 1:17 PM, Owen DeLong wrote:
> > The problem comes in trying to justify why you have a different
> > pricing model for Legacy than for everyone else who is (and has
> > been) paying the standard fees for years.
> >  
> This isn't that hard.
>
> First of all, there was no fee specified at the time they were given.
> And IP addresses were given out, no strings attached, with no
> expectation that they would come back, so why would there be any
> expectation of a recurring charge? If an item was given away for free
> with no terms of service, how can one argue that a "service" whether
> it's whois/DNS, or PPML, be tacked on later and then charged for? Under
> that light, $10/year seems fair, even charitable of Legacy holders to
> pay, given there's likely been little change since the original
> assignments.
>
> Second, there's no real justification for any costs to Legacy holders.
> The addresses were given out while the administration of the Internet
> was publicly funded, by the NSF, CA*Net (in Canada) etc., so any real
> work has already been paid out of tax dollars. The allocation is simply
> an entry in a database, or back of a napkin for that matter. It's great
> that it's recorded in Whois, but it's not a requirement that it be 
> that way.
>
> For the sake of argument, someone could document all the Legacy
> allocations and publish an RFC and say 'that's the historical record'
> and do away with any whois, other requirements, or ARIN's involvement
> with all of Legacy space for that matter, and that would be the
> historical record for all time, unless anyone cared enough to make minor
> revisions as a courtesy. What's to distinguish one Legacy assignment
> from another? 127.0.0.0/8 is assigned in an RFC, so are the Class E
> addresses and many others. I'm pretty sure the RFC process pre-dates
> whois, especially since 811 prior RFCs were published before they got
> around to publishing the one for Whois, but I could be wrong. (And if
> this Legacy holders RFC were published on April 1, I think that would
> definitely absolve the Legacy holders of any obligation to chip in for
> their 1/5000th share of the costs of hosting and maintaining the RFCs!)
>
> Especially in light of IPv4 address exhaustion, would anyone like to
> reclaim 127.0.0.0/8 or the Class E space, or parts of Legacy space? Yes,
> of course if we had the chance to do it all over, we would do things
> differently, but we can't. If people don't like that, that's too bad. In
> practical terms, IP address assignments are permanent and irrevocable.
>
> > If we're going to drop the annual maintenance fee to some lower
> > level, I'd like to see that happen across the board rather than
> > just for legacy holders.  Thus, we'd need to calculate it
> > in those terms.
> >  
> It's sounding like it's just not worth the effort to collect a token
> amount.
> > Owen
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >  
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080905/378686d1/attachment.htm>

From Lee.Howard at stanleyassociates.com  Fri Sep  5 08:31:16 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Fri, 5 Sep 2008 08:31:16 -0400
Subject: [arin-ppml] maintenance fees for legacy space holders
In-Reply-To: <48C07FD2.8080904@bogomips.com>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2315@CL-S-EX-1.stanleyassociates.com>

Without commenting on the specifics of what the fee might be. . .

> Maybe it should be $10/year or maybe $10 every time someone changes 
> their whois or DNS record, or maybe it's a sunk cost - it's net 
> $0/year but that doesn't make it worthless. I don't know if ARIN has 
> an endownment, but maybe they have capital assets, software etc. that 
> were given to them.   
	 
In ARIN's ten year history, all of the original gifts have long since
been depreciated and replaced.  We do receive some contributions, 
mostly in the form of organizations sponsoring meetings, or coffee/
snack breaks at the meetings.  We do have a reserve of about two
years' expenses, but that's from keeping expenses below revenues, not
from initial gifts.

>  The biggest "Legacy" ARIN inherited is not the Legacy IP assignments 
> but rather it is the recurring income they receive from fees, derived 
> from administering a database of numbers (the Banks must be envious!) 

Except that ARIN is not run for profit, we only try to recover our
costs.  Prior to ARIN (someone correct me if I'm wrong, I wasn't deeply
involved then) the address registry was financially supported by the
names registry, and before that it was funded by the U.S. government.  

Lee


From dwhite at olp.net  Fri Sep  5 09:56:05 2008
From: dwhite at olp.net (Dan White)
Date: Fri, 05 Sep 2008 08:56:05 -0500
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C09704.7050108@cjbsys.bdb.com>
References: <48C01D9B.10400@cjbsys.bdb.com>	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
	<48C09704.7050108@cjbsys.bdb.com>
Message-ID: <48C13A75.1070109@olp.net>

Cliff Bedore wrote:
> I read it and am impressed that you have gone as far as you have. I
> think you will have to admit you are not a typical CEO in a typical 
> for-profit company and are probably in the very small minority of 
> entities who have gone gung ho for IPv6.  As you point out, lots of 
> people bought Beta video players, HD DVD.  Hell I was a big proponent of 
> CPM86/Concurrent CPM/86.  It was a much better system than MSDOS but 
> that didn't make it a success.  And don't get me wrong.  I'm not 
> particularly anti-IPv6 but it's just NOT happening in most of the 
> world.  It doesn't seem like we're going to get a disruptive application 
> for IPv6 so we need another hook to get people to buy in.  The only one 
> I see is to get IPv6 and IPv4 talking transparently so we don't need 
> dual stack and people can keep resources that use IPv4 and get to IPv6 
> as progress and funds allow.  No one wants to go to IPv6 by itself 
> because there is too much IPv4 they couldn't reach.  Dual stack is a 
> kludge(IMO).  We need transparent communication between them and without 
> that, I don't believe IPv6 will take off in my lifetime.
>
> Cliff
>   

I think there's an implication in this line of reasoning that IPv6 is 
hard, and that dual stack is bad.

Dual-stack IPv4/IPv6 is easy. You just enable it in your OS, or perhaps 
it already is. IPv4 continues to work uninterrupted, dual stack servers 
are reachable and IPv6 only sites are reachable. I don't really see any 
downsides to this approach except for inevitable bugs and issues that 
are bound to pop up with new technology.

Of course, this is an overly simplistic scenario, but my point is that 
it's supposed to be easy for customers. It's not their job to worry 
about all the network engineering involved to make this happen. As a 
service provider, or network manager, it's your job, in my opinion, to 
engineer the network to support easy access to IPv6 and to figure out 
all the hard stuff for the benefit of your users. If engineered 
correctly, IPv6 deployment should be nearly unnoticeable to the majority 
of typical Web/Email users.

Networks are certainly different, and there are many barriers to entry 
(consumer routers being a big one) but making roll out as easy as 
possible for service providers, using translators and proxies and such, 
should not really be our primary goal.

Also, IPv6 was not designed as a product. It should not really depend on 
residential demand. It's a protocol designed to address the short 
comings of IP4 and should be used as a tool to provide better service, 
or service where it would not be feasible.

- Dan


From mueller at syr.edu  Fri Sep  5 10:30:05 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 5 Sep 2008 10:30:05 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
References: <48C01D9B.10400@cjbsys.bdb.com>
	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Cort Buffington
> Sent: Thursday, September 04, 2008 6:36 PM
> I've also worked in commercial two-way radio. I remember when  
> frequencies started to become scarce and the FCC started auctioning  
> off spectrum to the highest bidder. I talked to the guy (like 10  
> minutes ago) I worked for back then. I gave him the choice of 
> running out of spectrum and ending up in the auction environment we
have  
> today, or taking 5 years to replace the majority of his 
> infrastructure so that he'd never be unable to get frequencies.
Clearly, he'd have  
> opted to replace infrastructure. 

I am not sure I understand your point here. Exactly what infrastructure
changes did you suggest that would ensure someone in the 2-way radio
space that they would "never be unable to get frequencies?"

Further, if you were advising the FCC in the mid-1980s (as I was) and
they were faced with 6-10 different radio services contending for the
same narrow band of frequencies, how would you have told them to handle
the contention for the resource if not through auctions? 




From iljitsch at muada.com  Fri Sep  5 10:59:45 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Fri, 5 Sep 2008 16:59:45 +0200
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C01D9B.10400@cjbsys.bdb.com>
References: <48C01D9B.10400@cjbsys.bdb.com>
Message-ID: <73B3F4FB-6922-47E9-B3FD-CA8B86AB0749@muada.com>

On 4 sep 2008, at 19:40, Cliff Bedore wrote:

> Having been reading this group for approaching a year or so now, I  
> think
> I've seen the problem with adopting IPv6.  Nobody really wants it.

I don't think that's true.

Most people don't know enough to either want it or not want it. Of the  
people who know, I'm pretty sure a decent number want it, but the  
trouble is that if you're the only one running IPv6, it doesn't do  
much for you. Other people have to run it, too.

As someone how used to configure routers for a living, I want IPv6,  
because it makes my former job easier. (But few people configure  
routers, let alone for a living.)

> The problem:  There is no compatibility bit in IPv6 that says I'm just
> like IPv4 but I have 96 more address bits.

Although it doesn't seem like it, the current situation is as good as  
it gets. For the details:

http://www.bgpexpert.com/article.php?article=106

> The backbone for the Internet will have to
> be IPv6, DNS will have to be IPv6

Not a problem. I already get 10 - 20 % IPv6 hits on my DNS server and  
25 - 50 % of the big backbone networks have some kind of IPv6 running  
today.

> and IPv4 will be treated as IPv6 on
> the Internet and translated through the "converter box (CB)".  This
> means that the CB will have to do both translation and DNS lookups for
> the v4 hosts.

I'm not sure what you have in mind. The problem is that at some point  
within the next years, there won't be enough IPv4 addresses to  
continue current practices. So ISPs will have to figure out a way to  
connect new customers without being able to give these customers their  
own address. NAT can solve the immediate problem, but you can't slice  
and dice public IPv4 addresses forever by adding more NATs.

So at some point end-users will gradually have to start running IPv6.  
At that point, translation becomes useful because these people can  
then talk to people who are still IPv4-only. But translation in and of  
itself doesn't solve anything, and it also incorporates NAT so most of  
the downsides of IPv4 NAT are still there.

> Since there are 64 bits per subnet in IPv6, there will
> never be a subnet that can't split off IPv4 addresses through the CB  
> for
> translation.

Not sure what you mean and no idea what CB is. (Citizen's band?)

> That's a short summary of a big problem but I think it's obvious that
> there has been little real adoption of IPv6.

We don't need IPv6 today. So the fact that we don't see IPv6 today  
doesn't mean all that much. There's still time.

> We really need a program
> that accomplishes what the US HDTV program did.  Tell people that "on
> MM/DD/YY, the Internet backbone will be IPv6 only.  If you want to run
> IPv4, you will need one(or more) of the converter boxes for your IPv4
> addresses.  If you don't do this, you will lose Internet connectivity"

Ah, but our technology is much more advanced than that. Unlike digital  
TV (which may or may not be HD) versus analog TV, we can run both IP  
versions side by side, and even when IPv4 runs out of steam because of  
lack of addresses, the people who already have an address can keep  
using it.

> 1.  All IPv4 space effectively becomes PI space since you can tuck  
> your
> IPv4 into any IPv6 subnet

Unfortunately, this only works in the outgoing direction. In other  
words: you can put hundreds or thousands of clients behind a single  
public IPv4 address and translate from their public IPv6 address or  
private IPv4 address to that public address when they initiate an  
outgoing session, but receiving incoming sessions is much harder: then  
the translator needs to know how to map the sessions and the rest of  
the world needs to know which port number to use (no "80 for web, 25  
for mail" shortcuts).


From iljitsch at muada.com  Fri Sep  5 11:07:59 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Fri, 5 Sep 2008 17:07:59 +0200
Subject: [arin-ppml] An ARIN request to return address space as a
	service to community?
In-Reply-To: <E1BF45F6-1044-4437-A828-29E8AE637EEE@istaff.org>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
	<alpine.BSF.1.10.0809040908520.17102@hiroshima.bogus.com>
	<E1BF45F6-1044-4437-A828-29E8AE637EEE@istaff.org>
Message-ID: <77A4E4AE-5D40-4F0E-8A0F-4A5D088BC8D3@muada.com>

On 5 sep 2008, at 7:16, John Curran wrote:

> While I agree that it is simple, elegant, and in keeping with the  
> spirit
> of "old Internet", is there any chance that the request will also be
> seen
> as "quaint" and/or perhaps "out of touch with reality"?  Would that
> matter?

Observation: about a quarter of the legacy /8s are held by various US  
government entities. How about instigating an effort in Washington to  
get a significant part of that returned?

I'm sure a lot of that DOD space is used for military purposes, but I  
should hope that that stuff isn't connected to the public internet. If  
it isn't, that space can be reused, with the only issue being the  
systems that must connect to both the public internet and the private  
military systems.


From jcurran at istaff.org  Fri Sep  5 11:16:03 2008
From: jcurran at istaff.org (John Curran)
Date: Fri, 5 Sep 2008 11:16:03 -0400
Subject: [arin-ppml] An ARIN request to return address space as a
	service to community?
In-Reply-To: <77A4E4AE-5D40-4F0E-8A0F-4A5D088BC8D3@muada.com>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
	<alpine.BSF.1.10.0809040908520.17102@hiroshima.bogus.com>
	<E1BF45F6-1044-4437-A828-29E8AE637EEE@istaff.org>
	<77A4E4AE-5D40-4F0E-8A0F-4A5D088BC8D3@muada.com>
Message-ID: <A159369A-C861-4C94-8538-7C1117F54C95@istaff.org>

On Sep 5, 2008, at 11:07 AM, Iljitsch van Beijnum wrote:
> Observation: about a quarter of the legacy /8s are held by various  
> US government entities. How about instigating an effort in  
> Washington to get a significant part of that returned?

Already done, and the USG has been actively returning address space
as it becomes available (e.g. <http://blog.icann.org/?p=271>)

/John


From iljitsch at muada.com  Fri Sep  5 11:27:04 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Fri, 5 Sep 2008 17:27:04 +0200
Subject: [arin-ppml] An ARIN request to return address space as a
	service to community?
In-Reply-To: <A159369A-C861-4C94-8538-7C1117F54C95@istaff.org>
References: <EACF8B735E9CBA4B8BAF9E4165D030877AD34D@ex1.cait.wustl.edu>
	<369EB04A0951824ABE7D8BAC67AF9BB40B284DE7@CL-S-EX-1.stanleyassociates.com>
	<EACF8B735E9CBA4B8BAF9E4165D030877AD35A@ex1.cait.wustl.edu>
	<alpine.BSF.1.10.0809040908520.17102@hiroshima.bogus.com>
	<E1BF45F6-1044-4437-A828-29E8AE637EEE@istaff.org>
	<77A4E4AE-5D40-4F0E-8A0F-4A5D088BC8D3@muada.com>
	<A159369A-C861-4C94-8538-7C1117F54C95@istaff.org>
Message-ID: <3CEB515F-51D4-4F92-975C-7DCA9ACB2321@muada.com>

On 5 sep 2008, at 17:16, John Curran wrote:

> On Sep 5, 2008, at 11:07 AM, Iljitsch van Beijnum wrote:
>> Observation: about a quarter of the legacy /8s are held by various  
>> US government entities. How about instigating an effort in  
>> Washington to get a significant part of that returned?

> Already done, and the USG has been actively returning address space
> as it becomes available (e.g. <http://blog.icann.org/?p=271>)

I was thinking more along the lines of a "call your senator to support  
the 'save the internet act'" kind of thing...

Iljitsch


From owen at delong.com  Fri Sep  5 12:51:07 2008
From: owen at delong.com (Owen DeLong)
Date: Fri, 5 Sep 2008 09:51:07 -0700
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>
References: <48C01D9B.10400@cjbsys.bdb.com>
	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
	<7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>
Message-ID: <0EB47134-25C5-4AA8-BBDC-23EE719E9C19@delong.com>

> I am not sure I understand your point here. Exactly what  
> infrastructure
> changes did you suggest that would ensure someone in the 2-way radio
> space that they would "never be unable to get frequencies?"
>
> Further, if you were advising the FCC in the mid-1980s (as I was) and
> they were faced with 6-10 different radio services contending for the
> same narrow band of frequencies, how would you have told them to  
> handle
> the contention for the resource if not through auctions?
>
The FCC auction system has had numerous problems.  Were the FCC
to apply auctioning across the board, how much spectrum do you think
would still be available to Amateur Radio Operations or Public Services
as primary users?  What if the Military had to add their spectrum  
demands
into their budget?

The reality is that the FCC has chosen a non-auction mechanism for the
vast majority of spectrum and uses auctions to dispense what is left
after they have allocated spectrum to non-commercial uses that are
considered important by the FCC.

This is a VERY GOOD thing as the results of pure auctioning would
be terrible and produce a spectrum chart that did not work at all well
with the rest of the world (which would be especially tragic in the
HF bands).

I think that what would happen if you turned the entire RF spectrum
over to the auction process is an excellent example of why dollars
might not be the best method for measuring where IP addresses
should go.

Owen



From mueller at syr.edu  Fri Sep  5 13:05:55 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 5 Sep 2008 13:05:55 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <0EB47134-25C5-4AA8-BBDC-23EE719E9C19@delong.com>
References: <48C01D9B.10400@cjbsys.bdb.com>
	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
	<7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>
	<0EB47134-25C5-4AA8-BBDC-23EE719E9C19@delong.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E69B@SUEXCL-02.ad.syr.edu>



> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]

> The reality is that the FCC has chosen a non-auction mechanism for the
> vast majority of spectrum and uses auctions to dispense what is left
> after they have allocated spectrum to non-commercial uses that are
> considered important by the FCC.

To put it more accurately, when there are many contending commercial
applications for _exclusive use_ of the same spectrum, i.e. scarcity of
the sort faced in IPv4, they tend to use auctions. 

I personally have been a big advocate of unlicensed spectrum and making
more of that available, too. Some have tried to argue that all spectrum
should be exclusive/auctioned, others that it all should be unlicensed.
In fact, both models should exist, each has its strengths and
weaknesses. And there is still some role for administrative allocations.


The industry and most policy analysts have accepted this combination as
the best way to go, because each allocation model has its strengths and
weaknesses in different types of uses.

One could compare IPv6 space to unlicensed, freely available and IPv4 to
exclusive/licensed/scarce. 

> What if the Military had to add their spectrum
> demands into their budget?

It would very good, except that under most recent administrations DoD is
given a blank check. We should know how much military spectrum usage
actually costs the country. Surely you are not suggesting that by not
having a transparent cost for military resources it is somehow "free?" 



From mueller at syr.edu  Fri Sep  5 13:15:40 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 5 Sep 2008 13:15:40 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <BCE06A01-31D5-4EB9-9110-0697FE1D4C1F@kanren.net>
References: <48C01D9B.10400@cjbsys.bdb.com>
	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
	<7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>
	<BCE06A01-31D5-4EB9-9110-0697FE1D4C1F@kanren.net>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E69D@SUEXCL-02.ad.syr.edu>


> -----Original Message-----
> From: Cort Buffington [mailto:cort at kanren.net]
> 
> I "translated" the concept of moving from IPv4 to IPv6 with my two-way
> friend by comparing it to moving from 25kHz channels to 12.5kHz
> channels in analog FM (for example), 

Yes, but this kind of change in fact WAS made repeatedly in the 2-way
radio space, within the same spectrum. The situation was quite analogous
to running out of IPv4 addresses. Instead of expanding the amount of
spectrum used, specialized mobile radio operators made equipment and
standards changes to enable more intensive use of existing spectrum. It
is very similar to using NAT or some other reorg of existing address
space. 

Transfers or no transfers, people will be faced with economic incentives
of that sort. 

So, don't assume that if we just shut off IPv4 then everyone will
migrate to IPv6. Herrin and others have been making the much more
realistic point that that may not happen. People may just make more
intensive use of IPv4 via NAT and other techniques. 

> "spectrum savings" equal to the address space added by IPv6 (obviously
> much more drastic savings than 2:1). His answer, having lived with the
> loss of spectrum and business for many years now, was that it would
> clearly be worth, and would have been worth the necessary
> infrastructure changes to accommodate it, and that given the CHOICE,
> he would have suffered infrastructure upgrades had he been given an
> option back then. We have an option now, but folks don't seem to see
> value. Perhaps if we didn't have an option, an option would look
> better to us?
> 
> I'm overly philosophical about it I'm afraid.
> Cort
> 


From Lee at Dilkie.com  Fri Sep  5 14:09:05 2008
From: Lee at Dilkie.com (Lee Dilkie)
Date: Fri, 05 Sep 2008 14:09:05 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E69D@SUEXCL-02.ad.syr.edu>
References: <48C01D9B.10400@cjbsys.bdb.com>	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>	<7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>	<BCE06A01-31D5-4EB9-9110-0697FE1D4C1F@kanren.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E69D@SUEXCL-02.ad.syr.edu>
Message-ID: <48C175C1.6070309@Dilkie.com>



Milton L Mueller wrote:
>> -----Original Message-----
>> From: Cort Buffington [mailto:cort at kanren.net]
>>
>> I "translated" the concept of moving from IPv4 to IPv6 with my two-way
>> friend by comparing it to moving from 25kHz channels to 12.5kHz
>> channels in analog FM (for example), 
>>     
>
> Yes, but this kind of change in fact WAS made repeatedly in the 2-way
> radio space, within the same spectrum. The situation was quite analogous
> to running out of IPv4 addresses. Instead of expanding the amount of
> spectrum used, specialized mobile radio operators made equipment and
> standards changes to enable more intensive use of existing spectrum. It
> is very similar to using NAT or some other reorg of existing address
> space. 
>
>
>   
I don't think the analogy is at all correct.

Radio spectrum has a physical hard limit and there is no substitution
(until subspace radio is invented). So obviously the effort has *always*
been to improve utilization of a fixed resource. I see no reason why
this won't continue.

The difference we have in the internet, we have an alternative in IPv6.
So the question that has yet to be answered is at what point(s) will the
cost/effort of deploying IPv6 outweigh the costs/effort of improving the
utilization of IPv4. I'm sure the answer to this will be "it depends"
and different folks will have different timelines for both solutions.

Personally. I think we are all worrying about this way too much. After
ARIN gives out it's last block, then you'll see a combination of IPv4
utilization improvements and IPv6 uptake. I don't foresee a panic or
anything like that.

-lee


From owen at delong.com  Fri Sep  5 14:14:18 2008
From: owen at delong.com (Owen DeLong)
Date: Fri, 5 Sep 2008 11:14:18 -0700
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E69B@SUEXCL-02.ad.syr.edu>
References: <48C01D9B.10400@cjbsys.bdb.com>
	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
	<7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>
	<0EB47134-25C5-4AA8-BBDC-23EE719E9C19@delong.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E69B@SUEXCL-02.ad.syr.edu>
Message-ID: <170B3867-D634-4DCF-9BE7-B954B4D479E9@delong.com>


On Sep 5, 2008, at 10:05 AM, Milton L Mueller wrote:

>
>
>> -----Original Message-----
>> From: Owen DeLong [mailto:owen at delong.com]
>
>> The reality is that the FCC has chosen a non-auction mechanism for  
>> the
>> vast majority of spectrum and uses auctions to dispense what is left
>> after they have allocated spectrum to non-commercial uses that are
>> considered important by the FCC.
>
> To put it more accurately, when there are many contending commercial
> applications for _exclusive use_ of the same spectrum, i.e. scarcity  
> of
> the sort faced in IPv4, they tend to use auctions.
>
No... That is not more accurate.  That is more in line with your idea of
how things should work.

The FCC has reserved many chunks of spectrum as primary to
a number of non-commercial uses.  These chunks of spectrum
are not available to the auction process for exclusive use. The FCC
has auctioned off some of these chunks to "secondary" users.

For people unfamiliar with what this means, I'll digress briefly to
explain...

There is almost no RF spectrum allocated to exclusive use by a single
class of service or user(s).  The AM and FM broadcast bands, aircraft
communications and navigation, some of the military bands and a
limited number of others are allocated on a "exclusive use" basis.

Most RF spectrum is allocated to one primary and one or more
secondary uses.

A primary user of RF spectrum has the right to use that spectrum
as they are licensed so long as they are not causing harmful  
interference
to a fellow primary user. (For example if the primary use is Amatuer
radio, any licensed Ham may use the frequency, but, not in such a
way as to cause harmful interference to another Ham).

A secondary user of RF spectrum has the right to use that spectrum
so long as they do not cause interference to any primary user or
harmful interference to any secondary user.

Nonetheless, the fact remains that the vast majority of RF spectrum
is licensed, but, not exclusive use.  Additionally, only a tiny fraction
of that is auctioned, especially on a primary use basis.

> I personally have been a big advocate of unlicensed spectrum and  
> making
> more of that available, too. Some have tried to argue that all  
> spectrum
> should be exclusive/auctioned, others that it all should be  
> unlicensed.
> In fact, both models should exist, each has its strengths and
> weaknesses. And there is still some role for administrative  
> allocations.
>
You make this statement as if there is no licensed spectrum that is not
auctioned.  That simply isn't the case.  MOST licensed spectrum is not
auctioned, at least on a primary basis.

For more information, take a look at:

http://www.ntia.doc.gov/osmhome/allochrt.pdf

It does a pretty good job of displaying the US frequency spectrum and
how it is utilized.  Note that the vast majority of it is licensed and  
not
commercial.  To the best of my knowledge, auctions have only been
done for commercial use.

>
> The industry and most policy analysts have accepted this combination  
> as
> the best way to go, because each allocation model has its strengths  
> and
> weaknesses in different types of uses.
>
Of course industry likes it.  However, industry is not the only user  
of RF
spectrum, just as they are not the only user of IP.  Using the  
willingness
and ability to put dollars into getting a resource is a fine way of  
measuring
it's commercial value and optimizing the distribution on that basis.
However, when one non-commercial interests also need parts of the
same finite resource, such an approach tends to treat such users
as unimportant.

> One could compare IPv6 space to unlicensed, freely available and  
> IPv4 to
> exclusive/licensed/scarce.
>
One could compare scissors to pocket knives, and fingers to toes, but,
I'm not sure that such comparisons would be any more or less useful.

>> What if the Military had to add their spectrum
>> demands into their budget?
>
> It would very good, except that under most recent administrations  
> DoD is
> given a blank check. We should know how much military spectrum usage
> actually costs the country. Surely you are not suggesting that by not
> having a transparent cost for military resources it is somehow "free?"

I am suggesting that how you measure cost and how I measure cost
may differ.  You are convinced that your method is vastly superior to
mine.  I am not. I am not completely convinced either way.  However,
from my observations, the blind faith that using money to measure
importance will cause society to choose the correct priorities is
misguided at best.

The military has always had a nearly blank check in one form or
another with occasional and short-lived exceptions.

Under the current circumstances, the military's RF spectrum
use could be said to cost the country the opportunity of the
revenue that auctioning it might bring.  However, if the military
were to have to purchase its spectrum at auction, what it would
cost, instead, would be that opportunity (the government didn't
make the revenue, it merely moved it from the military pile
to the FCC pile) in addition to the costs of administering the
auction, dealing with the law suits about the auctioneer being
a bidder, the overhead and accounting costs on the FCC and
military sides of the transfer of funds, etc.

It would increase the costs without producing revenue to offset
those increased costs. This does not seem in the best interests
of the taxpayers in my view.

Owen



From kkargel at polartel.com  Fri Sep  5 14:22:34 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 5 Sep 2008 13:22:34 -0500
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <0EB47134-25C5-4AA8-BBDC-23EE719E9C19@delong.com>
References: <48C01D9B.10400@cjbsys.bdb.com><5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net><7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>
	<0EB47134-25C5-4AA8-BBDC-23EE719E9C19@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10ACB@mail>

My own humble and paranoid (and hopefully primarily erroneus) feeling is
that the transfer process is being pushed by a few individuals who plan or
hope to take a large short term profit.  I am an ISP and I know that I would
not enjoy competing to pay top dollar for addresses.  

What follows here will border on being a theistic rant, so feel free to quit
here.  

I am heartily afraid of a number of things should this come to pass.  First
and formost is that it would add more than significant cost to doing
business.  This would be passed on to end users, with the end result of
pushing the affordability of internet access out of the hands of common
people, further stratifying the class structure in our society.  Upper
middle and higher income classes will have more access to information and
services, while middle and lower income classes will be kept at a
disadvantage.  The class boundaries will be harder to cross when the tools
are further restricted.  It will be more difficult for the lower class
student to compete fairly with the upper class student who has fast and
instant access to references at home. 

The additional cost will neither help nor hinder business.  So long as the
playing field is level then resource capital expenditure is largely
transparant and transitory.  It is passed to the consumer, and the only
effect business sees is a small profit increase due to markup as it passes
through.  

Small business will be at a distinct disadvantage in getting and maintaining
connectivity.  As with everything advantages of scale will apply, and the
small business that needs a /24 will pay orders of magnitude more (per
unit)for PI than will the megacorp that purchases a /8.  Permitting
commercialization or converting IP addresses to a commodity will further the
advantages of monopolistic business, and will severely handicap the SBO or
family business.

The industry that we are in is more than a business, we have direct impact
on society and quality of life, and thereby we have more than normal
responsibility to safeguard the public interest (Use the power wisely,
Luke)..  Our decisions cannot be based entirely on business and bottom line.


I am a median line capitalist, and I do believe that capitalistic drivers
are good and necessary for shaping business.  Having said that it is
expressly the cooperative anarchy that has let the internet develop into the
wonderful and functional entity that it is.  Without the free thinking
methods of open source and the tremendous works of organizions such as ARIN
the various standards bodies the Internet would not have evolved into the
amazing thing we have today.  

Turning IP addresses into a commodity with a unit cost does one more thing,
it makes it easier for goverments to quantify, tax and control the
commodity.  This in itself has terrifying possibilities.

OK, I will step down from my soapbox for a while again..  I apologize for
taking your time with my rant, but Heretic Thoughts seemed the appropriate
place to be.

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Owen DeLong
Sent: Friday, September 05, 2008 11:51 AM
To: Milton L Mueller
Cc: PPML
Subject: Re: [arin-ppml] IPv6 Heretic thoughts

> I am not sure I understand your point here. Exactly what 
> infrastructure changes did you suggest that would ensure someone in 
> the 2-way radio space that they would "never be unable to get 
> frequencies?"
>
> Further, if you were advising the FCC in the mid-1980s (as I was) and 
> they were faced with 6-10 different radio services contending for the 
> same narrow band of frequencies, how would you have told them to 
> handle the contention for the resource if not through auctions?
>
The FCC auction system has had numerous problems.  Were the FCC to apply
auctioning across the board, how much spectrum do you think would still be
available to Amateur Radio Operations or Public Services as primary users?
What if the Military had to add their spectrum demands into their budget?

The reality is that the FCC has chosen a non-auction mechanism for the vast
majority of spectrum and uses auctions to dispense what is left after they
have allocated spectrum to non-commercial uses that are considered important
by the FCC.

This is a VERY GOOD thing as the results of pure auctioning would be
terrible and produce a spectrum chart that did not work at all well with the
rest of the world (which would be especially tragic in the HF bands).

I think that what would happen if you turned the entire RF spectrum over to
the auction process is an excellent example of why dollars might not be the
best method for measuring where IP addresses should go.

Owen

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public
Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080905/876fef65/attachment.bin>

From owen at delong.com  Fri Sep  5 14:24:29 2008
From: owen at delong.com (Owen DeLong)
Date: Fri, 5 Sep 2008 11:24:29 -0700
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E69D@SUEXCL-02.ad.syr.edu>
References: <48C01D9B.10400@cjbsys.bdb.com>
	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>
	<7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>
	<BCE06A01-31D5-4EB9-9110-0697FE1D4C1F@kanren.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E69D@SUEXCL-02.ad.syr.edu>
Message-ID: <922DFDAA-DD18-48F1-93B9-80A18F090C7D@delong.com>


On Sep 5, 2008, at 10:15 AM, Milton L Mueller wrote:

>
>> -----Original Message-----
>> From: Cort Buffington [mailto:cort at kanren.net]
>>
>> I "translated" the concept of moving from IPv4 to IPv6 with my two- 
>> way
>> friend by comparing it to moving from 25kHz channels to 12.5kHz
>> channels in analog FM (for example),
>
> Yes, but this kind of change in fact WAS made repeatedly in the 2-way
> radio space, within the same spectrum. The situation was quite  
> analogous
> to running out of IPv4 addresses. Instead of expanding the amount of
> spectrum used, specialized mobile radio operators made equipment and
> standards changes to enable more intensive use of existing spectrum.  
> It
> is very similar to using NAT or some other reorg of existing address
> space.
>
Actually, it's a lot closer to adding bits to the size of the address.
Literally, they turned what was one channel into two channels
by creating greater precision in the channel numbering.  The
shift from 25Khz spacing to 12.5Khz spacing was analogous
to adding a single bit to IPv4.

It doubles the number of channels available and requires everyone
to upgrade their equipment.  Yes, these changes have happened
repeatedly.  Usually each change takes 3-5 years and goes along
the lines of:

1.	New channel spacing is allowed, not required.  Old radios still
	work, but, new radios supporting narrower spacing are able
	to be deployed and will interoperate with older radios.

2.	0-2 years later, Announcement: In 3 years, old channel
	spacing will no longer be allowed.

3.	Old channel spacing is made illegal.

It would be interesting to see what would happen if the FCC were
to announce today that IPv6 is the new standard for IP addressing
in the US and IPv4 would no longer be legal to use in 3 years.
I think that the conversion effort required here is a bit more expensive
than that required to swap out two-way radio equipment, so, I think
it would cause substantial problems.

I think IPv6 is more akin to the move from NTSC to ATSC.  You simply
can't receive NTSC signals with an ATSC tuner or ATSC signals with
an NTSC tuner.  New televisions are, however, dual-stack capable
and come with both ATSC and NTSC tuners.

> Transfers or no transfers, people will be faced with economic  
> incentives
> of that sort.
>
> So, don't assume that if we just shut off IPv4 then everyone will
> migrate to IPv6. Herrin and others have been making the much more
> realistic point that that may not happen. People may just make more
> intensive use of IPv4 via NAT and other techniques.
>
I think that both solutions will end up deployed in the real world.
However, there is a limit to how far you can go with more intensive
use of NAT.  I think that limit actually comes up far shorter than
Herrin and some others do, but, I've yet to see NAT work flawlessly,
so, perhaps I'm too much of a purist and a skeptic.


Owen



From JOHN at egh.com  Fri Sep  5 15:05:47 2008
From: JOHN at egh.com (John Santos)
Date: Fri, 5 Sep 2008 15:05:47 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C13A75.1070109@olp.net>
Message-ID: <1080905143022.13222W-100000@Ives.egh.com>

On Fri, 5 Sep 2008, Dan White wrote:

> Cliff Bedore wrote:
> > I read it and am impressed that you have gone as far as you have. I
> > think you will have to admit you are not a typical CEO in a typical 
> > for-profit company and are probably in the very small minority of 
> > entities who have gone gung ho for IPv6.  As you point out, lots of 
> > people bought Beta video players, HD DVD.  Hell I was a big proponent of 
> > CPM86/Concurrent CPM/86.  It was a much better system than MSDOS but 
> > that didn't make it a success.  And don't get me wrong.  I'm not 
> > particularly anti-IPv6 but it's just NOT happening in most of the 
> > world.  It doesn't seem like we're going to get a disruptive application 
> > for IPv6 so we need another hook to get people to buy in.  The only one 
> > I see is to get IPv6 and IPv4 talking transparently so we don't need 
> > dual stack and people can keep resources that use IPv4 and get to IPv6 
> > as progress and funds allow.  No one wants to go to IPv6 by itself 
> > because there is too much IPv4 they couldn't reach.  Dual stack is a 
> > kludge(IMO).  We need transparent communication between them and without 
> > that, I don't believe IPv6 will take off in my lifetime.
> >
> > Cliff
> >   
> 
> I think there's an implication in this line of reasoning that IPv6 is 
> hard, and that dual stack is bad.
> 
> Dual-stack IPv4/IPv6 is easy. You just enable it in your OS, or perhaps 
> it already is. IPv4 continues to work uninterrupted, dual stack servers 
> are reachable and IPv6 only sites are reachable. I don't really see any 
> downsides to this approach except for inevitable bugs and issues that 
> are bound to pop up with new technology.

I think there are 2 serious issues with this.  1) It doesn't immediately
get you anything (with IPv4 runout) because each dual stacked host
needs *TWO* addresses, an "easily obtainable" IPv6 address and a scarce
IPv4 address.  2) Due to the way IPv6 defaults (apparently this is
defined in the specifications), it tries an IPv6 connection 1st and
then fails back to an IPv4 connection.  If the destination host is IPv4
only, then this isn't much of a problem (the DNS lookup for an IPv6
address will fail, but the originator will find an IPv4 address quickly
and use that, which will just increase connection setup time a bit),
but if the destination is dual-stacked also, but the IPv6 connectivity
isn't there yet, there will be *long* timeout delays while the source
tries to set up a session over IPv6.  Can you imagine the support
calls from people saying "why is it taking me a minute to connect to
google while I can connect to other places right away?"

So it's not that dual-stacking is *bad*, but it just isn't too
helpful until the infrastructure is up to snuff, and you can start
introducing IPv6-only hosts.  But to support existing IPv4-only
hosts, *all* publicly accessible servers will have to be dual-stacked
for the forseeable future.  (Someday, someone at Amazon or similar, or
at one of the major IP transport companies will make an execute decision
that they have to little remaining IPv4 traffic to justfy the support
costs, and will decree "turn it off!", and few people will notice.
Then, based on that precedent, lots of corporate IT departments will
make the same decision, causing a disaster of Y2K proportions, as
they discover all the little DOS boxes and PDP-11's running the
steel mill are IPv4-only and don't work with the new routers.  :-)



> 
> Of course, this is an overly simplistic scenario, but my point is that 
> it's supposed to be easy for customers. It's not their job to worry 
> about all the network engineering involved to make this happen. As a 
> service provider, or network manager, it's your job, in my opinion, to 
> engineer the network to support easy access to IPv6 and to figure out 
> all the hard stuff for the benefit of your users. If engineered 
> correctly, IPv6 deployment should be nearly unnoticeable to the majority 
> of typical Web/Email users.

I'm not a service provider, so I guess I don't have to do anything ;-)
However, at least one of our customers has asked about IPv6 on their
internal network, with the implication that they want it soon.  (We
supply database management systems to the Telecom industry, and this
customer has a bunch of our systems.)  Since they are also a major ISP,
I think that would be of interest to the people who are asking what the
big ISPs are doing about IPv6, but I don't know if this is public
knowledge, so I can't identify them further.


> 
> Networks are certainly different, and there are many barriers to entry 
> (consumer routers being a big one) but making roll out as easy as 
> possible for service providers, using translators and proxies and such, 
> should not really be our primary goal.
> 
> Also, IPv6 was not designed as a product. It should not really depend on 
> residential demand. It's a protocol designed to address the short 
> comings of IP4 and should be used as a tool to provide better service, 
> or service where it would not be feasible.

I think residential demand is what has driven the exponential growth
of the Internet and is what has caused the IPv4 runout and the need
for IPv6 in the first place?  Does ARIN have anyway of knowing this?
(If ISPs mostly catered to business or mostly to residence, you could
estimate, but I think most ISPs, except the ones selling only T1 or
faster service on dedicated lines, cater to both markets, so you can't
just divided up the allocations into two piles, and I doubt ISPs need
to or would want to provide this information to ARIN when requesing
new allocations.  Direct assignments (PI) are probably almost all to
medium or large businesses or educational users, but I would think they
are actually a very small slice of the pie compared to ISP allocations.)


> 
> - Dan
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From jcurran at istaff.org  Fri Sep  5 15:37:16 2008
From: jcurran at istaff.org (John Curran)
Date: Fri, 5 Sep 2008 15:37:16 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10ACB@mail>
References: <48C01D9B.10400@cjbsys.bdb.com><5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net><7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>
	<0EB47134-25C5-4AA8-BBDC-23EE719E9C19@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10ACB@mail>
Message-ID: <71D959B2-07AA-40F5-B6AD-EE1DB6A136EB@istaff.org>

On Sep 5, 2008, at 2:22 PM, Kevin Kargel wrote:
> The industry that we are in is more than a business, we have direct  
> impact
> on society and quality of life, and thereby we have more than normal
> responsibility to safeguard the public interest (Use the power wisely,
> Luke)..  Our decisions cannot be based entirely on business and  
> bottom line.
>
> I am a median line capitalist, and I do believe that capitalistic  
> drivers
> are good and necessary for shaping business.  Having said that it is
> expressly the cooperative anarchy that has let the internet develop  
> into the
> wonderful and functional entity that it is.  Without the free thinking
> methods of open source and the tremendous works of organizions such  
> as ARIN
> the various standards bodies the Internet would not have evolved  
> into the
> amazing thing we have today.

Kevin -

    I'm not advocating for (or against) a more relaxed
    transfer policy, but I'm wondering if you have an
    alternative suggestion on how to best encourage
    existing legacy holders that have some address
    space which could be freed up with significant
    effort to undertake the task?   Some of the
    suggestions to date have been a relaxed transfer
    policy, asking nicely and thanking them loudly,
    government intervention, or giving up completely
    since it may only provide us a few more years of
    IPv4 block general availability.

    Are you thinking that a relaxed transfer policy
    isn't needed, or just that it isn't worth the
    potential consequences?

/John
(solely responsibility for the above thoughts and
those photons emitted from displays as a result)


From dwhite at olp.net  Fri Sep  5 15:51:15 2008
From: dwhite at olp.net (Dan White)
Date: Fri, 05 Sep 2008 14:51:15 -0500
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <1080905143022.13222W-100000@Ives.egh.com>
References: <1080905143022.13222W-100000@Ives.egh.com>
Message-ID: <48C18DB3.4080407@olp.net>

John Santos wrote:
> On Fri, 5 Sep 2008, Dan White wrote:
>   
>> I think there's an implication in this line of reasoning that IPv6 is 
>> hard, and that dual stack is bad.
>>     
> I think there are 2 serious issues with this.  1) It doesn't immediately
> get you anything (with IPv4 runout) because each dual stacked host
> needs *TWO* addresses, an "easily obtainable" IPv6 address and a scarce
> IPv4 address.  

I don't grasp your point. Are you saying that it's a management problem 
of maintaining two addresses? Arguably, there is no end-user maintenance 
of IPv6 addresses (in a dual stack scenario).

> 2) Due to the way IPv6 defaults (apparently this is
> defined in the specifications), it tries an IPv6 connection 1st and
> then fails back to an IPv4 connection.

Not exactly. In the case where a user is visiting a website, the DNS 
resolver will do *one* search for IPv4 and IPv6 addresses for that site 
name. If there are no AAAA records for the site, no harm no foul. If an 
admin is advertising IPv6 services for a hostname that is not 
connectible that's a management issue, not a protocol deficiency.

> So it's not that dual-stacking is *bad*, but it just isn't too
> helpful until the infrastructure is up to snuff, and you can start
> introducing IPv6-only hosts.  But to support existing IPv4-only
> hosts, *all* publicly accessible servers will have to be dual-stacked
> for the forseeable future.

Dual stacking solves the problem of having IPv4 only hosts. It also 
conveniently solves the problem of having IPv6 only hosts. I do 
understand that there's a bit of a chicken and egg problem, but if you 
start dual stacking your hosts, you're at least prepared for what's coming.

- Dan


From JOHN at egh.com  Fri Sep  5 16:23:27 2008
From: JOHN at egh.com (John Santos)
Date: Fri, 5 Sep 2008 16:23:27 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C18DB3.4080407@olp.net>
Message-ID: <1080905160855.13222A-100000@Ives.egh.com>

On Fri, 5 Sep 2008, Dan White wrote:

> John Santos wrote:
> > On Fri, 5 Sep 2008, Dan White wrote:
> >   
> >> I think there's an implication in this line of reasoning that IPv6 is 
> >> hard, and that dual stack is bad.
> >>     
> > I think there are 2 serious issues with this.  1) It doesn't immediately
> > get you anything (with IPv4 runout) because each dual stacked host
> > needs *TWO* addresses, an "easily obtainable" IPv6 address and a scarce
> > IPv4 address.  
> 
> I don't grasp your point. Are you saying that it's a management problem 
> of maintaining two addresses? Arguably, there is no end-user maintenance 
> of IPv6 addresses (in a dual stack scenario).

No!  Go back to basics.  What problem are we trying to solve?
The problem is *not* getting people to adopt IPv6.  The problem is
running out of IPv4 addresses.  IPv6 is a potential *solution* to this
problem, and any difficulties getting people to adopt IPv6 are
secondary problems, not the primary problem.  Dual-stacking does
*not* solve the primary problem, so as a method of IPv6 adoption, it
is only useful if it is temporary or limited in scope.  Universal
dual-stack is not limited in scope, so it must be limited in time or
it doesn't solve the problem.  (That said, I think dual-stacking is
necessary for limited scope (i.e. servers), and might be a good 1st
step toward IPv6 adoption, but it has to be achieved *before* IPv4
runout, or we still hit the wall.  And once it has been acheived,
it is no longer necessary!  Because if everything accessible via
IPv4 is also accessible via IPv6, IPv4 can be shut off with no loss
of connectivity.)

> 
> > 2) Due to the way IPv6 defaults (apparently this is
> > defined in the specifications), it tries an IPv6 connection 1st and
> > then fails back to an IPv4 connection.
> 
> Not exactly. In the case where a user is visiting a website, the DNS 
> resolver will do *one* search for IPv4 and IPv6 addresses for that site 
> name. If there are no AAAA records for the site, no harm no foul. If an 
> admin is advertising IPv6 services for a hostname that is not 
> connectible that's a management issue, not a protocol deficiency.

The end site might have a perfectly configured IPv6 network and it's
upstream may be perfectly configured, and so might my network and my
upstream, but if something in between is *not* IPv6, I'll still
encounter this problem.

> 
> > So it's not that dual-stacking is *bad*, but it just isn't too
> > helpful until the infrastructure is up to snuff, and you can start
> > introducing IPv6-only hosts.  But to support existing IPv4-only
> > hosts, *all* publicly accessible servers will have to be dual-stacked
> > for the forseeable future.
> 
> Dual stacking solves the problem of having IPv4 only hosts. It also 
> conveniently solves the problem of having IPv6 only hosts. I do 
> understand that there's a bit of a chicken and egg problem, but if you 
> start dual stacking your hosts, you're at least prepared for what's coming.
> 
> - Dan
> 
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From kkargel at polartel.com  Fri Sep  5 16:46:20 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 5 Sep 2008 15:46:20 -0500
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <71D959B2-07AA-40F5-B6AD-EE1DB6A136EB@istaff.org>
References: <48C01D9B.10400@cjbsys.bdb.com><5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net><7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>
	<0EB47134-25C5-4AA8-BBDC-23EE719E9C19@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10ACB@mail>
	<71D959B2-07AA-40F5-B6AD-EE1DB6A136EB@istaff.org>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10ACF@mail>

Inlines by Kevin Kargel --  

> On Sep 5, 2008, at 2:22 PM, Kevin Kargel wrote:
> > The industry that we are in is more than a business, we have direct 
> > impact on society and quality of life, and thereby we have 
> more than 
> > normal responsibility to safeguard the public interest (Use 
> the power 
> > wisely, Luke)..  Our decisions cannot be based entirely on business 
> > and bottom line.
> >
> > I am a median line capitalist, and I do believe that capitalistic 
> > drivers are good and necessary for shaping business.  
> Having said that 
> > it is expressly the cooperative anarchy that has let the internet 
> > develop into the wonderful and functional entity that it 
> is.  Without 
> > the free thinking methods of open source and the tremendous 
> works of 
> > organizions such as ARIN the various standards bodies the Internet 
> > would not have evolved into the amazing thing we have today.
> 
> Kevin -
> 
>     I'm not advocating for (or against) a more relaxed
>     transfer policy, but I'm wondering if you have an
>     alternative suggestion on how to best encourage
>     existing legacy holders that have some address
>     space which could be freed up with significant
>     effort to undertake the task?   Some of the

First off, I do not accept the desperate need to force legacy holders to
give up any space.  This would not change anything, would not provide a
solution, and would only forstall the inevitable so that the rest of us can
procrastinate in dealing with the problem.  I do not even believe that the
time gained would be critical or necessary to arriving at the solution.

Attacking the legacy holders because they continue to hold what was freely
given them when we didn't think we needed it is nothing short of mob action.
We have explained the need to them, I think they understand it, and I trust
they will have the community spirit and compassion to respond when it is
needed if we allow them an easy path to keep what they require to meet their
own needs.  People tend to do what is good when given a choice, but if I am
presented with an ultimatum I have been known to pridefully spite a noseless
face. I don't expect the legacy holders to be any different.

I hope and believe that we have evolved past the point that our best
recourse is strongarm police actions.

BTW, I am not - nor (to my knowledge) have I been - a legacy holder. I hold
no office or interest in ARIN other than as a common member and I aspire to
no office.


>     suggestions to date have been a relaxed transfer
>     policy, asking nicely and thanking them loudly,
>     government intervention, or giving up completely
>     since it may only provide us a few more years of
>     IPv4 block general availability.

I think we should do nothing more than encourage and support our peers,
offer assistance and education and resources, allow the community to exhaust
IPv4 space under current rules, begin to use IPv6 space, and we will arrive
at the same place at the same time but we will have taken a different but
more ethical route.  

Network administrators are over-worked understaffed people who tend to be
crisis driven and do not have a lot of choice about which issues they can
tackle this week.  I hope that they are taking IPv6 in to account (I know I
do) when planning hardware upgrades.  I believe that the majority of network
administrators are talented ethical people who will do what they can when
they can and that the problem will be dealt with in the nick of time.  There
will be enough forward thinking industry leaders to create a wave front for
the rest to ride on. (As an aside, good network administrators have more
than a normal quantity of ego and *like* to be known as edge leaders.)

We can and should expect legacy holders to update their contact information
to allow better response to malicious or otherwise negative network traffic.
I do not think we should or have any right to demand additional or punative
recompense in excess of current agreements (or lack thereof) for this
action.  A side effect(it should not be the primary driver) is that we can
identify and reclaim abandoned space based on the lack of response.

> 
>     Are you thinking that a relaxed transfer policy
>     isn't needed, or just that it isn't worth the
>     potential consequences?

I strongly feel that the side effects of a transfer policy are so
detrimental to the community and to society as to greatly outweigh any
benefits.  

> 
> /John
> (solely responsibility for the above thoughts and those 
> photons emitted from displays as a result)
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080905/4568adae/attachment.bin>

From dwhite at olp.net  Fri Sep  5 17:11:17 2008
From: dwhite at olp.net (Dan White)
Date: Fri, 05 Sep 2008 16:11:17 -0500
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <1080905160855.13222A-100000@Ives.egh.com>
References: <1080905160855.13222A-100000@Ives.egh.com>
Message-ID: <48C1A075.4030003@olp.net>

John Santos wrote:
> On Fri, 5 Sep 2008, Dan White wrote:
>
>   
> No!  Go back to basics.  What problem are we trying to solve?
> The problem is *not* getting people to adopt IPv6.  The problem is
> running out of IPv4 addresses.  

I reject that claim. IPv4 depletion is *one* reason to move to IPv6, but 
certainly not the only one. The goal is to facilitate customers' needs. 
A service provider needs to anticipate those needs without really caring 
about how customers use their networks. I like IPv6, it has a lot of 
good things going for it, but I don't feel it's my place to advocate 
it's usage to my customers, even in the face of IPv4 depletion. IPv6 
usage is not going to be uniform. There are, and will be many, 
legitimate uses of IPv6 before IPv4 run out. I fully expect new devices, 
such as handhelds, to really drive IPv6 adoption.

>> Not exactly. In the case where a user is visiting a website, the DNS 
>> resolver will do *one* search for IPv4 and IPv6 addresses for that site 
>> name. If there are no AAAA records for the site, no harm no foul. If an 
>> admin is advertising IPv6 services for a hostname that is not 
>> connectible that's a management issue, not a protocol deficiency.
>>     
>
> The end site might have a perfectly configured IPv6 network and it's
> upstream may be perfectly configured, and so might my network and my
> upstream, but if something in between is *not* IPv6, I'll still
> encounter this problem.
>
>   

You could say the same thing about IPv4 connectivity. It's somebody's 
job to keep the internet cogs churning.

- Dan




From dwhite at olp.net  Fri Sep  5 18:08:07 2008
From: dwhite at olp.net (Dan White)
Date: Fri, 05 Sep 2008 17:08:07 -0500
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <4DF78E3C-7F0D-4F7E-843B-FADDF94E8746@delong.com>
References: <1080905143022.13222W-100000@Ives.egh.com>
	<48C18DB3.4080407@olp.net>
	<4DF78E3C-7F0D-4F7E-843B-FADDF94E8746@delong.com>
Message-ID: <48C1ADC7.8070005@olp.net>

Owen DeLong wrote:
>>
>> I don't grasp your point. Are you saying that it's a management problem
>> of maintaining two addresses? Arguably, there is no end-user maintenance
>> of IPv6 addresses (in a dual stack scenario).
>>
> No... He's saying that the inability for an IPv6 only host to talk to 
> hosts
> which don't yet have IPv6 makes it a less than useful solution until
> EVERY IPv4 accessible resource also has an IPv6 accessible address.

One doesn't follow the other. It's short sighted to view the network 
world in terms of the desktop computer. Specialized devices are a 
scenario where IPv6 makes sense. Not all the world's computers need to 
have IPv6 connectivity for me to want one.

>
> Additionally, until there are meaningful things you can get to via IPv6
> that you cannot reach via IPv4, there's little incentive to people that
> have IPv4 to add IPv6 capabilities.

I can get to my network over IPv6 today. That's meaningful to me. For 
the sake of argument, it doesn't matter that I also have IPv4 access. I 
can serve ISP services today to IPv6 only hosts.

>
> IOW, if you have an IPv6 enabled interface in an environment that
> lacks IPv6 connectivity, things bog down.
>
> No big deal, you say? Well, makes it a pain for notebooks that
> move in and out of IPv6 enabled worlds.

That's certainly a valid point.

 >> Dual stacking solves the problem of having IPv4 only hosts. It also
>> conveniently solves the problem of having IPv6 only hosts. I do
>> understand that there's a bit of a chicken and egg problem, but if you
>> start dual stacking your hosts, you're at least prepared for what's 
>> coming.
> It doesn't actually solve either problem.

I guess I'll have to disagree with you there.

- Dan


From jcurran at istaff.org  Fri Sep  5 20:56:48 2008
From: jcurran at istaff.org (John Curran)
Date: Fri, 5 Sep 2008 20:56:48 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
	Services Agreement (LRSA)
Message-ID: <644F81FC-422B-4646-B407-4FD8E41C39B8@istaff.org>

As the LRSA has been a topic of recent conversation, I figured it would
be appropriate to point out that a new version (2.0) was released today.
More information on the changes to the LRSA can be found here:
      <http://www.arin.net/announcements/20080905.html>

FYI,
/John

John Curran
Chair, ARIN Board of Trustees


From lear at cisco.com  Sat Sep  6 01:29:05 2008
From: lear at cisco.com (Eliot Lear)
Date: Sat, 06 Sep 2008 07:29:05 +0200
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C175C1.6070309@Dilkie.com>
References: <48C01D9B.10400@cjbsys.bdb.com>	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>	<7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>	<BCE06A01-31D5-4EB9-9110-0697FE1D4C1F@kanren.net>	<7663C7E01D8E094989CA62F0B0D21CD901E0E69D@SUEXCL-02.ad.syr.edu>
	<48C175C1.6070309@Dilkie.com>
Message-ID: <48C21521.6040708@cisco.com>

Lee Dilkie wrote:
> I don't think the analogy is at all correct.
>
> Radio spectrum has a physical hard limit and there is no substitution
> (until subspace radio is invented). So obviously the effort has *always*
> been to improve utilization of a fixed resource. I see no reason why
> this won't continue.
>    

I don't believe we can say that IPv6 is a substitutable resource for 
IPv4 at this point in time.  IPv6 addresses gain you access to very few 
destinations today.

Eliot



From Lee at dilkie.com  Sat Sep  6 11:12:53 2008
From: Lee at dilkie.com (Lee Dilkie)
Date: Sat, 06 Sep 2008 11:12:53 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C21521.6040708@cisco.com>
References: <48C01D9B.10400@cjbsys.bdb.com>	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>	<7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>	<BCE06A01-31D5-4EB9-9110-0697FE1D4C1F@kanren.net>	<7663C7E01D8E094989CA62F0B0D21CD901E0E69D@SUEXCL-02.ad.syr.edu>	<48C175C1.6070309@Dilkie.com>
	<48C21521.6040708@cisco.com>
Message-ID: <48C29DF5.5070808@dilkie.com>


Eliot Lear wrote:
> Lee Dilkie wrote:
>   
>> I don't think the analogy is at all correct.
>>
>> Radio spectrum has a physical hard limit and there is no substitution
>> (until subspace radio is invented). So obviously the effort has *always*
>> been to improve utilization of a fixed resource. I see no reason why
>> this won't continue.
>>    
>>     
>
> I don't believe we can say that IPv6 is a substitutable resource for 
> IPv4 at this point in time.  IPv6 addresses gain you access to very few 
> destinations today.
>
> Eliot
>   
As I said, the analogy is somewhat flawed. However, the move from HF to
VHF could be considered similar. In the early days, when the HF band was
filling up, the only options were to squeeze everyone closer together in
HF (improve utilization) or move to the unused VHF spectrum. where you
had to pioneer new radio technology (somewhat like our IPv6) and deal
with totally different radio propagation characteristics (no analogue to
our situation).

The same process has been repeated many times, the move to UHF and
higher. But analogy breaks down in several ways. First, moving to a new
spectrum affects your radio propagation characteristics (HF can
communicate over long distances, beyond the horizon, VHF and above is
line-of-sight, HF has limited bandwidth, VHF has much more). We don't
have this issue, IPv6 runs on the same physical medium as IPv4, with no
more or less bandwidth available to it. Second, radio applications often
tie applications to modulation techniques, essentially blurring the
lines between layers, as the band they operate in determines the
bandwidth that can be used. For example, slow-scan TV on HF, fast-scan
TV on VHF (and UHF) and high-def  TV on V/UHF (although hi-def also
benefits from the efficiency gained in compression so can operate in
spectrum that technically wouldn't support uncompressed). For the most
part, our networked applications are very much isolated from networking
transport details (IPv4 vs 6). So we *should* be able to move networked
applications to IPv6 fairly easily.

But all that really beside the point.

IPv6 is moving forward, applications are slowing being written to
support it, networks are slowing upgrading. It will be a viable
alternative to the other effort, namely more efficient utilization of
existing IPv4 space.

None of this is going to happen overnight, just as the internet won't
come to a crashing halt after the last IPv4 address is given out. This
will all work out just fine in the end, and frankly, we're lucky as hell
that all our existing networked applications have such an easy
transition as they do to migrate to IPv6. Plus, we're even more blessed
that dual-stack exists and we can network into both address spaces at
the same time from the same host.

In the words of Douglas Adams, "don't panic".

It is largely for these reasons that I don't support a transfer policy.
For one, I'm not all convinced that the radio spectrum auctions have
actually proven to be good. Sure, the companies with the most bucks won
and the government got billions, but some of the deployments have not
been so smooth. In some cases the cost of buying the spectrum has
hampered the business case for the network, either by driving up the end
consumer costs (after all, it's the end user who pays for all business
costs) so much that demand isn't there, or by taking too much capital
out of the infrastructure deployment. Either way, I don't see a
liberalized transfer policy as benefiting anyone but big business at the
expense of everyone else.

To put it simply. I hate derivative markets. If you want to run a public
network, purchase your ip addresses from ARIN at a fixed price (for
everyone), don't start buying and selling addresses on the "open"
market. Because what I worry will end up happening is a market with
folks that hold addresses, to buy and sell, but don't operate networks.

-lee






From cliffb at cjbsys.bdb.com  Sat Sep  6 13:35:09 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Sat, 06 Sep 2008 13:35:09 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <73B3F4FB-6922-47E9-B3FD-CA8B86AB0749@muada.com>
References: <48C01D9B.10400@cjbsys.bdb.com>
	<73B3F4FB-6922-47E9-B3FD-CA8B86AB0749@muada.com>
Message-ID: <48C2BF4D.4040507@cjbsys.bdb.com>

Iljitsch van Beijnum wrote:
> On 4 sep 2008, at 19:40, Cliff Bedore wrote:
>
>> Having been reading this group for approaching a year or so now, I think
>> I've seen the problem with adopting IPv6.  Nobody really wants it.
>
> I don't think that's true.
>
> Most people don't know enough to either want it or not want it. Of the 
> people who know, I'm pretty sure a decent number want it, but the 
> trouble is that if you're the only one running IPv6, it doesn't do 
> much for you. Other people have to run it, too.
>
> As someone how used to configure routers for a living, I want IPv6, 
> because it makes my former job easier. (But few people configure 
> routers, let alone for a living.)

OK Let's say there's great apathy for IPv6.  Based on adoption rates, 
those in a position to "make it happen" don't care enough to make it 
happen. (Don't care can be taken to mean "won't spend the money" in many 
cases.)
>
>> The problem:  There is no compatibility bit in IPv6 that says I'm just
>> like IPv4 but I have 96 more address bits.
>
> Although it doesn't seem like it, the current situation is as good as 
> it gets. For the details:
>
> http://www.bgpexpert.com/article.php?article=106
>
>> The backbone for the Internet will have to
>> be IPv6, DNS will have to be IPv6
>
> Not a problem. I already get 10 - 20 % IPv6 hits on my DNS server and 
> 25 - 50 % of the big backbone networks have some kind of IPv6 running 
> today.

I'm saying no more IPv4 backbone anywhere.
>
>> and IPv4 will be treated as IPv6 on
>> the Internet and translated through the "converter box (CB)".  This
>> means that the CB will have to do both translation and DNS lookups for
>> the v4 hosts.
>
> I'm not sure what you have in mind. The problem is that at some point 
> within the next years, there won't be enough IPv4 addresses to 
> continue current practices. So ISPs will have to figure out a way to 
> connect new customers without being able to give these customers their 
> own address. NAT can solve the immediate problem, but you can't slice 
> and dice public IPv4 addresses forever by adding more NATs.

If at this point, we had the conversion boxes (CBs), there would be no 
further need for IPv4 addresses.  All new addresses would be IPv6.  I 
would have IPv6 addresses issued to me that the outside world would 
point to.  The conversion box would do a one-to-one conversion of my 
outside IPv6 addresses to my IPv4 inside addresses   To the outside 
world, I would be running IPv6.  The big ISPs would have gazillions of 
IPv6 addresses (remember those 128 bits) that could reach my IPv4 web 
page through the CB. They would also have lots of IPv6 address space to 
provide the same one-to-one mapping of IPv6 to IPv4 addresses for their 
existing customers if they needed it..  In this scenario, I would expect 
that organizations like Google, Yahoo, eBay etc would have IPV6 
addresses so all those Comcast, Cox, Charter, ATT and other ISP's 
customers can get to them directly and to me through my CB.
>
> So at some point end-users will gradually have to start running IPv6. 
> At that point, translation becomes useful because these people can 
> then talk to people who are still IPv4-only. But translation in and of 
> itself doesn't solve anything, and it also incorporates NAT so most of 
> the downsides of IPv4 NAT are still there.

NAT as a method of saving addresses would go away.
>
>> Since there are 64 bits per subnet in IPv6, there will
>> never be a subnet that can't split off IPv4 addresses through the CB for
>> translation.
>
> Not sure what you mean and no idea what CB is. (Citizen's band?)

As defined in the original email and above, it is the conversion box (or 
translator) that does the one-to one mapping of IPv6 to IPv4.

>
>
>> That's a short summary of a big problem but I think it's obvious that
>> there has been little real adoption of IPv6.
>
> We don't need IPv6 today. So the fact that we don't see IPv6 today 
> doesn't mean all that much. There's still time.
>
>> We really need a program
>> that accomplishes what the US HDTV program did.  Tell people that "on
>> MM/DD/YY, the Internet backbone will be IPv6 only.  If you want to run
>> IPv4, you will need one(or more) of the converter boxes for your IPv4
>> addresses.  If you don't do this, you will lose Internet connectivity"
>
> Ah, but our technology is much more advanced than that. Unlike digital 
> TV (which may or may not be HD) versus analog TV, we can run both IP 
> versions side by side, and even when IPv4 runs out of steam because of 
> lack of addresses, the people who already have an address can keep 
> using it.

As they can in mine but my proposal doesn't require dual stacking
>
>> 1.  All IPv4 space effectively becomes PI space since you can tuck your
>> IPv4 into any IPv6 subnet
>
> Unfortunately, this only works in the outgoing direction. In other 
> words: you can put hundreds or thousands of clients behind a single 
> public IPv4 address and translate from their public IPv6 address or 
> private IPv4 address to that public address when they initiate an 
> outgoing session, but receiving incoming sessions is much harder: then 
> the translator needs to know how to map the sessions and the rest of 
> the world needs to know which port number to use (no "80 for web, 25 
> for mail" shortcuts).

As per above, we're not address hiding, we're one-to-one translating.  
Every 64 bit subnet can hold 4 billion different copies of the current 
IPv4 space.(I hope I did that math right.)  All we need to do is say 
something like "If the first bit of the subnet is 1, this is really an 
IPv4 address so ignore the next 31 bits and feed the packet to the CB."  
Or just have 2 subnets, one for native IPv6 and one for translated 
IPv4.  As everybody keeps pointing out, IPv6 has lots and lots of 
address space.  Sure it might be a waste to use 64 bits for an IPv4 /24 
but we've effectively done that anyhow with the 64 bit subnet business.

I'm sure that there are companies who are running something on Windows 
98, SCO Xenix or something similar who may not ever want to update to 
IPv6.  The CB lets them talk to the world via IPv6 for as long as they 
need to run that application.

I guess you could do all kinds of things in the CB to tell it which of 
the upper 32 bits of IPv6 subnet space define IPv4 translation requirements.

I had been thinking of the CB as a standalone box but it could certainly 
be part of a router if that's easier.

Another meaning of CB by the way is Cliff Bedore or the last half of my 
ham radio call of W3CB.  So needless to say "Citizens Band" is fighting 
words to us hams. :-)

Cliff Bedore
W3CB



From cliffb at cjbsys.bdb.com  Sat Sep  6 16:11:18 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Sat, 06 Sep 2008 16:11:18 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <141A7D602E144644A1E19F63275BA3D2@changeip.com>
References: <48C01D9B.10400@cjbsys.bdb.com><73B3F4FB-6922-47E9-B3FD-CA8B86AB0749@muada.com>
	<48C2BF4D.4040507@cjbsys.bdb.com>
	<141A7D602E144644A1E19F63275BA3D2@changeip.com>
Message-ID: <48C2E3E6.6050206@cjbsys.bdb.com>

Sam Norris wrote:
>> As defined in the original email and above, it is the conversion box (or
>> translator) that does the one-to one mapping of IPv6 to IPv4.
>
> Thats funny.  How do you plan on mapping 128 bits to 32 bits ?  When 
> you say 'one to one' mapping, that is NAT, and no, there aren't enough 
> addresses to map to every ipv6 address.
I don't.  I map the 32 bits of IPv4 into various 64 bit subnets of IPv6 
around the IPv6 only Internet backbone.  Each current IPv4 user gets 
assigned at least one IPv6 64 bit subnet.  Whatever sized IPv4 they have 
gets mapped to a small section of that 64 bit subnet and the conversion 
box translates the IPv4 from the outside one-to-one to an IPv6 address 
on the IPv6 backbone.  There is no more IPv4 except behind the 
conversion box and the Internet looks like IPv6 only to everyone 
"inside" the net. No tunnels. No NAT (unless someone wants part of the 
IPv4 space "protected" by NAT)

Cliff


From cliffb at cjbsys.bdb.com  Sat Sep  6 17:05:21 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Sat, 6 Sep 2008 17:05:21 -0400 (EDT)
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <644F81FC-422B-4646-B407-4FD8E41C39B8@istaff.org> from "John
	Curran" at Sep 05, 2008 08:56:48 PM
Message-ID: <200809062105.m86L5LTA005771@cjbsys.bdb.com>

> 
> As the LRSA has been a topic of recent conversation, I figured it would
> be appropriate to point out that a new version (2.0) was released today.
> More information on the changes to the LRSA can be found here:
>       <http://www.arin.net/announcements/20080905.html>

As I read it, ARIN still has the option of taking the address space upon
termination. I still consider this a deal breaker.

ARIN needs to decide if it wants good information from legacy holders (and
maybe some financial support) or it wants to get too wrapped up in legalese
and convince people to stay away,

I still think something like my LRSA lite proposal can get the info needed so
the whois and such are up to date and still protects the legacy holders rights
to their addresses.

Cliff


> 
> FYI,
> /John
> 
> John Curran
> Chair, ARIN Board of Trustees
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20740
cliffb at cjbsys.bdb.com http://www.bdb.com
Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/


From jcurran at istaff.org  Sat Sep  6 19:06:47 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 6 Sep 2008 19:06:47 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
Message-ID: <4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>

On Sep 6, 2008, at 5:05 PM, Cliff Bedore wrote:
>>
>> As the LRSA has been a topic of recent conversation, I figured it  
>> would
>> be appropriate to point out that a new version (2.0) was released  
>> today.
>> More information on the changes to the LRSA can be found here:
>>      <http://www.arin.net/announcements/20080905.html>
>
> As I read it, ARIN still has the option of taking the address space  
> upon
> termination. I still consider this a deal breaker.

In the earlier version, there were several circumstances (termination by
holder due to cause, the failure of ARIN to perform due to force  
majeure,
or ARIN's termination for convenience) that could have resulted in the
revocation of the number resources under agreement.  There was ample
community discussion of these situations and need to minimize the the
risk of revocation for those who simply want to come under agreement
and maintain current information.   As a result, this revised version
of the LRSA is now available which eliminates these circumstances or
prevents revocation of included resources should they occur.

There does indeed remain some situations (e.g. on termination by ARIN
due to applicants failure to comply with terms and conditions of the
agreement) which provide for the revocation of the included resources
under agreement, but this is also true of the standard RSA.  It would
be fairly easy to further refine what circumstances (if any) warrant
revocation, but until the community makes that very clear, I personally
don't see how ARIN can completely exclude it from the Legacy RSA.

/John
(I'm Chairman of the ARIN Board of Trustees which was involved in the
  aforementioned revisions to the LRSA, but simply noting my personal
  views on this issue)





From jcurran at istaff.org  Sat Sep  6 21:39:15 2008
From: jcurran at istaff.org (John Curran)
Date: Sat, 6 Sep 2008 21:39:15 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
Message-ID: <B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>

On Sep 6, 2008, at 8:21 PM, Jeremy H. Griffith wrote:
>  ARIN didn't issue these resources.  Duh.


"ARIN didn't issue these resources" is correct, but belies
the complexity of the situation.

The resources have been issued over time through a variety of
registry entities, and in this region, ARIN is the entity
that has been assigned responsibility for administration of
these resources behalf of the community.  You are a part of
this community, so your participation to make the conditions
acceptable is highly valued.

> These half-measures are encouraging in one sense; they show
> some flexibility, rather than the mad-dog punitive mentality
> that has characterized way too much of the discussion about
> legacy issues.  But in another sense, they are discouraging,
> because the best you have come up with is to decrease the
> likelihood of "revocation" of something *you never issued*,
> not to eliminate your threat of that inappropriate action.

It is understandable to be discouraged by the LRSA changes
made to date, *if* you start from the belief that there is
no successor registry with the duty of administration of
these numbering resources in the region.  Others see a
different starting point and hence are encouraged by the
progress.

/John
(personal view)


From mueller at syr.edu  Sat Sep  6 23:03:40 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Sat, 6 Sep 2008 23:03:40 -0400
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C29DF5.5070808@dilkie.com>
References: <48C01D9B.10400@cjbsys.bdb.com>	<5C5581DE-1928-4087-9ADC-1F491A5917F6@kanren.net>	<7663C7E01D8E094989CA62F0B0D21CD902215129@SUEXCL-02.ad.syr.edu>	<BCE06A01-31D5-4EB9-9110-0697FE1D4C1F@kanren.net>	<7663C7E01D8E094989CA62F0B0D21CD901E0E69D@SUEXCL-02.ad.syr.edu>	<48C175C1.6070309@Dilkie.com><48C21521.6040708@cisco.com>
	<48C29DF5.5070808@dilkie.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E6D6@SUEXCL-02.ad.syr.edu>


> -----Original Message-----
> It is largely for these reasons that I don't support a transfer
policy.
> For one, I'm not all convinced that the radio spectrum auctions have
> actually proven to be good.

You're comparing market allocation of a scarce resource to some
idealized - and nonexistent - alternative, an alternative in which it is
assumed that somehow everything miraculously works just the way you
think it ought to. 

What you have to do is compare transfers (or spectrum auctions) with the
REAL policies and practices that preceded them, or that are feasible
alternatives to them. 

The alternative in many spectrum cases were "beauty contests," a.k.a.
comparative hearings, in which applicants hired tons of lawyers and
poured all kinds of flashy documents into an administrative docket and
relentlessly lobbied commissioners and staffers. It was ridiculous and
the FCC knew it. Do you think it was cheap? Do you think it was fair and
unbiased? Do you think anyone could play on equal terms? Wrong.

Can you explain to me why the powerful, wealthy and wired Washington
incumbents "with the most money", such as the broadcasters and Motorola,
were the ones who strongly opposed auctions? Answer was obvious to
anyone in the situation: they knew they had the political clout to get
what they wanted out of the DC machine - for free. The massive spectrum
grant to broadcasters during the DTV transition being a case in point.

The basic fallacy underlying your position is that you are still
comparing contention for a scarce resource with the prior situation, in
which there was RIR allocation of a non-scarce resource. Well, sure, if
a resource isn't scarce it doesn't make a lot of sense to have a
competitive bid for it. But it is scarce. Define a policy that handles
that scarcity, one that works for at least a decade, maybe two. Make a
credible case that it works better than the simple expedient of allowing
party A to transfer unneeded addresses to party B who needs them. Don't
duck the question by talking about IPv6, or by yearning for the good old
days before scarcity existed. Don't try to tell me that organizations
are suddenly going to willingly surrender any address resources they
don't need. Tell me how you will handle that. I'm genuinely interested,
because I've heard a lot of negative comments about markets but not a
whisper about superior methods for handling the address scarcity. 

> Sure, the companies with the most bucks won
> and the government got billions, but some of the deployments have not
> been so smooth. In some cases the cost of buying the spectrum has
> hampered the business case for the network, either by driving up the
end
> consumer costs (after all, it's the end user who pays for all business

So how would you have decided to allocate/assign this spectrum? Cuz if
you say "comparative hearings" I'll respond that it simply was not a
viable option given the scope and scale of the allocations that needed
to be made, and that the contention would have resulted in bribery and
corruption, and discriminatory decisions.

And if you say "lotteries" I'll remind you of the cellular fiasco of the
early 1980s. 

Perhaps you'd say something like, "some very wise people should give the
scarce resource to the very best and most deserving applicants." And of
course that assumes away the whole problem. 

> To put it simply. I hate derivative markets.

...Which tells me that either you're being rhetorical or that you don't
know what a derivative market is. Paying for IP addresses is not a
derivative market or anything close to it. It is no different than
paying for routers or bidding for the best technical people. IP
addresses are an input to the provision of Internet service. I pay for
them, when I hire an ISP. 



From mueller at syr.edu  Sat Sep  6 23:04:31 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Sat, 6 Sep 2008 23:04:31 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy
	RegistrationServices Agreement (LRSA)
In-Reply-To: <644F81FC-422B-4646-B407-4FD8E41C39B8@istaff.org>
References: <644F81FC-422B-4646-B407-4FD8E41C39B8@istaff.org>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E6D7@SUEXCL-02.ad.syr.edu>

Curious, John:
What happens to the folks who signed the earlier version of the LRSA?

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of John Curran
> Sent: Friday, September 05, 2008 8:57 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN releases new version of the Legacy
> RegistrationServices Agreement (LRSA)
> 
> As the LRSA has been a topic of recent conversation, I figured it
would
> be appropriate to point out that a new version (2.0) was released
today.
> More information on the changes to the LRSA can be found here:
>       <http://www.arin.net/announcements/20080905.html>
> 
> FYI,
> /John
> 
> John Curran
> Chair, ARIN Board of Trustees
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From jhg at omsys.com  Sat Sep  6 23:04:18 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Sat, 06 Sep 2008 20:04:18 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
Message-ID: <n3h6c4p7fbvl03v748hg7u8rmdtnpv855p@4ax.com>

On Sat, 6 Sep 2008 19:06:47 -0400, John Curran <jcurran at istaff.org> wrote:

>There does indeed remain some situations (e.g. on termination by ARIN
>due to applicants failure to comply with terms and conditions of the
>agreement) which provide for the revocation of the included resources
>under agreement, 

Yes, and there lies the problem.

>but this is also true of the standard RSA.  

That's irrelevant.  ARIN didn't issue these resources.  Duh.

>It would be fairly easy to further refine what circumstances (if any) 
>warrant revocation, 

IMHO, none at all.  All termination should restore the status quo
as of before the agreement was signed.  That is the *normal* effect
with all other contracts.  This should not be any different.

>but until the community makes that very clear, I personally
>don't see how ARIN can completely exclude it from the Legacy RSA.

Hopefully more of us legacy folks will speak up and encourage
you to do the right thing.  Even if it is like pulling teeth...

These half-measures are encouraging in one sense; they show
some flexibility, rather than the mad-dog punitive mentality
that has characterized way too much of the discussion about
legacy issues.  But in another sense, they are discouraging,
because the best you have come up with is to decrease the 
likelihood of "revocation" of something *you never issued*,
not to eliminate your threat of that inappropriate action.

On Sat, 6 Sep 2008 17:05:21 -0400 (EDT), Cliff Bedore <cliffb at cjbsys.bdb.com> 
wrote:

>ARIN needs to decide if it wants good information from legacy holders (and
>maybe some financial support) or it wants to get too wrapped up in legalese
>and convince people to stay away,

Exactly right.  As Cliff said, you're still offering us a 
dealbreaker.  Too bad.  I was hoping I could sign this one.

--JHG <jhg at omsys.com>


From cgucker at onesc.net  Sat Sep  6 23:18:50 2008
From: cgucker at onesc.net (Charles Gucker)
Date: Sat, 6 Sep 2008 23:18:50 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy
	RegistrationServices Agreement (LRSA)
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E6D7@SUEXCL-02.ad.syr.edu>
References: <644F81FC-422B-4646-B407-4FD8E41C39B8@istaff.org>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E6D7@SUEXCL-02.ad.syr.edu>
Message-ID: <c85424b0809062018q69754e9fn8570f21b759d0363@mail.gmail.com>

On Sat, Sep 6, 2008 at 11:04 PM, Milton L Mueller <mueller at syr.edu> wrote:
> Curious, John:
> What happens to the folks who signed the earlier version of the LRSA?

If you read the last two lines of the URL provided
(http://www.arin.net/announcements/20080905.html), it states:

"Organizations that have signed the LRSA have the option to retain
their existing version or sign Version 2.0 superseding their prior
version."

charles




>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
>> Behalf Of John Curran
>> Sent: Friday, September 05, 2008 8:57 PM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] ARIN releases new version of the Legacy
>> RegistrationServices Agreement (LRSA)
>>
>> As the LRSA has been a topic of recent conversation, I figured it
> would
>> be appropriate to point out that a new version (2.0) was released
> today.
>> More information on the changes to the LRSA can be found here:
>>       <http://www.arin.net/announcements/20080905.html>
>>
>> FYI,
>> /John
>>
>> John Curran
>> Chair, ARIN Board of Trustees
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From jhg at omsys.com  Sat Sep  6 23:36:25 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Sat, 06 Sep 2008 20:36:25 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
Message-ID: <12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>

On Sat, 6 Sep 2008 21:39:15 -0400, John Curran <jcurran at istaff.org> 
wrote:

>It is understandable to be discouraged by the LRSA changes
>made to date, *if* you start from the belief that there is
>no successor registry with the duty of administration of
>these numbering resources in the region.  

That's not where I start from.  I start from the belief that 
a "successor" is necessarily bound to respect the acts of its
"predecessors", which issued the legacy resources under terms
that were very different from those now being offered:

*  No possibility of return on an involuntary basis.
   This was essential to encourage us to do the work
   that led to the current Internet.

*  No fees, even though essentially the same services
   for which fees are now deemed appropriate were in
   existence at that time.

Is ARIN going to respect the terms of our previous contract,
or not?  (The contract does not have to be written to be a
contract, as I hope you know.)  So far, all I see on offer
is take-away, and the reason we are to sign is so that we
do not experience something worse later, presumably also at
ARIN's hands, or at the hands of *its* successor.  There's
a name for that form of encouragement: "extortion".  I am
sure that is not your intent, but that is the precise legal
term for the legacy RSA process as I see it unfolding here.

No offense intended.  Just calling a spade a spade,
and not a ... diamond.  ;-)

>Others see a different starting point and hence are encouraged 
>by the progress.

Well, if you begin with the idea that all legacy resources
should be expropriated, then yes, it is progress.  But if
you want us to join voluntarily, not under vague threats, 
you need to do better.  Mind you, I *want* to join... but
it would be irresponsible of me to do so under the present 
terms.

If I seem a bit testy, I am.  I've been here following the
process for about a year and a half now, and seen amazing
displays of greed, bad faith, categorical insults, and
vitriol, not all directed against legacy assignees (there
seems plenty to go around for all).  I've also seen good,
dedicated, community-minded folks doing their very best to
solve hard problems, and I applaud them.  I just hope that
the second group has more traction than the first.

--JHG <jhg at omsys.com>


From stephen at sprunk.org  Sun Sep  7 00:55:58 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Sat, 06 Sep 2008 23:55:58 -0500
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
Message-ID: <48C35EDE.5070902@sprunk.org>

Jeremy H. Griffith wrote:
> On Sat, 6 Sep 2008 21:39:15 -0400, John Curran <jcurran at istaff.org> 
> wrote:
>   
>> It is understandable to be discouraged by the LRSA changes made to date, *if* you start from the belief that there is no successor registry with the duty of administration of these numbering resources in the region.  
>>     
>
> That's not where I start from.  I start from the belief that a "successor" is necessarily bound to respect the acts of its "predecessors", which issued the legacy resources under terms that were very different from those now being offered:
>
> *  No possibility of return on an involuntary basis.
>    This was essential to encourage us to do the work
>    that led to the current Internet.
>   

There was no statement either way about the basis on which addresses 
were assigned because, at the time, nobody could conceive that we'd 
actually run out of addresses and need any of them back.

> *  No fees, even though essentially the same services
>    for which fees are now deemed appropriate were in
>    existence at that time.
>   

That is because, prior to ARIN's creation, number registration services 
were subsidized by government grants and then domain registration fees 
-- fees that were imposed on domains that had been originally been 
granted on the same unspecified basis as numbers.  Like it or not, there 
_is_ precedent for imposing fees on previously "free" registrations.  
The only reason it hasn't been done in the ARIN region for numbers so 
far (unlike other regions) is that so far the community hasn't chosen to 
impose them.

> Is ARIN going to respect the terms of our previous contract, or not?  (The contract does not have to be written to be a contract, as I hope you know.)  

Even a verbal contract requires that one party receive consideration of 
some sort in return for performing or not performing some act.  You have 
no contract with ARIN, and it would be completely legal for ARIN to stop 
providing registration services to organizations that are not paying for 
them.  Again, the community has so far decided not to do that, and the 
one proposal that went in that direction seems, to me, to have been 
soundly rejected by the very folks you seem to be accusing of trying to 
steal your addresses...

> So far, all I see on offer is take-away, and the reason we are to sign is so that we do not experience something worse later, presumably also at ARIN's hands, or at the hands of *its* successor.  There's a name for that form of encouragement: "extortion".  I am sure that is not your intent, but that is the precise legal term for the legacy RSA process as I see it unfolding here.
>   

While I am not prepared to debate the exact definition of extortion, I 
do not think that any court (or jury) would find that deciding (or even 
threatening) not to provide you services that you did not pay for was 
unlawful.

>> Others see a different starting point and hence are encouraged by the progress.
>>     
>
> Well, if you begin with the idea that all legacy resources should be expropriated, then yes, it is progress.  But if you want us to join voluntarily, not under vague threats, you need to do better.  Mind you, I *want* to join... but it would be irresponsible of me to do so under the present terms.
>   

I don't believe that the LRSA was formed with that idea; I think that 
the standard RSA was used as a template and changes were made to reflect 
the key properties of legacy space.  I will agree that not enough was 
changed, but that's an entirely different matter than claiming ARIN 
wants to "expropriate" all legacy resources (which is not, in fact, 
possible since numbers cannot be property).

> If I seem a bit testy, I am.  I've been here following the process for about a year and a half now, and seen amazing displays of greed, bad faith, categorical insults, and vitriol, not all directed against legacy assignees (there seems plenty to go around for all).  I've also seen good, dedicated, community-minded folks doing their very best to solve hard problems, and I applaud them.  I just hope that the second group has more traction than the first.
>   
I've noticed very little anti-legacy vitriol on PPML; most of it comes 
from the legacy holders themselves and is directed at strawmen that have 
not actually made an appearance.

S


From jcurran at istaff.org  Sun Sep  7 02:20:50 2008
From: jcurran at istaff.org (John Curran)
Date: Sun, 7 Sep 2008 02:20:50 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
Message-ID: <4FFF1468-0D9B-4E8E-9D32-7BEF4590711D@istaff.org>

On Sep 6, 2008, at 11:36 PM, Jeremy H. Griffith wrote:
>
> That's not where I start from.  I start from the belief that
> a "successor" is necessarily bound to respect the acts of its
> "predecessors", which issued the legacy resources under terms
> that were very different from those now being offered:
>
> *  No possibility of return on an involuntary basis.
>   This was essential to encourage us to do the work
>   that led to the current Internet.
>
> *  No fees, even though essentially the same services
>   for which fees are now deemed appropriate were in
>   existence at that time.

Interesting...  You're asserting that these were the terms
under which legacy address assignments were made?  For what
time period and registry do you believe that to have been
the case?

/John






From jcurran at istaff.org  Sun Sep  7 02:48:39 2008
From: jcurran at istaff.org (John Curran)
Date: Sun, 7 Sep 2008 02:48:39 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48C35EDE.5070902@sprunk.org>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C35EDE.5070902@sprunk.org>
Message-ID: <9DF96F31-57B8-4A51-983F-F88D4D091D06@istaff.org>

On Sep 7, 2008, at 12:55 AM, Stephen Sprunk wrote:
> Jeremy H. Griffith wrote:
>>
>> *  No possibility of return on an involuntary basis.
>>   This was essential to encourage us to do the work
>>   that led to the current Internet.
>>
>
> There was no statement either way about the basis on which addresses
> were assigned

Just to be clear, there was such a statement made in 1996 by Jon Postel
(via RFC 2050) that reads "The IANA reserves the right to invalidate any
IP assignments once it is determined the the requirement for the address
space no longer exists."  As the original IANA, Jon certainly knew what
conditions were applicable to existing IP assignments, even if those who
received the assignments did not...

/John
(my opinion alone)



From jhg at omsys.com  Sun Sep  7 02:54:14 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Sat, 06 Sep 2008 23:54:14 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <4FFF1468-0D9B-4E8E-9D32-7BEF4590711D@istaff.org>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<4FFF1468-0D9B-4E8E-9D32-7BEF4590711D@istaff.org>
Message-ID: <t9u6c4dc9gc8nt2r17tnb5r30fri5iqm86@4ax.com>

On Sun, 7 Sep 2008 02:20:50 -0400, John Curran <jcurran at istaff.org> 
wrote:

>On Sep 6, 2008, at 11:36 PM, Jeremy H. Griffith wrote:
>>
>> That's not where I start from.  I start from the belief that
>> a "successor" is necessarily bound to respect the acts of its
>> "predecessors", which issued the legacy resources under terms
>> that were very different from those now being offered:
>>
>> *  No possibility of return on an involuntary basis.
>>   This was essential to encourage us to do the work
>>   that led to the current Internet.
>>
>> *  No fees, even though essentially the same services
>>   for which fees are now deemed appropriate were in
>>   existence at that time.
>
>Interesting...  You're asserting that these were the terms
>under which legacy address assignments were made?  For what
>time period and registry do you believe that to have been
>the case?

I'm going by my best recollection of the rules in effect
at the time I received my assignment, in 1992.  If you
feel you have better information, kindly share it.

--JHG <jhg at omsys.com>


From jcurran at istaff.org  Sun Sep  7 03:41:02 2008
From: jcurran at istaff.org (John Curran)
Date: Sun, 7 Sep 2008 03:41:02 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <t9u6c4dc9gc8nt2r17tnb5r30fri5iqm86@4ax.com>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<4FFF1468-0D9B-4E8E-9D32-7BEF4590711D@istaff.org>
	<t9u6c4dc9gc8nt2r17tnb5r30fri5iqm86@4ax.com>
Message-ID: <CE3CDDC3-3CDC-4C62-8A0B-C344D27446EA@istaff.org>

On Sep 7, 2008, at 2:54 AM, Jeremy H. Griffith wrote:
>
> I'm going by my best recollection of the rules in effect
> at the time I received my assignment, in 1992.  If you
> feel you have better information, kindly share it.

Already done; see prior email regarding IANA's policy on
reclamation in absence of need, and my August 23 posting
regarding ARIN's history and the decision of the USG to
move to an industry-led and industry-funded model for IP
registry services.  To my knowledge, those are the rules
that cover any IP assignment regardless of date of issue.

/John
(personal view)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080907/b8f491b4/attachment.htm>

From jhg at omsys.com  Sun Sep  7 03:56:15 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Sun, 07 Sep 2008 00:56:15 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48C35EDE.5070902@sprunk.org>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C35EDE.5070902@sprunk.org>
Message-ID: <mku6c45m78ke18ol91s81jhjasm0s9rjr6@4ax.com>

On Sat, 06 Sep 2008 23:55:58 -0500, Stephen Sprunk <stephen at sprunk.org> wrote:

>Jeremy H. Griffith wrote:
>> On Sat, 6 Sep 2008 21:39:15 -0400, John Curran <jcurran at istaff.org> 
>> wrote:
>>   
>>> It is understandable to be discouraged by the LRSA changes made to date, *if* you start from the belief that there is no successor registry with the duty of administration of these numbering resources in the region.  
>>>     
>>
>> That's not where I start from.  I start from the belief that a "successor" is necessarily bound to respect the acts of its "predecessors", which issued the legacy resources under terms that were very different from those now being offered:
>>
>> *  No possibility of return on an involuntary basis.
>>    This was essential to encourage us to do the work
>>    that led to the current Internet.
>>   
>
>There was no statement either way about the basis on which addresses 
>were assigned because, at the time, nobody could conceive that we'd 
>actually run out of addresses and need any of them back.

Exactly.  So there was no such return requirement made.

I license software.  If my license does not specify a
time limit, which it does not, it is "in perpetuity"
by default.  If I were to sell the product to another 
company, they could *not* go back to the existing users 
and demand an annual subscription fee, saying that if it 
were not paid, their right to use the software would end.

>> *  No fees, even though essentially the same services
>>    for which fees are now deemed appropriate were in
>>    existence at that time.
>>   
>
>That is because, prior to ARIN's creation, number registration services 
>were subsidized by government grants and then domain registration fees 
>-- fees that were imposed on domains that had been originally been 
>granted on the same unspecified basis as numbers.  Like it or not, there 
>_is_ precedent for imposing fees on previously "free" registrations.  

Yes, and when it was done for domains, I was not happy.
But I went along with it... which may have been a mistake.

If you were making the argument that ARIN was unable to pay
its staff and needed more support, I'd pay happily.  Heck,
I'd donate.  But the last thing the treasurer said about
that was that ARIN had reserves equal to two years' expenses.
He considered that "adequate".  If I had that, I'd consider
it a miracle.  ;-)

>The only reason it hasn't been done in the ARIN region for numbers so 
>far (unlike other regions) is that so far the community hasn't chosen to 
>impose them.

There are limits to what the community can choose to do.
For example, it cannot choose to walk into my office and
take away my hardware on the grounds that it's using the
community network...  I don't think any of us really wants
to have these particular limits, around number assignment, 
determined by the Federal court system, but that would be
the final arbiter if we cannot agree among ourselves.  All
of us.

>> Is ARIN going to respect the terms of our previous contract, or not?  (The contract does not have to be written to be a contract, as I hope you know.)  
>
>Even a verbal contract requires that one party receive consideration of 
>some sort in return for performing or not performing some act.  

Not all considerations are cash.  One condition on the 
original legacy assignment, IIRC, was to keep contact info
current.  I've done that.  And I'd have no problem with
ARIN proceeding to identify those who are no longer at
their contact addresses, and recovering their numbers if
they were unreachable.

>You have no contract with ARIN, and it would be completely legal for 
>ARIN to stop providing registration services to organizations that 
>are not paying for them.  

Would it, now?  Or would it violate ARIN's contract with IANA?

>Again, the community has so far decided not to do that, and the 
>one proposal that went in that direction seems, to me, to have been 
>soundly rejected by the very folks you seem to be accusing of trying to 
>steal your addresses...

I don't think anyone here is "trying to steal addresses",
though it's interesting that you think of them as property
that can be stolen.  I do not.  I think of them as an
assignment made to me in 1992, which I have counted on 
being able to use ever since, as that was the understanding
when they were assigned.

>> So far, all I see on offer is take-away, and the reason we are to sign is so that we do not experience something worse later, presumably also at ARIN's hands, or at the hands of *its* successor.  There's a name for that form of encouragement: "extortion".  I am sure that is not your intent, but that is the precise legal term for the legacy RSA process as I see it unfolding here.
>
>While I am not prepared to debate the exact definition of extortion,

Merriam-Webstr defines "extort" as:
  to obtain from a person by force, intimidation, or undue 
  or illegal power : wring; also : to gain especially by
  ingenuity or compelling argument

  http://www.merriam-webster.com/dictionary/extort

I'd say "intimidation", and to a lesser degree "ingenuity 
or compelling argument", would apply to at least some of 
the arguments in favor of signing the LRSA, wouldn't you?  ;-)

>I do not think that any court (or jury) would find that deciding (or even 
>threatening) not to provide you services that you did not pay for was 
>unlawful.

Very cute.   But rather disingenuous, don't you think?

I presume the "services" I am provided are IP whois and
in-addr, right?  But these services benefit everyone 
*except* the registrant, who already knows who he is.
In fact, they impose a cost on the registrant, that
of processing thousands of spams a day that might not
be arriving if it were not for these services.  The
real beneficiary is the community itself.

That aside, the "threat" is not so much to remove us
from whois, but rather to reassign the numbers we were
assigned 16 years ago to others.  Did you really think 
it wasn't?

>>> Others see a different starting point and hence are encouraged by the progress.
>>
>> Well, if you begin with the idea that all legacy resources should be expropriated, then yes, it is progress.  But if you want us to join voluntarily, not under vague threats, you need to do better.  Mind you, I *want* to join... but it would be irresponsible of me to do so under the present terms.
>
>I don't believe that the LRSA was formed with that idea; I think that 
>the standard RSA was used as a template and changes were made to reflect 
>the key properties of legacy space.  

I agree.  They just didn't go far enough, which is
why I took the time to write in the first place.

>I will agree that not enough was changed, 

Good.

>but that's an entirely different matter than claiming ARIN 
>wants to "expropriate" all legacy resources (which is not, in fact, 
>possible since numbers cannot be property).

I didn't make that claim.  I was merely pointing out
that to consider the current LRSA "progress", you'd
have to have started from a place like that.  I'm
not, because I don't consider it progress.  I consider
it more of the same.

>> If I seem a bit testy, I am.  I've been here following the process for about a year and a half now, and seen amazing displays of greed, bad faith, categorical insults, and vitriol, not all directed against legacy assignees (there seems plenty to go around for all).  I've also seen good, dedicated, community-minded folks doing their very best to solve hard problems, and I applaud them.  I just hope that the second group has more traction than the first.
>>   
>I've noticed very little anti-legacy vitriol on PPML; most of it comes 
>from the legacy holders themselves and is directed at strawmen that have 
>not actually made an appearance.

Oh please.  I don't want to exhume all those dead bodies,
but even in the last month we've been told that the
"elephant in the room" is that those legacy people are 
just waiting to sell their numbers for the highest price
they can get.  When the truth is, I doubt if *any* of us
want to sell them at all... we just want to continue the
"quiet enjoyment" we've had of them all these years.  ;-)

--JHG <jhg at omsys.com>


From jhg at omsys.com  Sun Sep  7 04:26:15 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Sun, 07 Sep 2008 01:26:15 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <CE3CDDC3-3CDC-4C62-8A0B-C344D27446EA@istaff.org>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<4FFF1468-0D9B-4E8E-9D32-7BEF4590711D@istaff.org>
	<t9u6c4dc9gc8nt2r17tnb5r30fri5iqm86@4ax.com>
	<CE3CDDC3-3CDC-4C62-8A0B-C344D27446EA@istaff.org>
Message-ID: <ju27c4dda1qsib7dn70g242kr2s10mi04p@4ax.com>

On Sun, 7 Sep 2008 03:41:02 -0400, John Curran <jcurran at istaff.org> wrote:

>On Sep 7, 2008, at 2:54 AM, Jeremy H. Griffith wrote:
>>
>> I'm going by my best recollection of the rules in effect
>> at the time I received my assignment, in 1992.  If you
>> feel you have better information, kindly share it.
>
>Already done; see prior email regarding IANA's policy on
>reclamation in absence of need, and my August 23 posting
>regarding ARIN's history and the decision of the USG to
>move to an industry-led and industry-funded model for IP
>registry services.  To my knowledge, those are the rules
>that cover any IP assignment regardless of date of issue.

Yes, I read your August 23 post at the time with great interest.
I also read Bill Herrin's reply, which in part said:

>On Sat, 23 Aug 2008 10:40:20 -0400, "William Herrin" <bill at herrin.us> wrote:
>
>>Quite the contrary: the way the legacy registrations were described
>>when made, they were intended to be unique and persist indefinitely,
>>even if the network was never connected to the Internet at large. The
>>sole described mechanism by which addresses could revert to the
>>registry was voluntary return.
>>
>>What's more, the presentations made to gain the community consensus
>>that led to NCR-9218742's amendment 6 repeatedly promised that what
>>came to be known as the legacy registrations would remain untouched by
>>ARIN except to provide whois and rdns services.
>>http://rip.psg.com/~randy/970414.fncac.pdf is was such a presentation,
>>made to the FNC in support of ARIN's formation. See page 9,
>>specifically: "Current and old allocations and their DNS will be
>>maintained with no policy changes"

Your response to the last para was:

>You're right!  That presentation was made after adoption of RFC 2050,
>which specifically calls for invalidation of existing assignments which
>are no longer needed.

In your other post today, you explained the RFC 2050 reference:

>Just to be clear, there was such a statement made in 1996 by Jon Postel
>(via RFC 2050) that reads "The IANA reserves the right to invalidate any
>IP assignments once it is determined the the requirement for the address
>space no longer exists."  As the original IANA, Jon certainly knew what
>conditions were applicable to existing IP assignments, even if those who
>received the assignments did not...

Which brings us to the interesting question, *who* determines
that the "requirement ... no longer exists"?  ARIN, I presume, 
but one could argue the registrant decides, which seemed to be 
Bill's understanding above.

And on what grounds?  Could this clause be used, for example, 
to invalidate any assignment where usage was not 100%?  50%?  
One address?  Whatever ARIN current policy is?  But wait, it
says "no policy changes" in NCR-9218742's amendment 6.  So
does this mean ARIN can never change its policies?  Ouch.

I think you were right on August 23:

>Frankly, I'd rather not think about this, and hope that this
>particular chain of succession remain nothing more than an
>interesting historical tidbit best ignored.
>  ...
>In the end, we have to treat all parties with respect, whether
>they are holding a legacy allocation or one more recent.

Thank you for that.


--JHG <jhg at omsys.com>


From cliffb at cjbsys.bdb.com  Sun Sep  7 08:01:08 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Sun, 7 Sep 2008 08:01:08 -0400 (EDT)
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
Message-ID: <200809071201.m87C18QR012303@cjbsys.bdb.com>

I posted this once before (July 07) but it may be worth looking at again.  I
see no reference to any document about "right to recall", fees, etc etc.  It
just says here's your addresses.  I don't have an AS but my upstream ISP does
and I assume they have permission to connect to the internet. :-)

http://www.bdb.com/~cliffb/bdb_netreg.jpg

Cliff

-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20740
cliffb at cjbsys.bdb.com http://www.bdb.com
Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/


From arin-ppml at westbrook.com  Sun Sep  7 08:50:09 2008
From: arin-ppml at westbrook.com (Eric Westbrook)
Date: Sun, 7 Sep 2008 20:50:09 +0800
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <200809071201.m87C18QR012303@cjbsys.bdb.com>
References: <200809071201.m87C18QR012303@cjbsys.bdb.com>
Message-ID: <6905ba860809070550w61a6bc17tf6e25d709c4a893b@mail.gmail.com>

Here are my most up to date observations, as I try to keep the issues simple
and clear (in my own mind, anyway), then a conclusion:

1.  Many legacy holders (myself included) want to formalize a relationship
with ARIN, and even engage in financial participation;

2.  Many legacy holders (myself included) are reluctant, to put it mildly,
to sacrifice ultimate control of their number resources -- and even more so
to pay for the dubious privilege;

3.  The integrity of whois data and financial support of ARIN seem to be the
community's best fundamental motivations for legacy holder agreements, even
if some would advocate the more controversial purposes of reallocation,
reclamation, or revocation;

4.  All parties have good reasons to discourage the escalation of
disagreements to the level of governmental intervention, especially for
issues that we all should be able to resolve together;

5.  If any legacy holdings are to be seized, the prevailing sentiment seems
to prefer doing so with the unreachable and/or apathetic holders, and not
with the cooperative and participating ones;

6.  Finally, by many if not all accounts, reallocating, reclaiming, and/or
revoking legacy holdings simply isn't likely to ameliorate ipv4 exhaustion
(or ramifications thereof) to any truly significant or meaningful degree.

Given all of these observations taken together, it seems clear to me that
involuntary reallocation, reclamation, and revocation of legacy ipv4 number
resources should be explicitly disavowed in the LRSA for those that sign
it.  The value of bringing such holders into a cooperative relationship for
consideration and participation seems to far outweigh the spoils of any
actual or potential forcible control over the resources.

Thanks again for considering my opinions for discussion.  Corrections of my
misunderstandings, illumination of error in my biases, or contrary
observations, are welcome and encouraged as always.

Best regards,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080907/3c8a6a26/attachment.htm>

From cliffb at cjbsys.bdb.com  Sun Sep  7 09:01:29 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Sun, 07 Sep 2008 09:01:29 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <6905ba860809070550w61a6bc17tf6e25d709c4a893b@mail.gmail.com>
References: <200809071201.m87C18QR012303@cjbsys.bdb.com>
	<6905ba860809070550w61a6bc17tf6e25d709c4a893b@mail.gmail.com>
Message-ID: <48C3D0A9.7010008@cjbsys.bdb.com>

I think this is an excellent summary of where we are.  Kudos to Eric.

Cliff

Eric Westbrook wrote:
> Here are my most up to date observations, as I try to keep the issues 
> simple and clear (in my own mind, anyway), then a conclusion:
>
> 1.  Many legacy holders (myself included) want to formalize a 
> relationship with ARIN, and even engage in financial participation;
>
> 2.  Many legacy holders (myself included) are reluctant, to put it 
> mildly, to sacrifice ultimate control of their number resources -- and 
> even more so to pay for the dubious privilege;
>
> 3.  The integrity of whois data and financial support of ARIN seem to 
> be the community's best fundamental motivations for legacy holder 
> agreements, even if some would advocate the more controversial 
> purposes of reallocation, reclamation, or revocation;
>
> 4.  All parties have good reasons to discourage the escalation of 
> disagreements to the level of governmental intervention, especially 
> for issues that we all should be able to resolve together;
>
> 5.  If any legacy holdings are to be seized, the prevailing sentiment 
> seems to prefer doing so with the unreachable and/or apathetic 
> holders, and not with the cooperative and participating ones;
>
> 6.  Finally, by many if not all accounts, reallocating, reclaiming, 
> and/or revoking legacy holdings simply isn't likely to ameliorate ipv4 
> exhaustion (or ramifications thereof) to any truly significant or 
> meaningful degree.
>
> Given all of these observations taken together, it seems clear to me 
> that involuntary reallocation, reclamation, and revocation of legacy 
> ipv4 number resources should be explicitly disavowed in the LRSA for 
> those that sign it.  The value of bringing such holders into a 
> cooperative relationship for consideration and participation seems to 
> far outweigh the spoils of any actual or potential forcible control 
> over the resources.
>
> Thanks again for considering my opinions for discussion.  Corrections 
> of my misunderstandings, illumination of error in my biases, or 
> contrary observations, are welcome and encouraged as always.
>
> Best regards,
> Eric
> ------------------------------------------------------------------------
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From Lee.Howard at stanleyassociates.com  Sun Sep  7 09:23:26 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Sun, 7 Sep 2008 09:23:26 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <6905ba860809070550w61a6bc17tf6e25d709c4a893b@mail.gmail.com>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6A@CL-S-EX-1.stanleyassociates.com>

> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On Behalf Of Eric Westbrook
> Sent: Sunday, September 07, 2008 8:50 AM
> To: arin ppml
> Subject: Re: [arin-ppml] ARIN releases new version of the Legacy
Registration
	
> 1.  Many legacy holders (myself included) want to formalize a
relationship 
> with ARIN, and even engage in financial participation;

An excellent start.
	
> 2.  Many legacy holders (myself included) are reluctant, to put it 
> mildly, to sacrifice ultimate control of their number resources -- 
> and even more so to pay for the dubious privilege;

I see that.  Can you specify in excrutiating detail what control you
yield?  

Let me put my perspective this way. . . we worked hard to rewrite
the LRSA so that the only circumstances under which you would cede
your addresses to ARIN were under your control.
	
> 3.  The integrity of whois data and financial support of ARIN seem 
> to be the community's best fundamental motivations for legacy holder 
> agreements, even if some would advocate the more controversial
purposes of reallocation, reclamation, or revocation;
	
	4.  All parties have good reasons to discourage the escalation
of disagreements to the level of governmental intervention, especially
for issues that we all should be able to resolve together;
	
	5.  If any legacy holdings are to be seized, the prevailing
sentiment seems to prefer doing so with the unreachable and/or apathetic
holders, and not with the cooperative and participating ones;
	
	6.  Finally, by many if not all accounts, reallocating,
reclaiming, and/or revoking legacy holdings simply isn't likely to
ameliorate ipv4 exhaustion (or ramifications thereof) to any truly
significant or meaningful degree.
	
	Given all of these observations taken together, it seems clear
to me that involuntary reallocation, reclamation, and revocation of
legacy ipv4 number resources should be explicitly disavowed in the LRSA
for those that sign it.  The value of bringing such holders into a
cooperative relationship for consideration and participation seems to
far outweigh the spoils of any actual or potential forcible control over
the resources.
	
	Thanks again for considering my opinions for discussion.
Corrections of my misunderstandings, illumination of error in my biases,
or contrary observations, are welcome and encouraged as always.
	
	Best regards,
	Eric
	



From Lee.Howard at stanleyassociates.com  Sun Sep  7 09:34:16 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Sun, 7 Sep 2008 09:34:16 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6A@CL-S-EX-1.stanleyassociates.com>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6B@CL-S-EX-1.stanleyassociates.com>

Darn Windows (i.e., user fatfinger) sent message before I was ready. 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee
> Sent: Sunday, September 07, 2008 9:23 AM
> To: Eric Westbrook; arin ppml
> Subject: Re: [arin-ppml] ARIN releases new version of the 
> Legacy Registration
> 
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On Behalf Of Eric Westbrook
> > Sent: Sunday, September 07, 2008 8:50 AM
> > To: arin ppml
> > Subject: Re: [arin-ppml] ARIN releases new version of the Legacy
> Registration
> 	
> > 1.  Many legacy holders (myself included) want to formalize a
> relationship 
> > with ARIN, and even engage in financial participation;
> 
> An excellent start.
> 	
> > 2.  Many legacy holders (myself included) are reluctant, to put it 
> > mildly, to sacrifice ultimate control of their number 
> resources -- and 
> > even more so to pay for the dubious privilege;
 
I see that.  Can you specify in excrutiating detail what 
control you yield?  I think you mean that you don't believe
you should be required to release your address space under
any circumstances.  I think the few circumstances remaining
in the LRSA are reasonable; can you list the ones you think
are unfair?
 
Let me put my perspective this way. . . we worked hard to 
rewrite the LRSA so that the only circumstances under which 
you would cede your addresses to ARIN were under your control.

By "we" I mean "that's what I was trying to do."

 	
> 	5.  If any legacy holdings are to be seized, the 
> prevailing sentiment seems to prefer doing so with the 
> unreachable and/or apathetic holders, and not with the 
> cooperative and participating ones;

I'm not sure I've seen that stated explicitly, but that seems
like a reasonable preference.  That would include falling
out of touch/compliance with the LRSA, too (if signed).

> 	6.  Finally, by many if not all accounts, reallocating, 
> reclaiming, and/or revoking legacy holdings simply isn't 
> likely to ameliorate ipv4 exhaustion (or ramifications 
> thereof) to any truly significant or meaningful degree.

I concede that.  That's why I didn't argue that legacy holders
must be able to show utilization (whether under current 
policies, RFC2050, or the policies or use stated at the time
of original assignment).


> Eric

Thank you for your reasonable tone and contribution.

Lee

Disclaimer:  I wrote this, nobody else, and it's entirely possible
that other Board members, ARIN staff, General Counsel, or my wife
will disagree or remember differently.


From cliffb at cjbsys.bdb.com  Sun Sep  7 09:46:26 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Sun, 07 Sep 2008 09:46:26 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
Message-ID: <48C3DB32.6070007@cjbsys.bdb.com>

I'm curious about why the sudden interest in "outreach/reclamation" of 
Legacy addresses.  We made it 10 years or so without it.  As IPv4 runs 
out,are we really trying to push IPv6 or get back enough IPv4 to stumble 
along for some undetermined length of time.

There seems to be one camp that says don't extend IPv4 by any methods.  
This will take us to the nirvana of IPv6 sooner.  A second group seems 
to want to reclaim IPv4 and/or collect fees from us legacy bums.  
Amazingly, several people on this group seem to be on both groups which 
seems kind of bipolar. (or maybe I just can't keep all the names and 
positions correct)

If the intent is to not extend IPv4, there is no need for outreach since 
Legacy space is only IPv4 and it's going to die.

If the intent is to try to reclaim space to extend IPv4 life, I think 
the LRSA is not needed to do it.  ARIN has no need for an agreement with 
Legacy holders to update the contact information and by definition won't 
have an agreement with those it tries to seize due to no contact..  They 
can outreach to the best of their ability and after X months or years, 
can make a claim that the addresses have been abandoned and if someone 
later complains, let the lawyers fight it out.  For those who do 
respond, ARIN can do whatever due diligence it needs to verify that the 
responder has the right to respond and update records as necessary.  
They need to do this with or without an LRSA and once done, they don't 
need the LRSA, they have the info they need for the whois etc.

If the intent is to raise money from Legacy holders, a much less 
restrictive agreement than the current LRSA would be do the job.  Many 
of us are willing to contribute but feel than any agreement that has any 
option of grabbing our addresses to be a deal breaker.

I think Eric Westbrook gave a good summary of where we are but I'm not 
sure I see why it even came up and knowing that might help reach a 
solution that answers that "why do this at all"

Cliff Bedore





From cort at kanren.net  Sun Sep  7 10:04:15 2008
From: cort at kanren.net (Cort Buffington)
Date: Sun, 7 Sep 2008 09:04:15 -0500
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6B@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6B@CL-S-EX-1.stanleyassociates.com>
Message-ID: <FBEEF918-7CFF-4664-892E-70AAAB94DA25@kanren.net>

When I read Eric's post, which is outstanding by the way, I recall  
what my fears were when I read the first LRSA offered to me (I have  
not had time to read the new one yet). The way things were worded make  
me feel kind of like this:

"So this looks pretty good, except all of the language protecting  
ARIN's ability to arbitrarily change the agreement in any way at any  
time."

And the first one did pretty much read that way. It's going to take a  
long, long time to regain my trust. Interestingly enough, I trusted  
ARIN before the one-sided contract and extortive sounding tactics of  
the original LRSA. Whether intended or not, that's the way it came  
across to me.

Cheers,
Cort

On Sep 7, 2008, at 8:34 AM, Howard, W. Lee wrote:

> Darn Windows (i.e., user fatfinger) sent message before I was ready.
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee
>> Sent: Sunday, September 07, 2008 9:23 AM
>> To: Eric Westbrook; arin ppml
>> Subject: Re: [arin-ppml] ARIN releases new version of the
>> Legacy Registration
>>
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>> On Behalf Of Eric Westbrook
>>> Sent: Sunday, September 07, 2008 8:50 AM
>>> To: arin ppml
>>> Subject: Re: [arin-ppml] ARIN releases new version of the Legacy
>> Registration
>> 	
>>> 1.  Many legacy holders (myself included) want to formalize a
>> relationship
>>> with ARIN, and even engage in financial participation;
>>
>> An excellent start.
>> 	
>>> 2.  Many legacy holders (myself included) are reluctant, to put it
>>> mildly, to sacrifice ultimate control of their number
>> resources -- and
>>> even more so to pay for the dubious privilege;
>
> I see that.  Can you specify in excrutiating detail what
> control you yield?  I think you mean that you don't believe
> you should be required to release your address space under
> any circumstances.  I think the few circumstances remaining
> in the LRSA are reasonable; can you list the ones you think
> are unfair?
>
> Let me put my perspective this way. . . we worked hard to
> rewrite the LRSA so that the only circumstances under which
> you would cede your addresses to ARIN were under your control.
>
> By "we" I mean "that's what I was trying to do."
>
> 	
>> 	5.  If any legacy holdings are to be seized, the
>> prevailing sentiment seems to prefer doing so with the
>> unreachable and/or apathetic holders, and not with the
>> cooperative and participating ones;
>
> I'm not sure I've seen that stated explicitly, but that seems
> like a reasonable preference.  That would include falling
> out of touch/compliance with the LRSA, too (if signed).
>
>> 	6.  Finally, by many if not all accounts, reallocating,
>> reclaiming, and/or revoking legacy holdings simply isn't
>> likely to ameliorate ipv4 exhaustion (or ramifications
>> thereof) to any truly significant or meaningful degree.
>
> I concede that.  That's why I didn't argue that legacy holders
> must be able to show utilization (whether under current
> policies, RFC2050, or the policies or use stated at the time
> of original assignment).
>
>
>> Eric
>
> Thank you for your reasonable tone and contribution.
>
> Lee
>
> Disclaimer:  I wrote this, nobody else, and it's entirely possible
> that other Board members, ARIN staff, General Counsel, or my wife
> will disagree or remember differently.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

--
Cort Buffington
Interim Executive Director
The Kansas Research and Education Network
cort at kanren.net
Office: +1-785-856-9800 x301
Mobile: +1-785-865-7206






From cliffb at cjbsys.bdb.com  Sun Sep  7 09:59:44 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Sun, 07 Sep 2008 09:59:44 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6B@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6B@CL-S-EX-1.stanleyassociates.com>
Message-ID: <48C3DE50.9020600@cjbsys.bdb.com>

Howard, W. Lee wrote:
> Darn Windows (i.e., user fatfinger) sent message before I was ready. 
>
>   
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee
>> Sent: Sunday, September 07, 2008 9:23 AM
>> To: Eric Westbrook; arin ppml
>> Subject: Re: [arin-ppml] ARIN releases new version of the 
>> Legacy Registration
>>
>>     
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>>>       
>> On Behalf Of Eric Westbrook
>>     
>>> Sent: Sunday, September 07, 2008 8:50 AM
>>> To: arin ppml
>>> Subject: Re: [arin-ppml] ARIN releases new version of the Legacy
>>>       
>> Registration
>> 	
>>     
>>> 1.  Many legacy holders (myself included) want to formalize a
>>>       
>> relationship 
>>     
>>> with ARIN, and even engage in financial participation;
>>>       
>> An excellent start.
>> 	
>>     
>>> 2.  Many legacy holders (myself included) are reluctant, to put it 
>>> mildly, to sacrifice ultimate control of their number 
>>>       
>> resources -- and 
>>     
>>> even more so to pay for the dubious privilege;
>>>       
>  
> I see that.  Can you specify in excrutiating detail what 
> control you yield?  I think you mean that you don't believe
> you should be required to release your address space under
> any circumstances.  I think the few circumstances remaining
> in the LRSA are reasonable; can you list the ones you think
> are unfair?
>  
> Let me put my perspective this way. . . we worked hard to 
> rewrite the LRSA so that the only circumstances under which 
> you would cede your addresses to ARIN were under your control.
>
> By "we" I mean "that's what I was trying to do."
>   

Again I would point to my LRSA-lite posting of August 23 which contains 
my thoughts on an acceptable agreement.  I don't know if it is in enough 
excruciating detail but it hits all my concerns.  It probably needs some 
legalese but the major points are there.

Cliff
>  	
>   
>> 	5.  If any legacy holdings are to be seized, the 
>> prevailing sentiment seems to prefer doing so with the 
>> unreachable and/or apathetic holders, and not with the 
>> cooperative and participating ones;
>>     
>
> I'm not sure I've seen that stated explicitly, but that seems
> like a reasonable preference.  That would include falling
> out of touch/compliance with the LRSA, too (if signed).
>
>   
>> 	6.  Finally, by many if not all accounts, reallocating, 
>> reclaiming, and/or revoking legacy holdings simply isn't 
>> likely to ameliorate ipv4 exhaustion (or ramifications 
>> thereof) to any truly significant or meaningful degree.
>>     
>
> I concede that.  That's why I didn't argue that legacy holders
> must be able to show utilization (whether under current 
> policies, RFC2050, or the policies or use stated at the time
> of original assignment).
>
>
>   
>> Eric
>>     
>
> Thank you for your reasonable tone and contribution.
>
> Lee
>
> Disclaimer:  I wrote this, nobody else, and it's entirely possible
> that other Board members, ARIN staff, General Counsel, or my wife
> will disagree or remember differently.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>   



From arin-ppml at westbrook.com  Sun Sep  7 12:28:40 2008
From: arin-ppml at westbrook.com (Eric Westbrook)
Date: Mon, 8 Sep 2008 00:28:40 +0800
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <6905ba860809070757o7eb63b67v23eded4771a70791@mail.gmail.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6A@CL-S-EX-1.stanleyassociates.com>
	<369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6B@CL-S-EX-1.stanleyassociates.com>
	<6905ba860809070757o7eb63b67v23eded4771a70791@mail.gmail.com>
Message-ID: <6905ba860809070928p19c57f39p6da62f3e0090e108@mail.gmail.com>

Not sure this went through to the list on the first try, so re-sending.
Please disregard if duplicate.

On Sun, Sep 7, 2008 at 9:34 PM, Howard, W. Lee <
Lee.Howard at stanleyassociates.com> wrote:

> I see that.  Can you specify in excrutiating detail what
> control you yield?  I think you mean that you don't believe
> you should be required to release your address space under
> any circumstances.  I think the few circumstances remaining
> in the LRSA are reasonable; can you list the ones you think
> are unfair?


I'm happy to clarify however I can.  And while I'm admittedly motivated to
protect my own resources, I would like to think I'm speaking to concerns
held by many other legacy holders, in the hopes of championing terms we can
all live with happily and peaceably as a community.

My point on that score is this:  Today, I don't have to worry about
involuntary release.  Perhaps "control" is the wrong term, but that's more
or less what I mean by it.  I'd like to remain unworried about that.  And
I'm willing to participate reasonably (indeed, perhaps generously) to work
for that.

I think I must be confused about what the "few circumstances" to which you
refer are, because they don't seem few to me.  Being bound to current and
future policy, without a release disavowment clause in the LRSA, means that
ARIN policy could change out from under legacy holders in unanticipated
ways, very conceivably resulting in disagreeable involuntary release.


> Let me put my perspective this way. . . we worked hard to
> rewrite the LRSA so that the only circumstances under which
> you would cede your addresses to ARIN were under your control.
>
> By "we" I mean "that's what I was trying to do."


That sentiment reassures me enormously.  So, why not make it explicit?  I
think that a clear statement to that effect in the LRSA, without exceptions
made for future unanticipated policy changes, would go far toward satisfying
even the most skeptical legacy holders (although possibly not the most
penny-pinching).


> >       5.  If any legacy holdings are to be seized, the
> > prevailing sentiment seems to prefer doing so with the
> > unreachable and/or apathetic holders, and not with the
> > cooperative and participating ones;
>
> I'm not sure I've seen that stated explicitly, but that seems
> like a reasonable preference.  That would include falling
> out of touch/compliance with the LRSA, too (if signed).


That seems fair enough to me.


>  >       6.  Finally, by many if not all accounts, reallocating,
> > reclaiming, and/or revoking legacy holdings simply isn't
> > likely to ameliorate ipv4 exhaustion (or ramifications
> > thereof) to any truly significant or meaningful degree.
>
> I concede that.  That's why I didn't argue that legacy holders
> must be able to show utilization (whether under current
> policies, RFC2050, or the policies or use stated at the time
> of original assignment).


Among the points I tried to make, I find this one the most resonant.  If
it's so extremely unlikely to benefit anyone, why insist on it, particularly
when doing so seems to create a barrier to the participation of so many?


> Thank you for your reasonable tone and contribution.


My pleasure.  I thank you for the same, and I also thank you for saying so.

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080908/1fe19ddc/attachment.htm>

From rhw2 at rhwsun.wooten.net  Sun Sep  7 12:43:18 2008
From: rhw2 at rhwsun.wooten.net (Richard Wooten)
Date: Sun, 07 Sep 2008 12:43:18 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <FBEEF918-7CFF-4664-892E-70AAAB94DA25@kanren.net>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6B@CL-S-EX-1.stanleyassociates.com>
	<FBEEF918-7CFF-4664-892E-70AAAB94DA25@kanren.net>
Message-ID: <48C404A6.7050208@rhwsun.wooten.net>

Cort Buffington wrote:

>When I read Eric's post, which is outstanding by the way, I recall  
>what my fears were when I read the first LRSA offered to me (I have  
>not had time to read the new one yet). The way things were worded make  
>me feel kind of like this:
>
>"So this looks pretty good, except all of the language protecting  
>ARIN's ability to arbitrarily change the agreement in any way at any  
>time."
>
>And the first one did pretty much read that way. It's going to take a  
>long, long time to regain my trust. Interestingly enough, I trusted  
>ARIN before the one-sided contract and extortive sounding tactics of  
>the original LRSA. Whether intended or not, that's the way it came  
>across to me.
>
>Cheers,
>Cort
>
>  
>
Cort,

I'll second your statement...


Cheers,
Richard

>On Sep 7, 2008, at 8:34 AM, Howard, W. Lee wrote:
>
>  
>
>>Darn Windows (i.e., user fatfinger) sent message before I was ready.
>>
>>    
>>
>>>-----Original Message-----
>>>From: arin-ppml-bounces at arin.net
>>>[mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee
>>>Sent: Sunday, September 07, 2008 9:23 AM
>>>To: Eric Westbrook; arin ppml
>>>Subject: Re: [arin-ppml] ARIN releases new version of the
>>>Legacy Registration
>>>
>>>      
>>>
>>>>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>>>>        
>>>>
>>>On Behalf Of Eric Westbrook
>>>      
>>>
>>>>Sent: Sunday, September 07, 2008 8:50 AM
>>>>To: arin ppml
>>>>Subject: Re: [arin-ppml] ARIN releases new version of the Legacy
>>>>        
>>>>
>>>Registration
>>>	
>>>      
>>>
>>>>1.  Many legacy holders (myself included) want to formalize a
>>>>        
>>>>
>>>relationship
>>>      
>>>
>>>>with ARIN, and even engage in financial participation;
>>>>        
>>>>
>>>An excellent start.
>>>	
>>>      
>>>
>>>>2.  Many legacy holders (myself included) are reluctant, to put it
>>>>mildly, to sacrifice ultimate control of their number
>>>>        
>>>>
>>>resources -- and
>>>      
>>>
>>>>even more so to pay for the dubious privilege;
>>>>        
>>>>
>>I see that.  Can you specify in excrutiating detail what
>>control you yield?  I think you mean that you don't believe
>>you should be required to release your address space under
>>any circumstances.  I think the few circumstances remaining
>>in the LRSA are reasonable; can you list the ones you think
>>are unfair?
>>
>>Let me put my perspective this way. . . we worked hard to
>>rewrite the LRSA so that the only circumstances under which
>>you would cede your addresses to ARIN were under your control.
>>
>>By "we" I mean "that's what I was trying to do."
>>
>>	
>>    
>>
>>>	5.  If any legacy holdings are to be seized, the
>>>prevailing sentiment seems to prefer doing so with the
>>>unreachable and/or apathetic holders, and not with the
>>>cooperative and participating ones;
>>>      
>>>
>>I'm not sure I've seen that stated explicitly, but that seems
>>like a reasonable preference.  That would include falling
>>out of touch/compliance with the LRSA, too (if signed).
>>
>>    
>>
>>>	6.  Finally, by many if not all accounts, reallocating,
>>>reclaiming, and/or revoking legacy holdings simply isn't
>>>likely to ameliorate ipv4 exhaustion (or ramifications
>>>thereof) to any truly significant or meaningful degree.
>>>      
>>>
>>I concede that.  That's why I didn't argue that legacy holders
>>must be able to show utilization (whether under current
>>policies, RFC2050, or the policies or use stated at the time
>>of original assignment).
>>
>>
>>    
>>
>>>Eric
>>>      
>>>
>>Thank you for your reasonable tone and contribution.
>>
>>Lee
>>
>>Disclaimer:  I wrote this, nobody else, and it's entirely possible
>>that other Board members, ARIN staff, General Counsel, or my wife
>>will disagree or remember differently.
>>_______________________________________________
>>PPML
>>You are receiving this message because you are subscribed to
>>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>Unsubscribe or manage your mailing list subscription at:
>>http://lists.arin.net/mailman/listinfo/arin-ppml
>>Please contact info at arin.net if you experience any issues.
>>
>>    
>>
>
>--
>Cort Buffington
>Interim Executive Director
>The Kansas Research and Education Network
>cort at kanren.net
>Office: +1-785-856-9800 x301
>Mobile: +1-785-865-7206
>
>
>
>
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080907/a66ee3a3/attachment.htm>

From jcurran at istaff.org  Sun Sep  7 13:22:51 2008
From: jcurran at istaff.org (John Curran)
Date: Sun, 7 Sep 2008 13:22:51 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48C3DB32.6070007@cjbsys.bdb.com>
References: <48C3DB32.6070007@cjbsys.bdb.com>
Message-ID: <66D50A73-49AE-418A-B070-FAE3F25F01DF@istaff.org>

On Sep 7, 2008, at 9:46 AM, Cliff Bedore wrote:
>
> I'm curious about why the sudden interest in "outreach/reclamation" of
> Legacy addresses.  We made it 10 years or so without it.

At present, we've got a fairly rational Internet community
which is concerned about the future but still capable of
informed discourse and self-governance.

It's been noted that the relationship/rights/responsibilities
of those address holders who received their space long ago is
not well documented or even generally agreed upon in some cases.
Any documents which do exist are rather sparse on many topics,
including governing policy, applicable low, forum for redress,
etc.

One of the benefits of the Legacy RSA is to try and enshrine
the current situation under a contract which would be both
recognized and provide protection of the status quo to the
extent possible.  To the extent that there is a conflict
between the Legacy RSA and future policies, the LRSA takes
precedence.

There is no particular financial need for the Legacy RSA;
the fees which are set are (as Lee pointed out) minimal
compared to ARIN's overall budget, and were simply set to
provide a level of parity with respect to existing address
space holders and their maintenance fees.

So, if there's no urgent need for the LRSA, why have go
through the work of offering it at all?  My personal
answer is simple:  in several years, it is quite likely
that many more parties other than ARIN will have strong
interest in IPv4 assignments and their pedigree.  While
we cannot predict what other parties might decide that
they need to get involved (e.g. governments, regulators,
multinational policy bodies), there's nearly universal
respect for contracts between parties, such as the LRSA
provides to those holding legacy address space. If having
forthright documentation of your use of the address space
and receipt of association services isn't of value to an
organization, then it should proceed as it has been doing.

/John





From rhw2 at rhwsun.wooten.net  Sun Sep  7 13:29:43 2008
From: rhw2 at rhwsun.wooten.net (Richard Wooten)
Date: Sun, 07 Sep 2008 13:29:43 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <6905ba860809070928p19c57f39p6da62f3e0090e108@mail.gmail.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6A@CL-S-EX-1.stanleyassociates.com>	<369EB04A0951824ABE7D8BAC67AF9BB40B2D2D6B@CL-S-EX-1.stanleyassociates.com>	<6905ba860809070757o7eb63b67v23eded4771a70791@mail.gmail.com>
	<6905ba860809070928p19c57f39p6da62f3e0090e108@mail.gmail.com>
Message-ID: <48C40F87.6070808@rhwsun.wooten.net>

Eric Westbrook wrote:

> Not sure this went through to the list on the first try, so 
> re-sending.  Please disregard if duplicate.
>
> On Sun, Sep 7, 2008 at 9:34 PM, Howard, W. Lee 
> <Lee.Howard at stanleyassociates.com 
> <mailto:Lee.Howard at stanleyassociates.com>> wrote:
>
>     I see that.  Can you specify in excrutiating detail what
>     control you yield?  I think you mean that you don't believe
>     you should be required to release your address space under
>     any circumstances.  I think the few circumstances remaining
>     in the LRSA are reasonable; can you list the ones you think
>     are unfair?
>
>
> I'm happy to clarify however I can.  And while I'm admittedly 
> motivated to protect my own resources, I would like to think I'm 
> speaking to concerns held by many other legacy holders, in the hopes 
> of championing terms we can all live with happily and peaceably as a 
> community.

Eric,

I'm one legacy holder you're also speaking for... I'm in full agreement 
with you.

This can and should be resolved with the ARIN without the Court system 
getting into
the middle, because, we'll both, Legacy holders and the ARIN, end up 
with something
nether of us can live with. 

I think IPv6 is the answer, however as other have, so very well pointed 
out, IPv6 does
have it own set of problems, major ones.

Now, all that said, is IPv4 going away in the next 10 or 15 years?  No 
is not and you
all know that as well as I do.  Let's get pasted all this, and get on 
with making the
internet a safer place to do business.


Cheers,
Richard


>
> My point on that score is this:  Today, I don't have to worry about 
> involuntary release.  Perhaps "control" is the wrong term, but that's 
> more or less what I mean by it.  I'd like to remain unworried about 
> that.  And I'm willing to participate reasonably (indeed, perhaps 
> generously) to work for that.
>
> I think I must be confused about what the "few circumstances" to which 
> you refer are, because they don't seem few to me.  Being bound to 
> current and future policy, without a release disavowment clause in the 
> LRSA, means that ARIN policy could change out from under legacy 
> holders in unanticipated ways, very conceivably resulting in 
> disagreeable involuntary release.
>  
>
>     Let me put my perspective this way. . . we worked hard to
>     rewrite the LRSA so that the only circumstances under which
>     you would cede your addresses to ARIN were under your control.
>
>     By "we" I mean "that's what I was trying to do."
>
>
> That sentiment reassures me enormously.  So, why not make it 
> explicit?  I think that a clear statement to that effect in the LRSA, 
> without exceptions made for future unanticipated policy changes, would 
> go far toward satisfying even the most skeptical legacy holders 
> (although possibly not the most penny-pinching).
>  
>
>     >       5.  If any legacy holdings are to be seized, the
>     > prevailing sentiment seems to prefer doing so with the
>     > unreachable and/or apathetic holders, and not with the
>     > cooperative and participating ones;
>
>     I'm not sure I've seen that stated explicitly, but that seems
>     like a reasonable preference.  That would include falling
>     out of touch/compliance with the LRSA, too (if signed).
>
>
> That seems fair enough to me.
>  
>
>     >       6.  Finally, by many if not all accounts, reallocating,
>     > reclaiming, and/or revoking legacy holdings simply isn't
>     > likely to ameliorate ipv4 exhaustion (or ramifications
>     > thereof) to any truly significant or meaningful degree.
>
>     I concede that.  That's why I didn't argue that legacy holders
>     must be able to show utilization (whether under current
>     policies, RFC2050, or the policies or use stated at the time
>     of original assignment).
>
>
> Among the points I tried to make, I find this one the most resonant.  
> If it's so extremely unlikely to benefit anyone, why insist on it, 
> particularly when doing so seems to create a barrier to the 
> participation of so many?
>  
>
>     Thank you for your reasonable tone and contribution.
>
>
> My pleasure.  I thank you for the same, and I also thank you for 
> saying so.
>
> Eric
>
>------------------------------------------------------------------------
>
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080907/9be145d9/attachment.htm>

From stephen at sprunk.org  Sun Sep  7 13:40:46 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Sun, 07 Sep 2008 12:40:46 -0500
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48C3DB32.6070007@cjbsys.bdb.com>
References: <48C3DB32.6070007@cjbsys.bdb.com>
Message-ID: <48C4121E.2080506@sprunk.org>

Cliff Bedore wrote:
> I'm curious about why the sudden interest in "outreach/reclamation" of Legacy addresses.  We made it 10 years or so without it.  As IPv4 runs out,are we really trying to push IPv6 or get back enough IPv4 to stumble along for some undetermined length of time.
>   

As a co-author of 2007-14, I will say that my "sudden interest" is not 
"sudden" at all; I have always been interested in reclamation, but I was 
unaware until 2007 that ARIN staff* felt that they were not able to 
reclaim space, even from those who had signed an RSA, due to lack of 
specific policy addressing how it should be done and under what 
circumstances.  I was merely trying to correct reality to match my 
long-standing perception.

I feel it is getting more important as we get closer to runout because I 
find it "unfair" that some organizations are holding on to addresses 
they are _not_ using and that, in a few years, will prevent other 
organizations from getting addresses that _will_ be used.  I have no 
interest in taking addresses away from anyone (whether or not they've 
signed an LRSA) who _is_ using their assignments -- and I think 2007-14 
is a reasonable articulation of that stance, though suggestions for 
improvement are always welcome.

While "unfair" is hardly a legal term, I believe that it is a worthwhile 
goal to try to be "fair" to everyone as a matter of good faith and that 
it is also in ARIN's (and the community's) best interests to be as fair 
as possible to preemptively defend against future lawsuits or government 
actions on the basis of claimed restraint of trade, artificial barriers 
to entry, etc.  As much as we may disagree, I'm sure we'd _all_ be less 
happy with _any_ "solution" that lawyers or politicians might come up with.

I do not believe any reclamation effort will meaningfully affect the 
lifetime of IPv4 or the transition to IPv6, nor does that have anything 
to do with my motivation.  Frankly, I hadn't even considered it; I was 
looking at IPv4 in a vacuum.

(* ARIN's counsel says the RSA gives them that power, but whoever 
responded to my ACSP suggestion appears to think that they cannot, or 
should not, exercise that power without policy backing it up.)

> If the intent is to raise money from Legacy holders,

The amount of money to be gained from that is barely significant.  The 
intent is to formalize the relationship, which will authenticate the 
current holder of the resources and keep the contact information 
current, which in turn will prevent spammers from hijacking legacy 
blocks.  However, that authentication costs money, as does upkeep of 
WHOIS, rDNS, and other ARIN systems used to track registrations.  You 
can debate what the fee should be in the other thread on that matter, 
but in general it seems fair that _some_ fee should be paid.

> ... a much less restrictive agreement than the current LRSA would be do the job.  Many of us are willing to contribute but feel than any agreement that has any option of grabbing our addresses to be a deal breaker.
>   

I am sympathetic to that argument; I am still dissatisfied with the 
current LRSA myself, though I am encouraged by the progress made so far.

S


From stephen at sprunk.org  Sun Sep  7 13:56:45 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Sun, 07 Sep 2008 12:56:45 -0500
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <9DF96F31-57B8-4A51-983F-F88D4D091D06@istaff.org>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C35EDE.5070902@sprunk.org>
	<9DF96F31-57B8-4A51-983F-F88D4D091D06@istaff.org>
Message-ID: <48C415DD.9090306@sprunk.org>

John Curran wrote:
> On Sep 7, 2008, at 12:55 AM, Stephen Sprunk wrote:
>> Jeremy H. Griffith wrote:
>>> *  No possibility of return on an involuntary basis.  This was 
>>> essential to encourage us to do the work that led to the current 
>>> Internet.
>>
>> There was no statement either way about the basis on which addresses 
>> were assigned
>
> Just to be clear, there was such a statement made in 1996 by Jon 
> Postel (via RFC 2050) that reads "The IANA reserves the right to 
> invalidate any IP assignments once it is determined the the 
> requirement for the address space no longer exists."  As the original 
> IANA, Jon certainly knew what conditions were applicable to existing 
> IP assignments, even if those who received the assignments did not...

While a case could certainly be made that such a rule applied to 
assignments made after the publication of RFC 2050, I don't see how Jon 
had the legal authority to apply that retroactively.  That he "knew" it 
did is not binding since the other parties arguably did not.

S


From bill at herrin.us  Sun Sep  7 13:58:15 2008
From: bill at herrin.us (William Herrin)
Date: Sun, 7 Sep 2008 13:58:15 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
Message-ID: <3c3e3fca0809071058j2599cd7au953bdd3ad08ea71f@mail.gmail.com>

On Sat, Sep 6, 2008 at 11:36 PM, Jeremy H. Griffith <jhg at omsys.com> wrote:
> That's not where I start from.  I start from the belief that
> a "successor" is necessarily bound to respect the acts of its
> "predecessors", which issued the legacy resources under terms
> that were very different from those now being offered:
>
> *  No possibility of return on an involuntary basis.
>   This was essential to encourage us to do the work
>   that led to the current Internet.
>
> *  No fees, even though essentially the same services
>   for which fees are now deemed appropriate were in
>   existence at that time.

Strictly speaking, there was a third condition: no commercial use.
Unless you got your IP addresses in the short window between 1995 and
1997, the expectation was that you were involved in activities
associated with the government/research/education network. There were
no fees because the government was footing the bill for the good of
the folks connected to that non-commercial network.

Times change and it's appropriate to change with them. That's among
the reasons I have no problem with the proposed fee.

That having been said, the fact that the legacy registrants can to
some extent tell ARIN to go stuff it provides an important check
against some of the more punitive-minded folks in the community. It
would be unfortunate and ultimately destructive to lose that check.


On Sun, Sep 7, 2008 at 9:46 AM, Cliff Bedore <cliffb at cjbsys.bdb.com> wrote:
> I'm curious about why the sudden interest in "outreach/reclamation" of
> Legacy addresses.  We made it 10 years or so without it.  As IPv4 runs
> out,are we really trying to push IPv6 or get back enough IPv4 to stumble
> along for some undetermined length of time.

In three years or so, IPv4 assignment gets really hairy. It would be
helpful for everybody with IP addresses to have well defined flow of
legal authority in place before then to provide a check against the
shall we say less sane ideas for what to do about it.


On Sun, Sep 7, 2008 at 8:50 AM, Eric Westbrook <arin-ppml at westbrook.com> wrote:
> Given all of these observations taken together, it seems clear to me that
> involuntary reallocation, reclamation, and revocation of legacy ipv4 number
> resources should be explicitly disavowed in the LRSA for those that sign
> it.  The value of bringing such holders into a cooperative relationship for
> consideration and participation seems to far outweigh the spoils of any
> actual or potential forcible control over the resources.

Ditto.


Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From farmer at umn.edu  Sun Sep  7 15:10:01 2008
From: farmer at umn.edu (David Farmer)
Date: Sun, 07 Sep 2008 14:10:01 -0500
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>,
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>,
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
Message-ID: <48C3E0B9.16203.4DE5806@farmer.umn.edu>

On 6 Sep 2008 Jeremy H. Griffith wrote:

> That's not where I start from.  I start from the belief that 
> a "successor" is necessarily bound to respect the acts of its
> "predecessors", which issued the legacy resources under terms
> that were very different from those now being offered:
> 
> *  No possibility of return on an involuntary basis.
>    This was essential to encourage us to do the work
>    that led to the current Internet.

Can you support this claim?  

I seriously doubt that anyone thinks someone empowered by the US 
government could or would do anything on terms so absolute as you 
suggest.  At the very least all contracts, verbal, written or implied, have an 
expectation to follow the law and there is a general expectation for parties to 
act in good faith.  

I also agree with you that ARIN is the successor and Legacy holders already 
have an implied contract with ARIN.  Further, in my opinion the point of the 
Legacy RSA is to document and amend that contract to reflect present 
realities. 

Given this, I believe it seems reasonable to expect a written contract to 
explicitly revoke the assignments is cases of illegal acts or acts of bad faith 
(eg violating the terms of the contract).  Additionally, it seems reasonable to 
me that if a legacy holder terminates the contract, and hence the original 
implied contract as well, then you terminate your rights to the resources. 

Above I said "and amend that contract to reflect present realities",  I think 
this cuts both ways.  Depending on when you received your assignments 
there was I believe an expectation of non-commercial use, remember the 
government was funding it.  So are there some terms and conditions that 
are new in the LRSA compared to original expectations?  Are there terms 
and conditions that have been eliminated or changed compared to original 
expectations?  Sure, this is only natural and as I said it cut both ways.  If you 
want the new rights that have evolved over the past 20 years or so, then you 
need to accept the new responsibilities too.

I have said several times, that fundamentally the LRSA is the right thing to 
do, but that doesn't mean that anyone should sign a bad agreement.  I think 
this is good progress and worthy of consideration.  At the very least it 
demonstrates to me that if you present reasonable and specific issues to 
ARIN, they will listen.  This has been slower than my liking, but if you 
consider the conditions have existed for over 10 years then maybe taking it 
slow is the right answer.





=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From jhg at omsys.com  Sun Sep  7 15:33:51 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Sun, 07 Sep 2008 12:33:51 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <6905ba860809070550w61a6bc17tf6e25d709c4a893b@mail.gmail.com>
References: <200809071201.m87C18QR012303@cjbsys.bdb.com>
	<6905ba860809070550w61a6bc17tf6e25d709c4a893b@mail.gmail.com>
Message-ID: <e1b8c493v8ketv8kpaplphrkdjdnujcgct@4ax.com>

On Sun, 7 Sep 2008 20:50:09 +0800, "Eric Westbrook" 
<arin-ppml at westbrook.com> wrote:

>Here are my most up to date observations, as I try to keep the issues simple
>and clear (in my own mind, anyway), then a conclusion:

+1

Excellent summary, thank you!

--JHG <jhg at omsys.com>


From bonomi at mail.r-bonomi.com  Sun Sep  7 16:08:32 2008
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 7 Sep 2008 15:08:32 -0500 (CDT)
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
Message-ID: <200809072008.m87K8WdZ026548@mail.r-bonomi.com>

> From arin-ppml-bounces at arin.net  Sun Sep  7 12:58:22 2008
> Date: Sun, 7 Sep 2008 13:58:15 -0400
> From: "William Herrin" <bill at herrin.us>
> To: "arin ppml" <ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN releases new version of the Legacy Registration
>
> On Sat, Sep 6, 2008 at 11:36 PM, Jeremy H. Griffith <jhg at omsys.com> wrote:
> > That's not where I start from.  I start from the belief that
> > a "successor" is necessarily bound to respect the acts of its
> > "predecessors", which issued the legacy resources under terms
> > that were very different from those now being offered:
> >
> > *  No possibility of return on an involuntary basis.
> >   This was essential to encourage us to do the work
> >   that led to the current Internet.
> >
> > *  No fees, even though essentially the same services
> >   for which fees are now deemed appropriate were in
> >   existence at that time.
>
> Strictly speaking, there was a third condition: no commercial use.
> Unless you got your IP addresses in the short window between 1995 and
> 1997, the expectation was that you were involved in activities
> associated with the government/research/education network. There were
> no fees because the government was footing the bill for the good of
> the folks connected to that non-commercial network.
>
> Times change and it's appropriate to change with them. That's among
> the reasons I have no problem with the proposed fee.
>
> That having been said, the fact that the legacy registrants can to
> some extent tell ARIN to go stuff it provides an important check
> against some of the more punitive-minded folks in the community. It
> would be unfortunate and ultimately destructive to lose that check.
>
>
> On Sun, Sep 7, 2008 at 9:46 AM, Cliff Bedore <cliffb at cjbsys.bdb.com> wrote:
> > I'm curious about why the sudden interest in "outreach/reclamation" of
> > Legacy addresses.  We made it 10 years or so without it.  As IPv4 runs
> > out,are we really trying to push IPv6 or get back enough IPv4 to stumble
> > along for some undetermined length of time.
>
> In three years or so, IPv4 assignment gets really hairy. It would be
> helpful for everybody with IP addresses to have well defined flow of
> legal authority in place before then to provide a check against the
> shall we say less sane ideas for what to do about it.
>
>
> On Sun, Sep 7, 2008 at 8:50 AM, Eric Westbrook <arin-ppml at westbrook.com> wrote:
> > Given all of these observations taken together, it seems clear to me that
> > involuntary reallocation, reclamation, and revocation of legacy ipv4 number
> > resources should be explicitly disavowed in the LRSA for those that sign
> > it.  The value of bringing such holders into a cooperative relationship for
> > consideration and participation seems to far outweigh the spoils of any
> > actual or potential forcible control over the resources.
>
> Ditto.
>
>
> Regards,
> Bill Herrin
>
>
> -- 
> William D. Herrin ................ herrin at dirtside.com bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From bmanning at vacation.karoshi.com  Sun Sep  7 18:17:00 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sun, 7 Sep 2008 22:17:00 +0000
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48C415DD.9090306@sprunk.org>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C35EDE.5070902@sprunk.org>
	<9DF96F31-57B8-4A51-983F-F88D4D091D06@istaff.org>
	<48C415DD.9090306@sprunk.org>
Message-ID: <20080907221700.GA12418@vacation.karoshi.com.>

On Sun, Sep 07, 2008 at 12:56:45PM -0500, Stephen Sprunk wrote:
> John Curran wrote:
> > On Sep 7, 2008, at 12:55 AM, Stephen Sprunk wrote:
> >> Jeremy H. Griffith wrote:
> >>> *  No possibility of return on an involuntary basis.  This was 
> >>> essential to encourage us to do the work that led to the current 
> >>> Internet.
> >>
> >> There was no statement either way about the basis on which addresses 
> >> were assigned
> >
> > Just to be clear, there was such a statement made in 1996 by Jon 
> > Postel (via RFC 2050) that reads "The IANA reserves the right to 
> > invalidate any IP assignments once it is determined the the 
> > requirement for the address space no longer exists."  As the original 
> > IANA, Jon certainly knew what conditions were applicable to existing 
> > IP assignments, even if those who received the assignments did not...
> 
> While a case could certainly be made that such a rule applied to 
> assignments made after the publication of RFC 2050, I don't see how Jon 
> had the legal authority to apply that retroactively.  That he "knew" it 
> did is not binding since the other parties arguably did not.
> 
> S

	As one time member of the IANA team under Jon and the original
head of the reclaimation efforts (we recovered ~30% of the total address pool)
i'd like to clarify what the IANA did to "invalidate any IP assignments once it 
is determined the the requirement for the address space no longer exists."
What we did was:

	) contact the listed resource holder(s)#
	) ask if they were still using the space
	) if so, process any updates they provided
	) if not, markt he space as "fallow" - leaving it usassignable for a period

# in some cases the organization no longer existed, in some cases the contect had died.

	The primary reason for the LRSA, imho, is to ensure that there is an 
understanding between the resource holder(s) and the current registry. I'm all in
favor of retaining the origina terms and conditions, inso far as is feasable/legal
The fact remains that we are temporary users/stewards of the resources and that in
100 years, it is unlikely that either ARIN or any of us will be around to assert rights
under soem previous centurys  half remembered expectations. And given the surprizing 
longevity of IPv4, I think it is prudent to re-sync the understandings btwn registry and
user.

--bill


From jhg at omsys.com  Sun Sep  7 20:14:20 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Sun, 07 Sep 2008 17:14:20 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <20080907221700.GA12418@vacation.karoshi.com.>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C35EDE.5070902@sprunk.org>
	<9DF96F31-57B8-4A51-983F-F88D4D091D06@istaff.org>
	<48C415DD.9090306@sprunk.org>
	<20080907221700.GA12418@vacation.karoshi.com.>
Message-ID: <tbq8c45ul1vu141ib1q4kis84640dd19kp@4ax.com>

On Sun, 7 Sep 2008 22:17:00 +0000, bmanning at vacation.karoshi.com wrote:

>	As one time member of the IANA team under Jon and the original
>head of the reclaimation efforts (we recovered ~30% of the total address pool)
>i'd like to clarify what the IANA did to "invalidate any IP assignments once it 
>is determined the the requirement for the address space no longer exists."
>What we did was:
>
>	) contact the listed resource holder(s)#
>	) ask if they were still using the space
>	) if so, process any updates they provided
>	) if not, markt he space as "fallow" - leaving it usassignable for a period
>
># in some cases the organization no longer existed, in some cases the contect had died.

Thank you!  This means, then, that it was up to the registrant to
determine whether the requirement still existed.  That's what I
thought.  The LRSA should have exactly the same effect.

Could you clarify one other point, please?  IIRC, there was no
requirement for "non-commercial" use at the time I was issued
my Class C, in June 1992.  In fact, my communications about it
were by email, from my domain "omsys.com" (obtained from UUNET
well before that).  So I was clearly not an .org, .edu, or .gov,
but nobody said anything about that.  What was the policy at IANA 
WRT commercial/non-commercial usage at that time?

>	The primary reason for the LRSA, imho, is to ensure that there is an 
>understanding between the resource holder(s) and the current registry. I'm all in
>favor of retaining the origina terms and conditions, inso far as is feasable/legal
>The fact remains that we are temporary users/stewards of the resources and that in
>100 years, it is unlikely that either ARIN or any of us will be around to assert rights
>under soem previous centurys  half remembered expectations. And given the surprizing 
>longevity of IPv4, I think it is prudent to re-sync the understandings btwn registry and
>user.

I agree, which is why I am persisting in trying to move the process
toward an LRSA that all legacy registrants would be comfortable
signing.

I have no problem with *some* fee.  I think $100 is a bit high for
a Class C, about right for a Class B, and *way* low for an A.  ;-)
Perhaps something like $25, $100, $1000?  With credits for A and B
if they return a /24 or more?  (It makes no sense for a C to return
anything but the full /24, since nothing longer is routable.)

I think we're getting closer.  Thanks, Bill!

--JHG <jhg at omsys.com>


From mysidia at gmail.com  Sun Sep  7 21:27:03 2008
From: mysidia at gmail.com (James Hess)
Date: Sun, 7 Sep 2008 20:27:03 -0500
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48C3E0B9.16203.4DE5806@farmer.umn.edu>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C3E0B9.16203.4DE5806@farmer.umn.edu>
Message-ID: <6eb799ab0809071827v4b78078cge27beb2aa3042b49@mail.gmail.com>

I think of getting address space as something more like getting a license to use
public land for a declared purpose;  i.e.  prospecting,  or building
something intended
to have a public presence.   There may be no revokation procedure in
place at the time you
obtain the license or grant from the government or  appointed private
administrator
for the use of public land.

But the approval of your grant, license, or exclusive assignment doesn't mean a
procedure might not later be developed that imposes new fees, or allows the
license to be assigned to someone else if you fail to use it,  or if
you use the land
for a purpose  other than what you declared,  or fail to uphold new
terms that may
be imposed later.

And there is always a risk of adverse legislation.
It is generous indeed to allow existing users to continue under the
original state
of affairs, and (in any case), it is not likely to last forever.

On Sun, Sep 7, 2008 at 2:10 PM, David Farmer <farmer at umn.edu> wrote:
> On 6 Sep 2008 Jeremy H. Griffith wrote:
> I also agree with you that ARIN is the successor and Legacy holders already
> have an implied contract with ARIN.  Further, in my opinion the point of the
> Legacy RSA is to document and amend that contract to reflect present

Really? What are the terms of this implicit contract?  And most
importantly: what is its duration, and what  consideration does the
legacy holder have to provide in order to honor the
agreement for every X amount of registry services?

Requiring one party to bear an infinite cost of perpetual registration
rDNS services
and to reserve the other party's perpetual use of a resource seems
like an unconscionable agreement.

Is there such a thing as an enforceable implied perpetual contract,
that only gives only one party a consideration that has an ongoing cost..?
It seems more like wishful thinking that there _were_  an enforceable
implied contract
rather than a polite agreement based on IANA's operating procedures and policies
known at the time, there was no expiration or revokation of addresses
ever practiced.

That _didn't_ necessarily  mean they promised it would always be the case, or
that would never change.


IANA is different from ARIN, and an agreement with IANA is no
agreement with ARIN.
There may have been agreements between ARIN and IANA,
but those aren't necessarily agreements with legacy registrants themselves.

If  IANA had obligations to the registrants, it may have failed to make ARIN
aware of them, or may have failed to include them in any agreement with ARIN.


--
-J


From bmanning at vacation.karoshi.com  Mon Sep  8 02:13:39 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 8 Sep 2008 06:13:39 +0000
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <tbq8c45ul1vu141ib1q4kis84640dd19kp@4ax.com>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C35EDE.5070902@sprunk.org>
	<9DF96F31-57B8-4A51-983F-F88D4D091D06@istaff.org>
	<48C415DD.9090306@sprunk.org>
	<20080907221700.GA12418@vacation.karoshi.com.>
	<tbq8c45ul1vu141ib1q4kis84640dd19kp@4ax.com>
Message-ID: <20080908061339.GA16330@vacation.karoshi.com.>

On Sun, Sep 07, 2008 at 05:14:20PM -0700, Jeremy H. Griffith wrote:
> On Sun, 7 Sep 2008 22:17:00 +0000, bmanning at vacation.karoshi.com wrote:
> 
> >	As one time member of the IANA team under Jon and the original
> >head of the reclaimation efforts (we recovered ~30% of the total address pool)
> >i'd like to clarify what the IANA did to "invalidate any IP assignments once it 
> >is determined the the requirement for the address space no longer exists."
> >What we did was:
> >
> >	) contact the listed resource holder(s)#
> >	) ask if they were still using the space
> >	) if so, process any updates they provided
> >	) if not, markt he space as "fallow" - leaving it usassignable for a period
> >
> ># in some cases the organization no longer existed, in some cases the contect had died.
> 
> Thank you!  This means, then, that it was up to the registrant to
> determine whether the requirement still existed.  That's what I
> thought.  The LRSA should have exactly the same effect.

	er, only if the registrant was available/responsive.  and
	that was under a slightly different suite of rules than what
	the IANA may chose to do or not these days. 

> 
> Could you clarify one other point, please?  IIRC, there was no

	I'll try.

> requirement for "non-commercial" use at the time I was issued
> my Class C, in June 1992.  In fact, my communications about it
> were by email, from my domain "omsys.com" (obtained from UUNET
> well before that).  So I was clearly not an .org, .edu, or .gov,
> but nobody said anything about that.  What was the policy at IANA 
> WRT commercial/non-commercial usage at that time?

	well, i can only pull from memory ...  in 1992, prefixes handed
	to me in my role as a network admin for a DoD contractor had to 
	be forceably reclaimed and we had to renumber 33 sites around the
	globe because we "moved" from the disconnected to connected status
	in the then address database.  unconnected sites were never supposed to
	be seen on the 'net and you could run commercial traffic there - it just was
	not part of the ARPAnet.  (check the CSnet history for commercial use)
	seems that at the time, there was a policy of doing "duplicate" assignments,
	those who would connect and those who would not.  And if you changed status,
	then you had to renumber.  so, "unconnected" == do what you want, your 
	not part of the Internet while "connected" == part of the Internet, shared
	obligation regarding stewardship.

	others will no doubt correct my errors and provide additional insight.

> 
> >	The primary reason for the LRSA, imho, is to ensure that there is an 
> >understanding between the resource holder(s) and the current registry. I'm all in
> >favor of retaining the origina terms and conditions, inso far as is feasable/legal
> >The fact remains that we are temporary users/stewards of the resources and that in
> >100 years, it is unlikely that either ARIN or any of us will be around to assert rights
> >under soem previous centurys  half remembered expectations. And given the surprizing 
> >longevity of IPv4, I think it is prudent to re-sync the understandings btwn registry and
> >user.
> 
> I agree, which is why I am persisting in trying to move the process
> toward an LRSA that all legacy registrants would be comfortable
> signing.

	great! agreement is a good basis on which to build.

> I have no problem with *some* fee.  I think $100 is a bit high for
> a Class C, about right for a Class B, and *way* low for an A.  ;-)
> Perhaps something like $25, $100, $1000?  With credits for A and B
> if they return a /24 or more?  (It makes no sense for a C to return
> anything but the full /24, since nothing longer is routable.)

	i think the fee is not intened to reflect the range of the allocation,
	but as a means to track the "freshness" of the contact information.
	Its tough to track down who is responsible for a resource where the
	org disbanded 5 years ago and the admin/tech contacts are dead.

	a regular "hi, are you still there & using the space" in the form of
	invoice and an ack inthe form of "heres my $100 - we're good" is a 
	decent way to track stuff.

	credits for return ... i find to be entangling resource tracking and 
	resoruce re-use.  it would be nice to disambiguate them.  
	wearing my rose-tinted glasses, I can forsee a future where folks won't
	need 256 addresses - when 4 or 8 will do nicely for their translation
	needs.  So being able to return the rest makes sense to me.  I am not
	convinced that /24's are the permanent floor on prefix size.

> 
> I think we're getting closer.  Thanks, Bill!

	your welcome.

--bill
> 
> --JHG <jhg at omsys.com>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From dwhite at olp.net  Mon Sep  8 09:26:44 2008
From: dwhite at olp.net (Dan White)
Date: Mon, 08 Sep 2008 08:26:44 -0500
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <A583F078-C072-40B8-8C1B-8AE740A3C668@delong.com>
References: <1080905143022.13222W-100000@Ives.egh.com>
	<48C18DB3.4080407@olp.net>
	<4DF78E3C-7F0D-4F7E-843B-FADDF94E8746@delong.com>
	<48C1ADC7.8070005@olp.net>
	<A583F078-C072-40B8-8C1B-8AE740A3C668@delong.com>
Message-ID: <48C52814.7040901@olp.net>

Owen DeLong wrote:
>
> On Sep 5, 2008, at 3:08 PM, Dan White wrote:
>
>>
>> One doesn't follow the other. It's short sighted to view the network 
>> world in terms of the desktop computer. Specialized devices are a 
>> scenario where IPv6 makes sense. Not all the world's computers need 
>> to have IPv6 connectivity for me to want one.
>>
> Fine... However, for the vast majority of IPv4 instances in use today,
> IPv6 is not a useful or viable alternative and there's no advantage
> to adding IPv6, only cost.
>
> In order to support IPv6 only hosts on desktop computers after
> we run out of IPv4 addresses with which to do so, all the other
> things those desktops need to be able to reach or be reached
> by need IPv6 addresses, or, we have to play interesting games
> with things like NAT-PT and DNS magic.

In my personal point of view, I see these lines of thoughts following 
two general strains. Let me summarize by offering a case that I expect 
to occur in the next couple of years:

Let's suppose that someone at a hosting company decides to offer a 
service that is IPv6 only. Perhaps the host is dual stack or maybe it 
isn't, but the admin of that host decided that it would be best to offer 
a service that is only reachable over IPv6. Perhaps it's a gaming 
service, or a SIP server or something else.

Suppose that one of my customers comes to me and complains that they are 
unable to use this service. They keep getting an error. The reason is 
that they do not have (native) IPv6 service.

Who's at fault in this scenario?

It's easy to say that it's the host admin. Why would he enable IPv6 when 
not everyone can reach it? Doesn't he know he's going to cause a lot of 
support calls for other admins?

The other point of view is that no one is to blame in this scenario 
except me, since I have not given my customers access to IPv6. I didn't 
do the heavy lifting up front or properly prepare for future demand. My 
customer, who really likes that game, is free to find another ISP who 
will give them that access.

IPv6 will not (and has not) deployed as all or nothing, but piecemeal as 
it should. It would be insanity to do otherwise.

- Dan


From tvest at pch.net  Mon Sep  8 10:03:17 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 8 Sep 2008 10:03:17 -0400
Subject: [arin-ppml] Historical awareness
In-Reply-To: <48C52814.7040901@olp.net>
References: <1080905143022.13222W-100000@Ives.egh.com>
	<48C18DB3.4080407@olp.net>
	<4DF78E3C-7F0D-4F7E-843B-FADDF94E8746@delong.com>
	<48C1ADC7.8070005@olp.net>
	<A583F078-C072-40B8-8C1B-8AE740A3C668@delong.com>
	<48C52814.7040901@olp.net>
Message-ID: <5068A8C0-AAF7-4BC5-999F-5FC425C026CC@pch.net>

"The Prospect Of IP Renumbering"
Christine Hudgins-Bonafield
Network Computing, May 31, 1996
http://www.networkcomputing.com/709/709f2.html


"Net Address Transfers Could Presage Routing Fees"
Christine Hudgins-Bonafield
Network Computing, August 8, 1996
http://www.networkcomputing.com/712/712hreportb.html

TV


From vixie at isc.org  Mon Sep  8 10:14:01 2008
From: vixie at isc.org (Paul Vixie)
Date: Mon, 08 Sep 2008 14:14:01 +0000
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C52814.7040901@olp.net> (Dan White's message of "Mon\,
	08 Sep 2008 08\:26\:44 -0500")
References: <1080905143022.13222W-100000@Ives.egh.com>
	<48C18DB3.4080407@olp.net>
	<4DF78E3C-7F0D-4F7E-843B-FADDF94E8746@delong.com>
	<48C1ADC7.8070005@olp.net>
	<A583F078-C072-40B8-8C1B-8AE740A3C668@delong.com>
	<48C52814.7040901@olp.net>
Message-ID: <g3zlmiafo6.fsf@nsa.vix.com>

dwhite at olp.net (Dan White) writes:

> In my personal point of view, I see these lines of thoughts following two
> general strains. Let me summarize by offering a case that I expect to
> occur in the next couple of years:
>
> Let's suppose that someone at a hosting company decides to offer a
> service that is IPv6 only. Perhaps the host is dual stack or maybe it
> isn't, but the admin of that host decided that it would be best to offer
> a service that is only reachable over IPv6. Perhaps it's a gaming
> service, or a SIP server or something else.
>
> Suppose that one of my customers comes to me and complains that they are
> unable to use this service. They keep getting an error. The reason is
> that they do not have (native) IPv6 service.
>
> Who's at fault in this scenario?

by definition: whoever loses, or fails to make, the most money as a result
of their actions or inactions.  there's no higher court for a network owner
than that, since you spoke in terms of customers and their complaints.

> It's easy to say that it's the host admin. Why would he enable IPv6 when 
> not everyone can reach it? Doesn't he know he's going to cause a lot of 
> support calls for other admins?

i think you mean "offer an ipv6-only service" (which you said above) rather
than "enable ipv6".  all of the hosts i use regularly have been dual stack
for years, and other than the times ipv4 is down and i can only reach ipv6
endpoints, i've neither made nor received support calls as a result of it.

> The other point of view is that no one is to blame in this scenario 
> except me, since I have not given my customers access to IPv6. I didn't 
> do the heavy lifting up front or properly prepare for future demand. My 
> customer, who really likes that game, is free to find another ISP who 
> will give them that access.
>
> IPv6 will not (and has not) deployed as all or nothing, but piecemeal as 
> it should. It would be insanity to do otherwise.

i agree with that last statement, which is why i think everybody ought to be
running dual-stack, while there are still greenfield ipv4's to do it with.
the time will come when various providers will offer only "native ipv6 plus
NAT'd ipv4" and this will be the moment when your own customers will wish
that you could offer them dual-stack.
-- 
Paul Vixie


From DHAWKES at abrazohealth.com  Mon Sep  8 13:59:38 2008
From: DHAWKES at abrazohealth.com (Hawkes, Dave)
Date: Mon, 8 Sep 2008 10:59:38 -0700
Subject: [arin-ppml] IPv6 Heretic thoughts
In-Reply-To: <48C01D9B.10400@cjbsys.bdb.com>
Message-ID: <5FFFDD424FD24B48A47E7CEA7B2F888C02D2E06C@mail-srv02.vhswest.local>

I agree.  There is nothing forcing a IPv6 migration.

The inherent problem with IPv6 is that no one is forced to initiate the migration today.  It has already been made clear that many of the larger companies that can drive the technology have large legacy IPv4 blocks that are no where near depletion.  Some of them have small experimental IPv6 subnets, but no plans to migrate their existing legacy IPv4 networks.  Companies with smaller IPv4 blocks that need to migrate to IPv6 sooner may not have the clout to force a migration outside of their own network.  Also, there is no benefit from the Internet end-user's perspective to drive IPv6, and end-user's in general don't know what IPv6 is.  Of course, all of us are Internet end-users (individually and as companies), however few of us are driving IPv6 outside of this forum.

The technology to implement IPv6 on existing networks is there (however many companies may not have that equipment, or more likely not be able to support the increase in processing on their aggregated networks, etc).  Some solutions for supporting IPv4 and IPv6 may not be viable, but the solutions are there.  IPv6 has support for IPv4 built in, the hangup is in the translation between the two in cases where dual-stack isn't feasible.  (These cases may just need to be re-engineered for a dual-stacked network).

I agree that there needs to be a deadline, instead of the impending doom of IPv4 depletion.  Perhaps the deadline should be focused on one aspect of the Internet, rather than all IPv4 usage.  After all, we aren't talking about HDTV, MSDOS, or other similar migrations.  We are talking about IPv4/IPv6.  IPv4 to IPv4 communication needs to continue to survive transparently on an IPv6 network, and the IPv4 networks will continue to increase in size.  A deadline can be proposed that forces the exchange points between networks to migrate to IPv6 first.  Internal networks and networking equipment can initiate the migration, leaving the end-points (web servers, workstations, etc) on IPv4 networks.

By initiating a migration between networks, and on traffic internal to a network (traffic aggregation between access routers and the core of networks), then many IPv4 subnets will be freed and can be used on the nodes left in (non-RFC1918) IPv4 space.  More importantly, the framework for IPv6 on the Internet between peers, and within networks will be in place.  The nodes left in IPv4 space will then eventually follow the migration.  It seems that if a blanket deadline is put in place, no one will accept it and nothing will get done.  But perhaps there can be more support for a deadline that phased certain traffic to IPv6.

I'm not sure how a deadline can be limited to such traffic.  Since once a company is issued IPv4 addresses, they are free to use them as they wish.  However, once a few larger legacy networks begin such a migration on their internal networks and exchange points, it would gain momentum.  Company A that peers to companies B - Z would be able to force the router to router communication at that exchange to IPv6 easier than a smaller company that peers with only a few networks.  Once you are forced to use IPv6 for router to router communication on one part of your network, a lot of the investment is done and migrating all of your router to router/internal traffic to IPv6 is that much easier.

*** I may be totally out of left field on all of this, and possibly just came out of hibernation.  So, if none of this makes sense, or if I am behind on the discussions, let me know.

Dave

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Cliff Bedore
Sent: Thursday, September 04, 2008 10:41 AM
To: PPML
Subject: [arin-ppml] IPv6 Heretic thoughts

Having been reading this group for approaching a year or so now, I think I've seen the problem with adopting IPv6.  Nobody really wants it.
There is no CEO in the world sitting around saying "Boy I can't wait to get us on IPv6" and there is no Joe Sixpack sitting at home who gives a rats a** about IPv6 vs IPv4.  They want to get to Google or ESPN or their favorite porn site or their favorite gaming site or gambling site.

The problem:  There is no compatibility bit in IPv6 that says I'm just like IPv4 but I have 96 more address bits.  Lacking this, I think the only way to get IPv6 going is to develop a transparent IPv6 to IPv4 translator and convert the entire "Internet backbone" to IPv6.  If I'm reading stuff correctly, something like NAT64 is a good starting point but there is more required.  The backbone for the Internet will have to be IPv6, DNS will have to be IPv6 and IPv4 will be treated as IPv6 on the Internet and translated through the "converter box (CB)".  This means that the CB will have to do both translation and DNS lookups for the v4 hosts.  Since there are 64 bits per subnet in IPv6, there will never be a subnet that can't split off IPv4 addresses through the CB for translation.

That's a short summary of a big problem but I think it's obvious that there has been little real adoption of IPv6.  We really need a program that accomplishes what the US HDTV program did.  Tell people that "on MM/DD/YY, the Internet backbone will be IPv6 only.  If you want to run IPv4, you will need one(or more) of the converter boxes for your IPv4 addresses.  If you don't do this, you will lose Internet connectivity"

Advantages to this include

1.  All IPv4 space effectively becomes PI space since you can tuck your
IPv4 into any IPv6 subnet and not have to change anything but the address of your CB(s).

2.  Routing tables should shrink since IPv4 can be removed and there should be better aggregation.

3.  You don't throw out all the old IPv4 only systems/software.  Old games work.  Old PCs work

4.  IPv4 local networks can still talk to IPv4 local networks across the world "transparently". Any IPv4 browser should be able to go through the CB and get to Google or any other web server.

5  Those who want to take advantage of the fancy parts of IPv6 can still do so.

6.  No tunneling only translation.

7.  As time goes by, more and more of the Internet will become native
IPv6 and the conversion boxes can be retired but it should always be possible to have that converter box to allow running some oddball old software.  (I still have a 386 in my basement that runs DOS with packet drivers and can telnet to any host that lets me have an account.)

I'm sure people can come up with  all kinds of reasons why this won't work but let's face it; right now IPv6 is a dud.  Sure it works but it can't talk to IPv4 simply and transparently and if the converter box discussed above is technically impossible, IPv6 doesn't deserve to be the next generation of IP addressing.  If the converter box works (and it has to work with all of IPv4) then the only way to get people to IPv6 is to do something similar to what is discussed above.  I'm not particularly pro or con re IPv6, I just see it not working in the present method of rolling it out.  The U. S. government mandate of using
IPv6 is very reminiscent of the great GOSIP debacle of the 1990s and if something doesn't change in how we do this, I frankly see IPv6 dying out and a smaller group of good engineers will come up with something that works instead of a protocol designed by an overly large committee that wants everything but the kitchen sink.

Look at the successful conversions of the past.  The latest Pentium will run MS DOS.  I can watch HDTV on my old TV, I believe it was IBM 360s which ran "an older machine"(somebody here will remember) in emulation mode.  The latest DVD drive can still play a CD.  People will adopt something because it works for them without a lot of fuss or it is a disruptive technology that offers something worth the conversion to something new (think iPod).  I don't see IPv6 as ever being a disruptive technology so it is going to have to be backward compatible in some way or it will die.

Cliff






_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From Lee.Howard at stanleyassociates.com  Mon Sep  8 17:33:42 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Mon, 8 Sep 2008 17:33:42 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <FBEEF918-7CFF-4664-892E-70AAAB94DA25@kanren.net>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B348FF1@CL-S-EX-1.stanleyassociates.com>

Sorry, the length of this message kind of got away from me.  I'm
trying to put many thoughts into a single message, rather than
spew messages into PPML all day.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Cort Buffington
> Sent: Sunday, September 07, 2008 10:04 AM
> To: arin ppml
> Subject: Re: [arin-ppml] ARIN releases new version of the 
> Legacy Registration
> 
> When I read Eric's post, which is outstanding by the way, I 
> recall what my fears were when I read the first LRSA offered 
> to me (I have not had time to read the new one yet). The way 
> things were worded make me feel kind of like this:
> 
> "So this looks pretty good, except all of the language 
> protecting ARIN's ability to arbitrarily change the agreement 
> in any way at any time."

Two things in the LRSA might mitigate that concern:
1.  Section 7 says you agree to be bound by community-developed
policies, unless they contradict the LRSA (e.g., section 10b).
2.  You always have the option to stay on your current LRSA or
accept a new one: section 15(m)

> And the first one did pretty much read that way. It's going 
> to take a long, long time to regain my trust. Interestingly 
> enough, I trusted ARIN before the one-sided contract and 
> extortive sounding tactics of the original LRSA. Whether 
> intended or not, that's the way it came across to me.

Let's talk about what we agree on.  While not universal, there's
rough consensus around these points:
* Legacy holders have a slightly different status than modern 
holders
* ARIN is the organization providing rDNS, WHOIS, and other
services that are useful to the community, in this region
* Legacy holders should pay some nominal maintenance fee, to pay
for maintenance of those services, and as an annual check that 
the legacy holder still exists and is using the numbers
* Legacy holders who are using the space should not have to 
give up the space (unless required by a force greater than 
community consensus).  Conversely, legacy holders who are not
using the space should make that space available for 
reassignment; those with partial utilization should be 
encouraged, but not forced, to release what they can.
* ARIN must abide by laws, government regulations, court 
rulings, and contracts.
* People and organizations holding address space must abide by
laws, government regulations, court rulings and contracts.

Right?


Under the new LRSA, the contract would be terminated, but the 
resources would remain with the legacy holder, under the 
following circumstances:

1. 14(c) the legacy holder terminates for cause, or 
2. 15(k) ARIN is unable to provide service due to force majeure.

Fair so far?


The only major point of contention is whether a legacy holder
should ever be required to release their resources to ARIN.  As
I read the LRSA, the contract would be terminated and ARIN
would stop providing service (i.e., revoke) under the following 
circumstances:

1.  4(c) Legacy holder does not provide "information, assistance,
and cooperation that ARIN requests in provision of the Services."
ARIN may simply refuse additional resources instead.
2.  4(d)(i) Legacy holder disrupts or interferes with ARIN's 
services, 
3. 4(d)(ii) Legacy holder "violate(s) any applicable laws, 
statutes or regulations, as established by a definitive ruling 
of a court or government agency;"
4. 4(d)(iii) Legacy holder "assist(s) any third party in engaging 
in any activity prohibited by this Legacy Agreement."
5.  6(b)(ii) Legacy holder falls more than a year overdue on 
maintenance fees (which are substantially capped).  ARIN may stop
providing Services without revocation, and in any case must allow
an additional year for the holder to make good before reassigning
the numbers.
6. 5(a) - (c) Legacy holder misuses ARIN's database
7.  14(b)(ii) Breach of contract that remains uncured for 30 days
8.  14(a) Legacy holder decides to terminate the contract for 
convenience.  Note that ARIN cannot terminate for convenience in
LRSA 2.0.

Please let me know if I've missed or mistated any scenarios; it's 
entirely possible and not intentional.  I'm just reading along 
like everyone else.


Now, I understand that some people believe they have an
inviolable right to maintain their resources under all 
circumstances.  I believe that if a legacy holder violates the
trust of the community, the community ought to have recourse.
The community founded ARIN, to operate the registry and reverse
DNS, and to facilitate community development of policies for
stewardship of numbers, and to do what is needed to support 
that mission.  It seems to me that the termination clauses are 
trying to protect ARIN's ability to serve the community and 
fulfill its mission.

I think ARIN has come pretty far with this new LRSA, trying to
protect both legacy holders and the rest of the community.  I 
appreciate the participation on this list by so many people 
responsible for legacy address space, when many of the 
policies developed will not ultimately affect you.  I 
acknowledge the concession many of you have made, in 
willingness to support ARIN financially.  I respect the 
contributions legacy holders have made to the development and growth of
the Internet.  I hope you can see the Legacy RSA, 
which was designed to offer greater assurance to the legacy
holder than the conventional RSA, as a tool for protecting the 
community's broader interest.

I must be clear, that I do not represent ARIN any more than 
any other community member when it comes to the LRSA.  I hope
that everyone with questions about the LRSA will call the 
Registration Services Help Desk at +1.703.227. 0660 or send 
email to hostmaster at arin.net, or with specific legal questions, 
contact ARIN General Counsel, Steve Ryan, at sryan at mwe.com. 


Lee



From JOHN at egh.com  Mon Sep  8 19:11:20 2008
From: JOHN at egh.com (John Santos)
Date: Mon, 8 Sep 2008 19:11:20 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B348FF1@CL-S-EX-1.stanleyassociates.com>
Message-ID: <1080908184908.13222G-100000@Ives.egh.com>

On Mon, 8 Sep 2008, Howard, W. Lee wrote:

> Sorry, the length of this message kind of got away from me.  I'm
> trying to put many thoughts into a single message, rather than
> spew messages into PPML all day.
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Cort Buffington
> > Sent: Sunday, September 07, 2008 10:04 AM
> > To: arin ppml
> > Subject: Re: [arin-ppml] ARIN releases new version of the 
> > Legacy Registration
> > 
> > When I read Eric's post, which is outstanding by the way, I 
> > recall what my fears were when I read the first LRSA offered 
> > to me (I have not had time to read the new one yet). The way 
> > things were worded make me feel kind of like this:
> > 
> > "So this looks pretty good, except all of the language 
> > protecting ARIN's ability to arbitrarily change the agreement 
> > in any way at any time."
> 
> Two things in the LRSA might mitigate that concern:
> 1.  Section 7 says you agree to be bound by community-developed
> policies, unless they contradict the LRSA (e.g., section 10b).
> 2.  You always have the option to stay on your current LRSA or
> accept a new one: section 15(m)
> 
> > And the first one did pretty much read that way. It's going 
> > to take a long, long time to regain my trust. Interestingly 
> > enough, I trusted ARIN before the one-sided contract and 
> > extortive sounding tactics of the original LRSA. Whether 
> > intended or not, that's the way it came across to me.
> 
> Let's talk about what we agree on.  While not universal, there's
> rough consensus around these points:
> * Legacy holders have a slightly different status than modern 
> holders
> * ARIN is the organization providing rDNS, WHOIS, and other
> services that are useful to the community, in this region
> * Legacy holders should pay some nominal maintenance fee, to pay
> for maintenance of those services, and as an annual check that 
> the legacy holder still exists and is using the numbers
> * Legacy holders who are using the space should not have to 
> give up the space (unless required by a force greater than 
> community consensus).  Conversely, legacy holders who are not
> using the space should make that space available for 
> reassignment; those with partial utilization should be 
> encouraged, but not forced, to release what they can.
> * ARIN must abide by laws, government regulations, court 
> rulings, and contracts.
> * People and organizations holding address space must abide by
> laws, government regulations, court rulings and contracts.
> 
> Right?
> 
> 
> Under the new LRSA, the contract would be terminated, but the 
> resources would remain with the legacy holder, under the 
> following circumstances:
> 
> 1. 14(c) the legacy holder terminates for cause, or 
> 2. 15(k) ARIN is unable to provide service due to force majeure.
> 
> Fair so far?
> 
> 
> The only major point of contention is whether a legacy holder
> should ever be required to release their resources to ARIN.  As
> I read the LRSA, the contract would be terminated and ARIN
> would stop providing service (i.e., revoke) under the following 
> circumstances:
> 
> 1.  4(c) Legacy holder does not provide "information, assistance,
> and cooperation that ARIN requests in provision of the Services."
> ARIN may simply refuse additional resources instead.
> 2.  4(d)(i) Legacy holder disrupts or interferes with ARIN's 
> services, 
> 3. 4(d)(ii) Legacy holder "violate(s) any applicable laws, 
> statutes or regulations, as established by a definitive ruling 
> of a court or government agency;"

This is the only clause that I have any problems with, at least
so far.

Maybe the word "applicable" covers this, though IANAL, so I
worry!

First there are is the issue of jurisdiction, i.e. who decides
that the holder should lose their IPs?  The court?  The ARIN
staff?  How does ARIN discover that the situation has arisen?
Do courts routinely notify ARIN of such situations, or does
someone have to complain?

Second is the issue of scope.  I don't think I should lose my
IP addresses because my company failed to shovel its front walk
within 12 hours of a snow storm!  In fact, I would have problems
with this for virtually any criminal activity that wasn't
internet-related.  Sure, if someone was spoofing other peoples
IP addresses or injecting bogus routes or actively trying to
crack competitor's networks, but what about something like
tax fraud or OSHA violations?

Third is I don't think ARIN should become an instrument of
state suppression of freedom of speach, press, or association.
For example, I don't think ARIN should be in a position of
aiding the US Govt in prosecuting the New York Times, the
Washington Post, or the Boston Globe for publishing the
Pentagon Papers.  (I think they were all ultimately forced
to pay a fine and desist from further publication, until the
whole case became moot, but under these rules, would they
have lost their internet access?)  If ARIN were ordered
by a court to revoke the allocations, I don't see it would
have any choice, but I don't think it should be doing this
on its own initiative.

(A more current example would be if Amnesty International
was to publish secretly-obtained interviews with Gitmo
prisoners, and the US Govt went after it.)

Perhaps "applicable" covers all these areas, or maybe there
implicitly has to be a court order, with due process, all
possibility of appeals exhausted, etc.


> 4. 4(d)(iii) Legacy holder "assist(s) any third party in engaging 
> in any activity prohibited by this Legacy Agreement."

Assuming all protections that apply to the previous section
also apply here, this would be okay.  Otherwise it is the
possibility of an end-run around 4(d)(ii).


> 5.  6(b)(ii) Legacy holder falls more than a year overdue on 
> maintenance fees (which are substantially capped).  ARIN may stop
> providing Services without revocation, and in any case must allow
> an additional year for the holder to make good before reassigning
> the numbers.
> 6. 5(a) - (c) Legacy holder misuses ARIN's database
> 7.  14(b)(ii) Breach of contract that remains uncured for 30 days
> 8.  14(a) Legacy holder decides to terminate the contract for 
> convenience.  Note that ARIN cannot terminate for convenience in
> LRSA 2.0.
> 
> Please let me know if I've missed or mistated any scenarios; it's 
> entirely possible and not intentional.  I'm just reading along 
> like everyone else.
> 
> 
> Now, I understand that some people believe they have an
> inviolable right to maintain their resources under all 
> circumstances.  I believe that if a legacy holder violates the
> trust of the community, the community ought to have recourse.
> The community founded ARIN, to operate the registry and reverse
> DNS, and to facilitate community development of policies for
> stewardship of numbers, and to do what is needed to support 
> that mission.  It seems to me that the termination clauses are 
> trying to protect ARIN's ability to serve the community and 
> fulfill its mission.
> 
> I think ARIN has come pretty far with this new LRSA, trying to
> protect both legacy holders and the rest of the community.  I 
> appreciate the participation on this list by so many people 
> responsible for legacy address space, when many of the 
> policies developed will not ultimately affect you.  I 
> acknowledge the concession many of you have made, in 
> willingness to support ARIN financially.  I respect the 
> contributions legacy holders have made to the development and growth of
> the Internet.  I hope you can see the Legacy RSA, 
> which was designed to offer greater assurance to the legacy
> holder than the conventional RSA, as a tool for protecting the 
> community's broader interest.
> 
> I must be clear, that I do not represent ARIN any more than 
> any other community member when it comes to the LRSA.  I hope
> that everyone with questions about the LRSA will call the 
> Registration Services Help Desk at +1.703.227. 0660 or send 
> email to hostmaster at arin.net, or with specific legal questions, 
> contact ARIN General Counsel, Steve Ryan, at sryan at mwe.com. 
> 
> 
> Lee
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From sleibrand at internap.com  Mon Sep  8 23:18:09 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 08 Sep 2008 20:18:09 -0700
Subject: [arin-ppml] TPRC Paper on IP Addresses and Transfer Markets:
 "Running on Empty: the Challenge of Managing Internet Addresses"
In-Reply-To: <48BFEF2F.40108@cisco.com>
References: <48BFEF2F.40108@cisco.com>
Message-ID: <48C5EAF1.9080205@internap.com>

I just finished reading this paper, and must say it's very well written, 
does an excellent job of summarizing the issues, and presents some 
excellent analysis.  I would recommend it to anyone subscribed to this 
list, and many others outside our community.

Thanks very much for the contribution.

-Scott

Eliot Lear wrote:
> Dear all,
> 
> We would like to bring to your attention a paper that Bill Lehr, Tom 
> Vest, and I wrote for the upcoming TPRC conference, at the end of this 
> month, the title of which is "Running on Empty: The Challenge of 
> managing Internet addresses".  The paper looks at transfer markets and 
> specific proposals from the RIRs and provides pluses and minuses to the 
> theoretical space, as well as some commentary on specific proposals.  
> The authors concur that the results of the proposed market initiatives 
> will likely depend on variety of identifiable parameters (e.g., specific 
> transfer policy mechanisms, possible IPv4 reservation policies, secure 
> inter-domain routing initiatives, etc.), but do not agree on the 
> appropriate weighting of risks.
> 
> In talking about specific RIR proposals we note extreme differences in 
> what we presume to be the assumptions of the authors about ability to 
> enforce regulations and the priorities that an RIR should have.  We also 
> look at the impact of transfer markets on IPv6 adoption, and to a lesser 
> extent, on the interdependency between addressing and routing.
> 
> We hope this paper is useful to continuing a dialog that leads to 
> appropriate evolution of RIR policies.  You can find it here 
> <http://tprcweb.com/files/Lehr%20Vest%20Lear%20Internet%20Address%20TPRC%208_15_08.pdf> 
> or by going to www.tprc.org and looking at the detailed agenda for 
> Saturday, along with several other interesting and related papers.
> 
> Yours,
> 
> Bill Lehr
> Tom Vest
> Eliot Lear
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From mueller at syr.edu  Tue Sep  9 10:21:54 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 9 Sep 2008 10:21:54 -0400
Subject: [arin-ppml] TPRC Paper on IP Addresses and Transfer Markets:
	"Running on Empty: the Challenge of Managing Internet Addresses"
In-Reply-To: <48C5EAF1.9080205@internap.com>
References: <48BFEF2F.40108@cisco.com> <48C5EAF1.9080205@internap.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E74F@SUEXCL-02.ad.syr.edu>

Yes, it's especially gratifying to see a paper with Tom Vest's name on
it conclude that "An approved, well-functioning market is preferable to
the alternatives." ;-)  

--MM

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Scott Leibrand
> 
> I just finished reading this paper, and must say it's very well
written,
> does an excellent job of summarizing the issues, and presents some
> excellent analysis.  I would recommend it to anyone subscribed to this
> list, and many others outside our community.
> 
> Thanks very much for the contribution.
> 
> -Scott
> 
> Eliot Lear wrote:
> > Dear all,
> >
> > We would like to bring to your attention a paper that Bill Lehr, Tom
> > Vest, and I wrote for the upcoming TPRC conference, at the end of
this
> > month, the title of which is "Running on Empty: The Challenge of
> > managing Internet addresses".  The paper looks at transfer markets
and
> > specific proposals from the RIRs and provides pluses and minuses to
the
> > theoretical space, as well as some commentary on specific proposals.
> > The authors concur that the results of the proposed market
initiatives
> > will likely depend on variety of identifiable parameters (e.g.,
specific
> > transfer policy mechanisms, possible IPv4 reservation policies,
secure
> > inter-domain routing initiatives, etc.), but do not agree on the
> > appropriate weighting of risks.
> >
> > In talking about specific RIR proposals we note extreme differences
in
> > what we presume to be the assumptions of the authors about ability
to
> > enforce regulations and the priorities that an RIR should have.  We
also
> > look at the impact of transfer markets on IPv6 adoption, and to a
lesser
> > extent, on the interdependency between addressing and routing.
> >
> > We hope this paper is useful to continuing a dialog that leads to
> > appropriate evolution of RIR policies.  You can find it here
> >
>
<http://tprcweb.com/files/Lehr%20Vest%20Lear%20Internet%20Address%20TPRC
%2
> 08_15_08.pdf>
> > or by going to www.tprc.org and looking at the detailed agenda for
> > Saturday, along with several other interesting and related papers.
> >
> > Yours,
> >
> > Bill Lehr
> > Tom Vest
> > Eliot Lear
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From Lee.Howard at stanleyassociates.com  Tue Sep  9 10:50:13 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Tue, 9 Sep 2008 10:50:13 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <1080908184908.13222G-100000@Ives.egh.com>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B349459@CL-S-EX-1.stanleyassociates.com>

> > 3. 4(d)(ii) Legacy holder "violate(s) any applicable laws, 
> statutes or 
> > regulations, as established by a definitive ruling of a court or 
> > government agency;"
> 
> This is the only clause that I have any problems with, at 
> least so far.
> 
> Maybe the word "applicable" covers this, though IANAL, so I worry!

Would you check with a lawyer, or discuss your concerns with 
ARIN's General Counsel?  IANAL either, so I'm reluctant to
interpret this section too closely.

I will make the point that ARIN has to comply with laws, 
government regulations, and court orders.

> Third is I don't think ARIN should become an instrument of 
> state suppression of freedom of speach, press, or association.

While I am suspicious of government persecution, I also think
it would be inappropriate for ARIN staff or Board to decide to 
ignore a court order or break a law to defend a principle.  
We're not competent to evaluate, on behalf of the members and
community, whether a principle should supersede the law (at 
least, we're not more competent than the judicial system; let's
not be in contempt of the courts).  ARIN is not the right
organization to resist a government gone amok--that's waaay
outside our mission.

> Perhaps "applicable" covers all these areas, or maybe there 
> implicitly has to be a court order, with due process, all 
> possibility of appeals exhausted, etc.

"definitive" and "applicable" are useful adjectives.

> > 4. 4(d)(iii) Legacy holder "assist(s) any third party in 
> engaging in 
> > any activity prohibited by this Legacy Agreement."
> 
> Assuming all protections that apply to the previous section 
> also apply here, this would be okay.  Otherwise it is the 
> possibility of an end-run around 4(d)(ii).

The trick is to prevent the end run around 4(d)(ii) (or other
naughtiness) by having a third party do your dirty work.

Lee


From tvest at pch.net  Tue Sep  9 11:03:36 2008
From: tvest at pch.net (Tom Vest)
Date: Tue, 9 Sep 2008 11:03:36 -0400
Subject: [arin-ppml] TPRC Paper on IP Addresses and Transfer Markets:
	"Running on Empty: the Challenge of Managing Internet Addresses"
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E74F@SUEXCL-02.ad.syr.edu>
References: <48BFEF2F.40108@cisco.com> <48C5EAF1.9080205@internap.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E74F@SUEXCL-02.ad.syr.edu>
Message-ID: <520671EC-8160-4D99-B7C6-52F0441316A0@pch.net>

Hi Milton,

This was a collaborative work, and the authors worked hard (!) to find  
as much common ground as possible.
After reading through the full paper, you would probably be inclined  
to revise that to "a paper with Tom Vest's name on it conclude that  
'An approved, well-functioning market is preferable to *many* but not  
all alternatives.'"

Anyway, that's the way I actually did conclude. But that should come  
as no surprise, as that's perfectly consistent with what I've been  
writing here all along. I am not averse to markets, either in general  
or in the vast majority of specific instances; I just have reasons to  
doubt that they'll work -- much less be "well-functioning" -- in  
*this* specific context.

I am finalizing a bunch of things to put online (the long promised  
"other shoe" ++) over the next day or two. There's a link in the  
paper, but I'll ping you directly when the materials are actually up.

Regards,

TV


On Sep 9, 2008, at 10:21 AM, Milton L Mueller wrote:

> Yes, it's especially gratifying to see a paper with Tom Vest's name on
> it conclude that "An approved, well-functioning market is preferable  
> to
> the alternatives." ;-)
>
> --MM
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
>> Behalf Of Scott Leibrand
>>
>> I just finished reading this paper, and must say it's very well
> written,
>> does an excellent job of summarizing the issues, and presents some
>> excellent analysis.  I would recommend it to anyone subscribed to  
>> this
>> list, and many others outside our community.
>>
>> Thanks very much for the contribution.
>>
>> -Scott
>>
>> Eliot Lear wrote:
>>> Dear all,
>>>
>>> We would like to bring to your attention a paper that Bill Lehr, Tom
>>> Vest, and I wrote for the upcoming TPRC conference, at the end of
> this
>>> month, the title of which is "Running on Empty: The Challenge of
>>> managing Internet addresses".  The paper looks at transfer markets
> and
>>> specific proposals from the RIRs and provides pluses and minuses to
> the
>>> theoretical space, as well as some commentary on specific proposals.
>>> The authors concur that the results of the proposed market
> initiatives
>>> will likely depend on variety of identifiable parameters (e.g.,
> specific
>>> transfer policy mechanisms, possible IPv4 reservation policies,
> secure
>>> inter-domain routing initiatives, etc.), but do not agree on the
>>> appropriate weighting of risks.
>>>
>>> In talking about specific RIR proposals we note extreme differences
> in
>>> what we presume to be the assumptions of the authors about ability
> to
>>> enforce regulations and the priorities that an RIR should have.  We
> also
>>> look at the impact of transfer markets on IPv6 adoption, and to a
> lesser
>>> extent, on the interdependency between addressing and routing.
>>>
>>> We hope this paper is useful to continuing a dialog that leads to
>>> appropriate evolution of RIR policies.  You can find it here
>>>
>>
> <http://tprcweb.com/files/Lehr%20Vest%20Lear%20Internet%20Address%20TPRC
> %2
>> 08_15_08.pdf>
>>> or by going to www.tprc.org and looking at the detailed agenda for
>>> Saturday, along with several other interesting and related papers.
>>>
>>> Yours,
>>>
>>> Bill Lehr
>>> Tom Vest
>>> Eliot Lear
>>>
>>>
>>>
> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.



From cliffb at cjbsys.bdb.com  Tue Sep  9 11:55:11 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Tue, 09 Sep 2008 11:55:11 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B348FF1@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B348FF1@CL-S-EX-1.stanleyassociates.com>
Message-ID: <48C69C5F.1090002@cjbsys.bdb.com>

Howard, W. Lee wrote:
> Sorry, the length of this message kind of got away from me.  I'm
> trying to put many thoughts into a single message, rather than
> spew messages into PPML all day.
>
>   
>   
...... stuff deleted

> Let's talk about what we agree on.  While not universal, there's
> rough consensus around these points:
> * Legacy holders have a slightly different status than modern 
> holders
>   

I'd delete slightly

> * ARIN is the organization providing rDNS, WHOIS, and other
> services that are useful to the community, in this region
>   

Agree

> * Legacy holders should pay some nominal maintenance fee, to pay
> for maintenance of those services, and as an annual check that 
> the legacy holder still exists and is using the numbers
>  


Legacy holders "are willing to pay".  It appears from other posts that 
ARIN doesn't really need the money so the contact information seems to 
be the big issues.

> * Legacy holders who are using the space should not have to 
> give up the space (unless required by a force greater than 
> community consensus).  Conversely, legacy holders who are not
> using the space should make that space available for 
> reassignment; those with partial utilization should be 
> encouraged, but not forced, to release what they can.
>   
Legacy holders who are not using... "should".  So those who have no
agreement only "should" make the space available but those who sign the
LRSA and then decide to terminate the contract for convenience will lose
that space.  It seems that LRSA signers are being put at a disadvantage
compared to non-signers

> * ARIN must abide by laws, government regulations, court 
> rulings, and contracts.
> * People and organizations holding address space must abide by
> laws, government regulations, court rulings and contracts.
>
> Right?
>
>
> Under the new LRSA, the contract would be terminated, but the 
> resources would remain with the legacy holder, under the 
> following circumstances:
>
> 1. 14(c) the legacy holder terminates for cause, or 
> 2. 15(k) ARIN is unable to provide service due to force majeure.
>
> Fair so far?
>   

Per above, I don't agree with 14(c) being limited to terminates for cause.

>
> The only major point of contention is whether a legacy holder
> should ever be required to release their resources to ARIN.  As
> I read the LRSA, the contract would be terminated and ARIN
> would stop providing service (i.e., revoke) under the following 
> circumstances:
>
> 1.  4(c) Legacy holder does not provide "information, assistance,
> and cooperation that ARIN requests in provision of the Services."
> ARIN may simply refuse additional resources instead.
> 2.  4(d)(i) Legacy holder disrupts or interferes with ARIN's 
> services, 
> 3. 4(d)(ii) Legacy holder "violate(s) any applicable laws, 
> statutes or regulations, as established by a definitive ruling 
> of a court or government agency;"
> 4. 4(d)(iii) Legacy holder "assist(s) any third party in engaging 
> in any activity prohibited by this Legacy Agreement."
> 5.  6(b)(ii) Legacy holder falls more than a year overdue on 
> maintenance fees (which are substantially capped).  ARIN may stop
> providing Services without revocation, and in any case must allow
> an additional year for the holder to make good before reassigning
> the numbers.
> 6. 5(a) - (c) Legacy holder misuses ARIN's database
> 7.  14(b)(ii) Breach of contract that remains uncured for 30 days
> 8.  14(a) Legacy holder decides to terminate the contract for 
> convenience.  Note that ARIN cannot terminate for convenience in
>   

I would agree that ARIN could stop providing services but I'm not
convinced they should be able to revoke the numbers

> LRSA 2.0.
>
> Please let me know if I've missed or mistated any scenarios; it's 
> entirely possible and not intentional.  I'm just reading along 
> like everyone else.
>   

I'm not trying to be too picky but "silence gives consent" and I'm not
consenting yet.  Repeating my comments of earlier, if ARIN is trying to
formalize relationships with legacy holders, it can be done in a much
less restrictive manner than the current LRSA.  If they're trying to
recover unused/lost address space, there is no need for the LRSA since
per above, people who have it will only be encouraged to return it and
those who have disappeared from the grid and don't answer any requests
from ARIN will obviously not have any agreement with ARIN.  It seems odd
that the people who are most willing to participate face the most
onerous sanctions.

Cliff

>
> Now, I understand that some people believe they have an
> inviolable right to maintain their resources under all 
> circumstances.  I believe that if a legacy holder violates the
> trust of the community, the community ought to have recourse.
> The community founded ARIN, to operate the registry and reverse
> DNS, and to facilitate community development of policies for
> stewardship of numbers, and to do what is needed to support 
> that mission.  It seems to me that the termination clauses are 
> trying to protect ARIN's ability to serve the community and 
> fulfill its mission.
>
> I think ARIN has come pretty far with this new LRSA, trying to
> protect both legacy holders and the rest of the community.  I 
> appreciate the participation on this list by so many people 
> responsible for legacy address space, when many of the 
> policies developed will not ultimately affect you.  I 
> acknowledge the concession many of you have made, in 
> willingness to support ARIN financially.  I respect the 
> contributions legacy holders have made to the development and growth of
> the Internet.  I hope you can see the Legacy RSA, 
> which was designed to offer greater assurance to the legacy
> holder than the conventional RSA, as a tool for protecting the 
> community's broader interest.
>
> I must be clear, that I do not represent ARIN any more than 
> any other community member when it comes to the LRSA.  I hope
> that everyone with questions about the LRSA will call the 
> Registration Services Help Desk at +1.703.227. 0660 or send 
> email to hostmaster at arin.net, or with specific legal questions, 
> contact ARIN General Counsel, Steve Ryan, at sryan at mwe.com. 
>
>
> Lee
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>   




From JOHN at egh.com  Tue Sep  9 12:20:49 2008
From: JOHN at egh.com (John Santos)
Date: Tue, 9 Sep 2008 12:20:49 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B349459@CL-S-EX-1.stanleyassociates.com>
Message-ID: <1080909121212.10334H-100000@Ives.egh.com>

On Tue, 9 Sep 2008, Howard, W. Lee wrote:

> > > 3. 4(d)(ii) Legacy holder "violate(s) any applicable laws, 
> > statutes or 
> > > regulations, as established by a definitive ruling of a court or 
> > > government agency;"
> > 
> > This is the only clause that I have any problems with, at 
> > least so far.
> > 
> > Maybe the word "applicable" covers this, though IANAL, so I worry!
> 
> Would you check with a lawyer, or discuss your concerns with 
> ARIN's General Counsel?  IANAL either, so I'm reluctant to
> interpret this section too closely.
> 
> I will make the point that ARIN has to comply with laws, 
> government regulations, and court orders.
> 
> > Third is I don't think ARIN should become an instrument of 
> > state suppression of freedom of speach, press, or association.
> 
> While I am suspicious of government persecution, I also think
> it would be inappropriate for ARIN staff or Board to decide to 
> ignore a court order or break a law to defend a principle.  

Which I explicitly *said* in a paragraph you cut.

> We're not competent to evaluate, on behalf of the members and
> community, whether a principle should supersede the law (at 
> least, we're not more competent than the judicial system; let's
> not be in contempt of the courts).  ARIN is not the right
> organization to resist a government gone amok--that's waaay
> outside our mission.

It shouldn't be abetting it either, which is my point.  And
remember, there is more than one government involved.  
> 
> > Perhaps "applicable" covers all these areas, or maybe there 
> > implicitly has to be a court order, with due process, all 
> > possibility of appeals exhausted, etc.
> 
> "definitive" and "applicable" are useful adjectives.
> 
> > > 4. 4(d)(iii) Legacy holder "assist(s) any third party in 
> > engaging in 
> > > any activity prohibited by this Legacy Agreement."
> > 
> > Assuming all protections that apply to the previous section 
> > also apply here, this would be okay.  Otherwise it is the 
> > possibility of an end-run around 4(d)(ii).
> 
> The trick is to prevent the end run around 4(d)(ii) (or other
> naughtiness) by having a third party do your dirty work.
> 

Yes, and that cuts both ways.



> Lee
> 
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From bicknell at ufp.org  Tue Sep  9 12:41:37 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Sep 2008 12:41:37 -0400
Subject: [arin-ppml] A compromise on legacy space?
Message-ID: <20080909164137.GA68583@ussenterprise.ufp.org>


There are many reasons people are interested in legacy space, and
I personally find some level of merit to all of them:

- Updating contact information and/or securing (e.g. via PGP, S/MIME)
  updates to the records.
- Having Legacy Holders pay their "fair share".
- Finding fallow space, and reclaiming it.  [Both the truly fallow,
  e.g. all people/companies associated with it are dead/dissolved,
  and space where someone is still associated, but it is not being
  used.]
- Preventing unfair addressing competition (ISP's giving away a /24
  of their legacy space with a new circuit, no justification
  required.).

As I've also said before, there are multiple subgroups of legacy
space users.  Treating a person with their own personal /24 the
same way a large ISP is treated that has a legacy /8 doesn't make
any sense.  They are different situations, and very different
cost/benefit situations for ARIN and the community.

It seems to me it may be prudent then to divide the group.  I've been
pondering how to do that in a fair manor though, and I think I've come
up with a good idea.  I post it here for everyone else to rip apart.

Group #1:
  Definition: Legacy holders who also hold space covered by a regular
              ARIN RSA.

Group #2
  Definition: All legacy holders not in group #1.

There are a few minor implementation details that may need to appear in
the definition.  For instance, is group one determined by ORG-ID, by
legal entity, or some other definition.  I honestly don't know the
details we could get some input from staff.  The concept though is if
you run a network using both legacy and ARIN assigned space you're in
that group though.

Now, the question is, how do we treat those two groups differently?  My
proposal is also simple:

Group #1:
  Upon the next regular renewal of the ARIN RSA all legacy resources,
  covered by an existing RSA, LRSA, or not covered at all shall be
  rolled under a single, current, ARIN RSA.

Group #2:
  A "Legacy Service Agreement" (I won't use LSA, that's too confusing)
  shall be created.  It should state:
    - ARIN provides services to legacy holders, including but not
      limited to: whois, rdns, uniqueness, public policy meetings,
      mailing lists, and more.
    - The Legacy Holder must pay a fee (fees are not policy, but I'm
      thinking around $100 per year as has been discussed) to continue
      the use of these services.

  The Legacy Services Agreement can be terminated by the legacy holder
  at any time.  Of course, at that time ARIN may cease to provide whois,
  rdns, or any other service.  No revoking of services, no one sided
  termination, etc.  Those two simple ideas, wrapped up in the minimum
  legal language necessary.

Group #1 fixes what I feel are the worst violations of the community
trust.  There are plenty of ISP's with legacy resources and ARIN
assigned resources that have used the legacy ones over the years
to game the system.  At various points in time I have seen first
hand companies giving out resources with no justification, or coming
back to ARIN for new resources without showing they have used their
legacy resources.  I believe this has always been unfair to the
community as a whole, and that it is absurd that a single company
might be able to treat two numbers from the same pool differently
because of when they received them.  They are a global, community
resource and need to be treated as such.

Group #2 doesn't generally have that problem.  It's a bunch of
individuals and small businesses that have never 'come back to the
well'.  They are living in their legacy space and happy to keep
doing so.  There is no fairness issue here, no need to expend
resources harassing this group.  As I've stated before, I strongly
believe it is in both parties interest to have a contract, and also
to have some requirement for periodic touch.

What do people think?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080909/ae31e279/attachment.sig>

From owen at delong.com  Tue Sep  9 14:22:56 2008
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Sep 2008 11:22:56 -0700
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <20080909164137.GA68583@ussenterprise.ufp.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
Message-ID: <A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>

>
> Group #1:
>  Definition: Legacy holders who also hold space covered by a regular
>              ARIN RSA.
>
I'd like to refine this a bit.  I think it would be more appropriate  
to say
"Legacy Holders who are also Subscriber Members of ARIN."

This covers those who have allocations from ARIN (ISPs) while leaving
out those organizations who are end-users. I find it unlikely that end
users (some of which do have legacy+rsa space) fit in the category
you are attempting to include here.

> Group #2
>  Definition: All legacy holders not in group #1.
>
> There are a few minor implementation details that may need to appear  
> in
> the definition.  For instance, is group one determined by ORG-ID, by
> legal entity, or some other definition.  I honestly don't know the
> details we could get some input from staff.  The concept though is if
> you run a network using both legacy and ARIN assigned space you're in
> that group though.
>
Would my proposed re-definition of group 1 solve this?

> Now, the question is, how do we treat those two groups differently?   
> My
> proposal is also simple:
>
> Group #1:
>  Upon the next regular renewal of the ARIN RSA all legacy resources,
>  covered by an existing RSA, LRSA, or not covered at all shall be
>  rolled under a single, current, ARIN RSA.
>
Or what?  What if the group #1 members do not agree to this or
do not want to agree with it?  I don't believe ARIN really has the
authority to do this.  Especially in the case of legacy resources
covered by LRSA.  The LRSA specifically precludes ARIN taking
such an action unilaterally if I understand it correctly.

> Group #2:
>  A "Legacy Service Agreement" (I won't use LSA, that's too confusing)
>  shall be created.  It should state:
>    - ARIN provides services to legacy holders, including but not
>      limited to: whois, rdns, uniqueness, public policy meetings,
>      mailing lists, and more.
>    - The Legacy Holder must pay a fee (fees are not policy, but I'm
>      thinking around $100 per year as has been discussed) to continue
>      the use of these services.
>
>  The Legacy Services Agreement can be terminated by the legacy holder
>  at any time.  Of course, at that time ARIN may cease to provide  
> whois,
>  rdns, or any other service.  No revoking of services, no one sided
>  termination, etc.  Those two simple ideas, wrapped up in the minimum
>  legal language necessary.
>

I think we are applying meta-issues which obscure reality.

Let's talk about what ARIN really provides.  ARIN provides a number
of services, but, the key service at issue is registration of numbers
in a database which assures that no other entity cooperating in the
same system of databases receives the same numbers.

ARIN does not give, lease, transfer, or otherwise grant numbers
to people.  Integers are integers and regardless of what ARIN
does, every member of society remains perfectly within their
rights to use any integer they choose for any lawful purpose they
wish.

We have (perhaps mistakenly) referred to these registrations
as assignments and/or allocations, but, we aren't really assigning
or allocating integers.  We are assigning or allocating slots in
one particular database.  The available slots in said database
are a subset of 32 bit integers.  That subset is determined by
a "parent" database which registers (for uniqueness) the entire
set of 32 bit integers, and, which records what subsets of the
entire set have been registered  to which RIR (or other entity
in some rare cases). The "parent" database is operated by IANA.

The only reason the contents of ARIN's database have any
relevance whatsoever is that a large portion of the ISPs
have chosen to cooperate in the RIR system such that they
treat registrations in the various RIR database as the authoritative
source of information they choose to incorporate into routing
policy. ARIN does not control this. ARIN does take this trust
seriously and works hard to avoid violating this trust.

NOTE: I am not advocating for this to occur, but,
If a sufficient critical mass of ISPs were to choose to create
their own registry system, there is little or nothing ARIN
could do about it.

Certainly ARIN would not be able to sue such a competing
registry or the ISPs that choose to cooperate with it
on the basis that they were using integers which "belonged"
to ARIN.

So... If we approach this from the perspective that IP addresses
truly are not property and that ARIN does not issue, assign,
allocate, or otherwise transfer IP addresses from one entity
to another, but, instead, holds a database for a portion of
the IP space in which they record registrations which are
prevented from overlapping with other registrations held
in the ARIN database or the cooperating other RIR/IANA
databases.

Then... We can conclude that ARIN terminating such services
means that those slots become available in the ARIN database.

This means one of two things, depending on how you want
to define the term "reclamation".

If you define "revocation" as marking the space available to
be issued to another entity, then, termination of service almost
automatically becomes reclamation.

If you define "revocation" as ARIN preventing someone from
using a given integer for some particular purpose, then, ARIN
has no ability to reclaim anything.  Never has, and, likely never
will.

Owen



From michael at rancid.berkeley.edu  Tue Sep  9 15:07:45 2008
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 09 Sep 2008 12:07:45 -0700
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
Message-ID: <48C6C981.9030608@rancid.berkeley.edu>

On 09/09/08 11:22, Owen DeLong wrote:
>> Group #1:
>>  Definition: Legacy holders who also hold space covered by a regular
>>              ARIN RSA.
>>
> I'd like to refine this a bit.  I think it would be more appropriate  
> to say
> "Legacy Holders who are also Subscriber Members of ARIN."
> 
> This covers those who have allocations from ARIN (ISPs) while leaving
> out those organizations who are end-users. I find it unlikely that end
> users (some of which do have legacy+rsa space) fit in the category
> you are attempting to include here.

What about other non-profit, government and community-based 
organizations that provide services?  And, of course, what about 
universities?  We are covered by RSA for our IPv6 allocation, but our 
IPv4 space is all legacy, and we certainly don't intend to ask for more. 
  In spirit, I'd hope that we fit more into group 2 than group 1.

Would it make more sense to have the definition refer only to IPv4 
space, and ignore, for the purposes of defining the two groups, any IPv6 
RSAs that an entity may have?

>> Now, the question is, how do we treat those two groups differently?   
>> > My
>> > proposal is also simple:
>> >
>> > Group #1:
>> >  Upon the next regular renewal of the ARIN RSA all legacy resources,
>> >  covered by an existing RSA, LRSA, or not covered at all shall be
>> >  rolled under a single, current, ARIN RSA.
>> >
> Or what?  What if the group #1 members do not agree to this or
> do not want to agree with it?  I don't believe ARIN really has the
> authority to do this.  Especially in the case of legacy resources
> covered by LRSA.  The LRSA specifically precludes ARIN taking
> such an action unilaterally if I understand it correctly.

In my case, I suspect state governments and legislatures may have 
something to say about this.  Given the laws of California as they apply 
to contracts with state- and state-supported-agencies, I think there 
might be legal issues in forcing legacy resources into a regular RSA. 
But, of course, IANAL.

michael


From jhg at omsys.com  Tue Sep  9 15:16:31 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Tue, 09 Sep 2008 12:16:31 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48C69C5F.1090002@cjbsys.bdb.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40B348FF1@CL-S-EX-1.stanleyassociates.com>
	<48C69C5F.1090002@cjbsys.bdb.com>
Message-ID: <4midc4p7u5d2f8aehj19rc7buo1fu0g3uk@4ax.com>

On Tue, 09 Sep 2008 11:55:11 -0400, Cliff Bedore <cliffb at cjbsys.bdb.com> 
wrote:

>I'm not trying to be too picky but "silence gives consent" and I'm not
>consenting yet.  Repeating my comments of earlier, if ARIN is trying to
>formalize relationships with legacy holders, it can be done in a much
>less restrictive manner than the current LRSA.  If they're trying to
>recover unused/lost address space, there is no need for the LRSA since
>per above, people who have it will only be encouraged to return it and
>those who have disappeared from the grid and don't answer any requests
>from ARIN will obviously not have any agreement with ARIN.  It seems odd
>that the people who are most willing to participate face the most
>onerous sanctions.

+1.  Well said.

--JHG <jhg at omsys.com>


From jr at jrw.org  Tue Sep  9 15:24:49 2008
From: jr at jrw.org (J. R. Westmoreland)
Date: Tue, 9 Sep 2008 13:24:49 -0600
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <20080909164137.GA68583@ussenterprise.ufp.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
Message-ID: <004d01c912b1$bd228fc0$3767af40$@org>

Leo,

I'm in agreement with your idea but ...
I still have a hard time choking down $100 for my /24 address block when
someone, say like my previous employer, pays that same $100 for an address
space /16, 256 times larger than mine.
When I was last there they had two blocks of /24 exposed outside to the net.
That seems to me to be a bigger waste than my /24, which if needed I could
squeeze down by at least half if required. It just seems to be that the cost
should fit the resource usage in some more reasonable way.

As you said, many of the /24 holders are those who are using then personally
or as consultants or small businesses. To them a large fee could be much
harder to handle than a larger company.
I know that mentioning domain service is not exactly mixing apples and
apples but ...
If you have 25 domains you don't just pay one fee you pay a fee for each
resource you hold.
Shouldn't something like this be on the table as well? I fully understand
that there are many resource holders that could take offense but I still
can't help wondering if this might not be a more fair distribution of costs.

If something like this were in place, I'd obtain, read, sign and pay
instantly with no further issue.
I check my contact information when ever it needs to be updated. Hence, the
reason I was subscribed to this list.
My data was up-to-date and I could be contacted as required by the original
rules put in place when I received my block.

Regards,
J. R.

--------------------
J. R. Westmoreland
E-mail: jr at jrw.org


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Leo Bicknell
Sent: Tuesday, September 09, 2008 10:42 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] A compromise on legacy space?


There are many reasons people are interested in legacy space, and I
personally find some level of merit to all of them:

- Updating contact information and/or securing (e.g. via PGP, S/MIME)
  updates to the records.
- Having Legacy Holders pay their "fair share".
- Finding fallow space, and reclaiming it.  [Both the truly fallow,
  e.g. all people/companies associated with it are dead/dissolved,
  and space where someone is still associated, but it is not being
  used.]
- Preventing unfair addressing competition (ISP's giving away a /24
  of their legacy space with a new circuit, no justification
  required.).

As I've also said before, there are multiple subgroups of legacy space
users.  Treating a person with their own personal /24 the same way a large
ISP is treated that has a legacy /8 doesn't make any sense.  They are
different situations, and very different cost/benefit situations for ARIN
and the community.

It seems to me it may be prudent then to divide the group.  I've been
pondering how to do that in a fair manor though, and I think I've come up
with a good idea.  I post it here for everyone else to rip apart.

Group #1:
  Definition: Legacy holders who also hold space covered by a regular
              ARIN RSA.

Group #2
  Definition: All legacy holders not in group #1.

There are a few minor implementation details that may need to appear in the
definition.  For instance, is group one determined by ORG-ID, by legal
entity, or some other definition.  I honestly don't know the details we
could get some input from staff.  The concept though is if you run a network
using both legacy and ARIN assigned space you're in that group though.

Now, the question is, how do we treat those two groups differently?  My
proposal is also simple:

Group #1:
  Upon the next regular renewal of the ARIN RSA all legacy resources,
  covered by an existing RSA, LRSA, or not covered at all shall be
  rolled under a single, current, ARIN RSA.

Group #2:
  A "Legacy Service Agreement" (I won't use LSA, that's too confusing)
  shall be created.  It should state:
    - ARIN provides services to legacy holders, including but not
      limited to: whois, rdns, uniqueness, public policy meetings,
      mailing lists, and more.
    - The Legacy Holder must pay a fee (fees are not policy, but I'm
      thinking around $100 per year as has been discussed) to continue
      the use of these services.

  The Legacy Services Agreement can be terminated by the legacy holder
  at any time.  Of course, at that time ARIN may cease to provide whois,
  rdns, or any other service.  No revoking of services, no one sided
  termination, etc.  Those two simple ideas, wrapped up in the minimum
  legal language necessary.

Group #1 fixes what I feel are the worst violations of the community trust.
There are plenty of ISP's with legacy resources and ARIN assigned resources
that have used the legacy ones over the years to game the system.  At
various points in time I have seen first hand companies giving out resources
with no justification, or coming back to ARIN for new resources without
showing they have used their legacy resources.  I believe this has always
been unfair to the community as a whole, and that it is absurd that a single
company might be able to treat two numbers from the same pool differently
because of when they received them.  They are a global, community resource
and need to be treated as such.

Group #2 doesn't generally have that problem.  It's a bunch of individuals
and small businesses that have never 'come back to the well'.  They are
living in their legacy space and happy to keep doing so.  There is no
fairness issue here, no need to expend resources harassing this group.  As
I've stated before, I strongly believe it is in both parties interest to
have a contract, and also to have some requirement for periodic touch.

What do people think?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/



From bill at herrin.us  Tue Sep  9 15:42:49 2008
From: bill at herrin.us (William Herrin)
Date: Tue, 9 Sep 2008 15:42:49 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <004d01c912b1$bd228fc0$3767af40$@org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<004d01c912b1$bd228fc0$3767af40$@org>
Message-ID: <3c3e3fca0809091242p54e443e4p5c62063870a73857@mail.gmail.com>

On Tue, Sep 9, 2008 at 3:24 PM, J. R. Westmoreland <jr at jrw.org> wrote:
> I still have a hard time choking down $100 for my /24 address block when
> someone, say like my previous employer, pays that same $100 for an address
> space /16, 256 times larger than mine.

J.R.,

If it makes you feel any better, you're both getting about $8000 worth
of service for that $100. The service isn't from ARIN, but its enabled
by ARIN's recognition of your address block and is above and beyond
the service you could get connecting to the Internet with your ISP's
IP addresses.

http://bill.herrin.us/network/bgpcost.html

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bicknell at ufp.org  Tue Sep  9 15:48:30 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Sep 2008 15:48:30 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C6C981.9030608@rancid.berkeley.edu>
	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
	<48C6C981.9030608@rancid.berkeley.edu>
	<20080909164137.GA68583@ussenterprise.ufp.org>
	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
Message-ID: <20080909194830.GA83487@ussenterprise.ufp.org>

In a message written on Tue, Sep 09, 2008 at 11:22:56AM -0700, Owen DeLong wrote:
> This covers those who have allocations from ARIN (ISPs) while leaving
> out those organizations who are end-users. I find it unlikely that end
> users (some of which do have legacy+rsa space) fit in the category
> you are attempting to include here.

I am open to discussion, however my initial reaction is they should
be included.  For instance, I believe at least one of the Class A
holding private companies also has ARIN assigned space (due to
mergers, I think).  There are plenty of universities that have a
pre-ARIN /19 and a ARIN /19, as an example too, it makes no sense to
treat the two halves of their address space differently.

> >Group #1:
> > Upon the next regular renewal of the ARIN RSA all legacy resources,
> > covered by an existing RSA, LRSA, or not covered at all shall be
> > rolled under a single, current, ARIN RSA.
> >
> Or what?  What if the group #1 members do not agree to this or
> do not want to agree with it?  I don't believe ARIN really has the
> authority to do this.  Especially in the case of legacy resources
> covered by LRSA.  The LRSA specifically precludes ARIN taking
> such an action unilaterally if I understand it correctly.

While I realize I am making a stretch, everyone in group #1 has
already signed the more restrictive RSA for part of their space.
They have already opted-in to the community.  They have already
agreed, for instance, that their legacy space counts in utilization
requirements when they come back for more space.

Where I grant you there is more of an issue is where a firm has
already signed the LRSA.  In that case there exists two competing
contracts.

However, I have long held as a successor in interest ARIN has the
ability to change the terms on legacy holders, as long as it is done
through the open public policy process.  I think ARIN's position in this
case is defendable; it's hard for an ISP with multiple RSA covered
blocks who's already agreed to part of the terms on their legacy block
to continue to defend it should be something separate, particularly if
the open process says otherwise.

> So... If we approach this from the perspective that IP addresses
> truly are not property and that ARIN does not issue, assign,
> allocate, or otherwise transfer IP addresses from one entity
> to another, but, instead, holds a database for a portion of
> the IP space in which they record registrations which are
> prevented from overlapping with other registrations held
> in the ARIN database or the cooperating other RIR/IANA
> databases.
> 
> Then... We can conclude that ARIN terminating such services
> means that those slots become available in the ARIN database.

Nope.  You have made a stretch I have not.

I believe ARIN can stop providing whois, in-addr.arpa, free acceess
for two members to the public policy meeting and other services to
legacy holders who terminate their contract.  I do not believe ARIN
can dump the entry from their internal database or assign the same
numbers to someone else.

There is a difference between not providing services to non-paying,
non-contracted entities and revoking an assignment.  Revocation is an
affirmative action that requires a letter to be sent stating "Netblock
abc is no longer yours to use" and putting it back in the pool that may
be given to some new requester.  I do not advocate revocation in any
circumstances.

In a message written on Tue, Sep 09, 2008 at 12:07:45PM -0700, Michael Sinatra wrote:
> What about other non-profit, government and community-based 
> organizations that provide services?  And, of course, what about 
> universities?  We are covered by RSA for our IPv6 allocation, but our 
> IPv4 space is all legacy, and we certainly don't intend to ask for more. 
>  In spirit, I'd hope that we fit more into group 2 than group 1.
> 
> Would it make more sense to have the definition refer only to IPv4 
> space, and ignore, for the purposes of defining the two groups, any IPv6 
> RSAs that an entity may have?

I have no issues with limiting the entire scope of my original post
to IPv4 only.  Thus group 1 would include any entity with IPv4
addresses under an RSA, and not include IPv6 or ASN holders.

Indeed, that's really what I intended and I was imprecise with my
language.

> In my case, I suspect state governments and legislatures may have 
> something to say about this.  Given the laws of California as they apply 
> to contracts with state- and state-supported-agencies, I think there 
> might be legal issues in forcing legacy resources into a regular RSA. 

This may sound flippant, but I really don't mean it to be...

There are legal issues with everything, including taking no action.
While I want to solicit various legal input from both sides that
should be done towards the end of the community agreement process.
The strength here is the community agreeing to the right action.
I have faith that if we can get 80% of the community behind a
proposal the lawyers can find a way to make it hold up in court
most of the time.

ARIN Counsel has said before they have worked with government to adjust
for specific legal requirements on government agencies, this may be one
of those cases.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080909/e6c0949c/attachment.sig>

From cliffb at cjbsys.bdb.com  Tue Sep  9 15:35:53 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Tue, 09 Sep 2008 15:35:53 -0400
Subject: [arin-ppml] LRSA taking back addresses
Message-ID: <48C6D019.7050803@cjbsys.bdb.com>

Quoting from the ARIN legacy page

"Note that ARIN will not reclaim unutilized address space from legacy 
holders who sign this RSA, nor will ARIN attempt to take away legacy 
resources from organizations who choose not to sign it. However, signing 
the Legacy RSA contractually locks in a set of rights, and thus reduces 
the risk of future change to a minimum."

Note the section that says " nor will ARIN attempt to take away legacy 
resources from organizations who choose not to sign it."  So if I don't 
sign it, my address space is safe but if I sign it and then want to 
terminate for any reason, ARIN can reclaim the addresses.  What's wrong 
with this picture?  At a minimum, the address space should fall back to 
the status of those who don't sign the LRSA at all.

Slightly tongue in cheek, the section "However, signing the Legacy RSA 
contractually locks in a set of rights, and thus reduces the risk of 
future change to a minimum." doesn't sound a whole lot different from 
two guys walking into a neighborhood store and saying "You know there's 
a lot of crime and arson in this area.  If you sign a contract for our 
security service, your risks in this neighborhood will not be as high as 
if you don't sign with us."


Cliff


From bicknell at ufp.org  Tue Sep  9 15:55:19 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Sep 2008 15:55:19 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <004d01c912b1$bd228fc0$3767af40$@org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<004d01c912b1$bd228fc0$3767af40$@org>
Message-ID: <20080909195519.GB83487@ussenterprise.ufp.org>

In a message written on Tue, Sep 09, 2008 at 01:24:49PM -0600, J. R. Westmoreland wrote:
> I still have a hard time choking down $100 for my /24 address block when
> someone, say like my previous employer, pays that same $100 for an address
> space /16, 256 times larger than mine.

The fee is about cost recovery for ARIN (it is a non-profit after
all).  Unfortunately the level of work for a /24 and a /16 are
remarkably similar, both are one entry in whois, both are one set
of NS records in in-addr.arpa, both are one bill to send, one check
to collect.

I would look towards the Board for guidence on fees.  They set fees,
and can get input on what true cost recovery is, including the
appropriate buffers and such.  If they came back and said $25 a
year, I'd be happy.  If they came back and said $250, I'd be happy
too.  If it was made sliding based on the size (as many fees are
today) that's great as well.

My sense is we can get the fees low enough, particularly on group
#2 that they are a non-issue.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080909/c70f9429/attachment.sig>

From dwcarder at wisc.edu  Tue Sep  9 16:32:44 2008
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Tue, 09 Sep 2008 15:32:44 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <20080909164137.GA68583@ussenterprise.ufp.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
Message-ID: <8770E0AA-EDF7-4E08-AD34-F32E30B7BB5C@wisc.edu>


On Sep 9, 2008, at 11:41 AM, Leo Bicknell wrote:
>
> Group #1
...
> coming back to ARIN for new resources without showing they have used  
> their
> legacy resources.

How is this not covered in 4.2.4.1?
"ISPs must have efficiently utilized all previous allocations"

Dale


From cgrundemann at gmail.com  Tue Sep  9 17:07:36 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 9 Sep 2008 15:07:36 -0600
Subject: [arin-ppml] LRSA taking back addresses
In-Reply-To: <48C6D019.7050803@cjbsys.bdb.com>
References: <48C6D019.7050803@cjbsys.bdb.com>
Message-ID: <443de7ad0809091407j586bc822lcf866cb2da4aed2b@mail.gmail.com>

Honest question: How many RSA allocations and assignments have been
revoked and reclaimed by ARIN?  How many for LRSA covered space (I
assume this one is zero as it is a new contract, question is here for
the sake of being thorough)? Is there (or could there be) an available
list of such events that records the size, date, cause, etc?
~Chris

On Tue, Sep 9, 2008 at 1:35 PM, Cliff Bedore <cliffb at cjbsys.bdb.com> wrote:
> Quoting from the ARIN legacy page
>
> "Note that ARIN will not reclaim unutilized address space from legacy
> holders who sign this RSA, nor will ARIN attempt to take away legacy
> resources from organizations who choose not to sign it. However, signing
> the Legacy RSA contractually locks in a set of rights, and thus reduces
> the risk of future change to a minimum."
>
> Note the section that says " nor will ARIN attempt to take away legacy
> resources from organizations who choose not to sign it."  So if I don't
> sign it, my address space is safe but if I sign it and then want to
> terminate for any reason, ARIN can reclaim the addresses.  What's wrong
> with this picture?  At a minimum, the address space should fall back to
> the status of those who don't sign the LRSA at all.
>
> Slightly tongue in cheek, the section "However, signing the Legacy RSA
> contractually locks in a set of rights, and thus reduces the risk of
> future change to a minimum." doesn't sound a whole lot different from
> two guys walking into a neighborhood store and saying "You know there's
> a lot of crime and arson in this area.  If you sign a contract for our
> security service, your risks in this neighborhood will not be as high as
> if you don't sign with us."
>
>
> Cliff
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
Chris Grundemann
www.linkedin.com/in/cgrundemann


From Lee at dilkie.com  Tue Sep  9 18:26:52 2008
From: Lee at dilkie.com (Lee Dilkie)
Date: Tue, 09 Sep 2008 18:26:52 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <20080909195519.GB83487@ussenterprise.ufp.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org>
	<20080909195519.GB83487@ussenterprise.ufp.org>
Message-ID: <48C6F82C.6090108@dilkie.com>



Leo Bicknell wrote:
> In a message written on Tue, Sep 09, 2008 at 01:24:49PM -0600, J. R. Westmoreland wrote:
>   
>> I still have a hard time choking down $100 for my /24 address block when
>> someone, say like my previous employer, pays that same $100 for an address
>> space /16, 256 times larger than mine.
>>     
>
> The fee is about cost recovery for ARIN (it is a non-profit after
> all).  Unfortunately the level of work for a /24 and a /16 are
> remarkably similar, both are one entry in whois, both are one set
> of NS records in in-addr.arpa, both are one bill to send, one check
> to collect.
>
>
>   
I find it hard to believe, in this day of $169 Terabyte drives, that
*one* entry , that doesn't change, in a database would cost anything
close to $1, never mind $100. And I also suspect that the number of
in-addr and whois lookups for my /24 would be a tiny miniscule fraction
of those for a /8 and the bandwidth cost would be next to nothing.

As for all the other services ARIN provides, outreach, meetings, etc,
etc. Frankly, legacy owners don't need, or use, any of it.

Is there an way to create a separate "legacy" RIR to simply maintain
existing legacy records, whois and in-addr. Minimal staff (one would
likely suffice). Let them paid the costs. I find that the arin-ppml list
is obsessed with issues from the 90's while matters for 2010 and beyond
are languishing.

-lee


From jcurran at istaff.org  Tue Sep  9 19:09:54 2008
From: jcurran at istaff.org (John Curran)
Date: Tue, 9 Sep 2008 19:09:54 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C6F82C.6090108@dilkie.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org>
	<20080909195519.GB83487@ussenterprise.ufp.org>
	<48C6F82C.6090108@dilkie.com>
Message-ID: <D3BB9502-D4ED-439A-9764-B5F9AC321BA3@istaff.org>

On Sep 9, 2008, at 6:26 PM, Lee Dilkie wrote:
> ...
> As for all the other services ARIN provides, outreach, meetings, etc,
> etc. Frankly, legacy owners don't need, or use, any of it.
>
> Is there an way to create a separate "legacy" RIR to simply maintain
> existing legacy records, whois and in-addr. Minimal staff (one would
> likely suffice). Let them paid the costs. I find that the arin-ppml  
> list
> is obsessed with issues from the 90's while matters for 2010 and  
> beyond
> are languishing.

The legacy owners are the only ones with a say in the matter,
even for address blocks that they hold.   As was noted earlier,
the whois information serves the community at large, and this
includes folks involved in anti-spam/abuse activities, various
law enforcement types, and the public at large.   Just having
a discussion on the appropriate policies for privacy of WHOIS
data requires significant notice to many stakeholders and an
appropriate public forum to discuss the topic.

A long time from now (in an Internet far far away) there may
be such stability in policies for address space and related
directory matters that it would be possible to "skinny down"
ARIN into very simple registry function.  There would remain
a good question of how to meet the educational & outreach
aspects of ARIN's mission, but that's fairly straightforward
to handle in related organization or in a fee/service model.

Until that time, there's no particular reason that legacy
address holders should have any different treatment than
the many holders of the many end-user assignments that also
haven't changed over the years, and all of the above need
a fair and open policy forum even for maintenance of the
status quo.

/John
(personal sentiment only)



From bicknell at ufp.org  Tue Sep  9 19:16:49 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Sep 2008 19:16:49 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C6F82C.6090108@dilkie.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<004d01c912b1$bd228fc0$3767af40$@org>
	<20080909195519.GB83487@ussenterprise.ufp.org>
	<48C6F82C.6090108@dilkie.com>
Message-ID: <20080909231649.GA97181@ussenterprise.ufp.org>

In a message written on Tue, Sep 09, 2008 at 06:26:52PM -0400, Lee Dilkie wrote:
> > The fee is about cost recovery for ARIN (it is a non-profit after
> > all).  Unfortunately the level of work for a /24 and a /16 are
> > remarkably similar, both are one entry in whois, both are one set
> > of NS records in in-addr.arpa, both are one bill to send, one check
> > to collect.
>
> I find it hard to believe, in this day of $169 Terabyte drives, that
> *one* entry , that doesn't change, in a database would cost anything
> close to $1, never mind $100. And I also suspect that the number of
> in-addr and whois lookups for my /24 would be a tiny miniscule fraction
> of those for a /8 and the bandwidth cost would be next to nothing.

If the Board were to say the feed schedule for /24 assignments is
$5 per year (which is entirely possible) would you then be happy
with the proposal?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080909/c8fb24f3/attachment.sig>

From jcurran at istaff.org  Tue Sep  9 19:20:51 2008
From: jcurran at istaff.org (John Curran)
Date: Tue, 9 Sep 2008 19:20:51 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <D3BB9502-D4ED-439A-9764-B5F9AC321BA3@istaff.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org>
	<20080909195519.GB83487@ussenterprise.ufp.org>
	<48C6F82C.6090108@dilkie.com>
	<D3BB9502-D4ED-439A-9764-B5F9AC321BA3@istaff.org>
Message-ID: <5B572A90-7921-40C2-B484-2BBA1DA7B67B@istaff.org>

On Sep 9, 2008, at 7:09 PM, John Curran wrote:
>
> The legacy owners are the only ones with a say in the matter,

Should read "The legacy owners ARE NOT the only ones ..."

Mea culpa,
/John


From jr at jrw.org  Tue Sep  9 21:44:24 2008
From: jr at jrw.org (J. R. Westmoreland)
Date: Tue, 9 Sep 2008 19:44:24 -0600
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <20080909231649.GA97181@ussenterprise.ufp.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org>	<20080909195519.GB83487@ussenterprise.ufp.org>	<48C6F82C.6090108@dilkie.com>
	<20080909231649.GA97181@ussenterprise.ufp.org>
Message-ID: <000c01c912e6$c40c2c80$4c248580$@org>

For my agreement $25 would be fair.
If you can make that happen, sign me up. <smile>

--------------------
J. R. Westmoreland
E-mail: jr at jrw.org


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Leo Bicknell
Sent: Tuesday, September 09, 2008 5:17 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] A compromise on legacy space?

In a message written on Tue, Sep 09, 2008 at 06:26:52PM -0400, Lee Dilkie
wrote:
> > The fee is about cost recovery for ARIN (it is a non-profit after 
> > all).  Unfortunately the level of work for a /24 and a /16 are 
> > remarkably similar, both are one entry in whois, both are one set of 
> > NS records in in-addr.arpa, both are one bill to send, one check to 
> > collect.
>
> I find it hard to believe, in this day of $169 Terabyte drives, that
> *one* entry , that doesn't change, in a database would cost anything 
> close to $1, never mind $100. And I also suspect that the number of 
> in-addr and whois lookups for my /24 would be a tiny miniscule 
> fraction of those for a /8 and the bandwidth cost would be next to
nothing.

If the Board were to say the feed schedule for /24 assignments is
$5 per year (which is entirely possible) would you then be happy with the
proposal?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/



From jhg at omsys.com  Tue Sep  9 22:39:42 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Tue, 09 Sep 2008 19:39:42 -0700
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <000c01c912e6$c40c2c80$4c248580$@org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org>	<20080909195519.GB83487@ussenterprise.ufp.org>	<48C6F82C.6090108@dilkie.com>
	<20080909231649.GA97181@ussenterprise.ufp.org>
	<000c01c912e6$c40c2c80$4c248580$@org>
Message-ID: <0icec4tdmdn7lvquees7v41o15sd9lp0sa@4ax.com>

On Tue, 9 Sep 2008 19:44:24 -0600, "J. R. Westmoreland" 
<jr at jrw.org> wrote:

>For my agreement $25 would be fair.

+1.  That puts it in the same class as domain-name fees,
and makes it a non-issue.

Also, if it doesn't already, ARIN should accept credit
cards, or at least PayPal, for this fee.  That eliminates
the nuisance of getting a PO out to cut a check.

--JHG <jhg at omsys.com>


From kkargel at polartel.com  Wed Sep 10 09:12:52 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 10 Sep 2008 08:12:52 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AE3@mail>

 Well said Owen.  When everyone understands that Arin provides a unique
database entry and not a number the whole paradigm changes.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Tuesday, September 09, 2008 1:23 PM
> To: Leo Bicknell
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] A compromise on legacy space?
> 
> >
> > Group #1:
> >  Definition: Legacy holders who also hold space covered by a regular
> >              ARIN RSA.
> >
> I'd like to refine this a bit.  I think it would be more 
> appropriate to say "Legacy Holders who are also Subscriber 
> Members of ARIN."
> 
> This covers those who have allocations from ARIN (ISPs) while 
> leaving out those organizations who are end-users. I find it 
> unlikely that end users (some of which do have legacy+rsa 
> space) fit in the category you are attempting to include here.
> 
> > Group #2
> >  Definition: All legacy holders not in group #1.
> >
> > There are a few minor implementation details that may need 
> to appear 
> > in the definition.  For instance, is group one determined 
> by ORG-ID, 
> > by legal entity, or some other definition.  I honestly 
> don't know the 
> > details we could get some input from staff.  The concept 
> though is if 
> > you run a network using both legacy and ARIN assigned space 
> you're in 
> > that group though.
> >
> Would my proposed re-definition of group 1 solve this?
> 
> > Now, the question is, how do we treat those two groups 
> differently?   
> > My
> > proposal is also simple:
> >
> > Group #1:
> >  Upon the next regular renewal of the ARIN RSA all legacy 
> resources,  
> > covered by an existing RSA, LRSA, or not covered at all shall be  
> > rolled under a single, current, ARIN RSA.
> >
> Or what?  What if the group #1 members do not agree to this 
> or do not want to agree with it?  I don't believe ARIN really 
> has the authority to do this.  Especially in the case of 
> legacy resources covered by LRSA.  The LRSA specifically 
> precludes ARIN taking such an action unilaterally if I 
> understand it correctly.
> 
> > Group #2:
> >  A "Legacy Service Agreement" (I won't use LSA, that's too 
> confusing)  
> > shall be created.  It should state:
> >    - ARIN provides services to legacy holders, including but not
> >      limited to: whois, rdns, uniqueness, public policy meetings,
> >      mailing lists, and more.
> >    - The Legacy Holder must pay a fee (fees are not policy, but I'm
> >      thinking around $100 per year as has been discussed) 
> to continue
> >      the use of these services.
> >
> >  The Legacy Services Agreement can be terminated by the 
> legacy holder  
> > at any time.  Of course, at that time ARIN may cease to 
> provide whois,  
> > rdns, or any other service.  No revoking of services, no one sided  
> > termination, etc.  Those two simple ideas, wrapped up in 
> the minimum  
> > legal language necessary.
> >
> 
> I think we are applying meta-issues which obscure reality.
> 
> Let's talk about what ARIN really provides.  ARIN provides a 
> number of services, but, the key service at issue is 
> registration of numbers in a database which assures that no 
> other entity cooperating in the same system of databases 
> receives the same numbers.
> 
> ARIN does not give, lease, transfer, or otherwise grant 
> numbers to people.  Integers are integers and regardless of 
> what ARIN does, every member of society remains perfectly 
> within their rights to use any integer they choose for any 
> lawful purpose they wish.
> 
> We have (perhaps mistakenly) referred to these registrations 
> as assignments and/or allocations, but, we aren't really 
> assigning or allocating integers.  We are assigning or 
> allocating slots in one particular database.  The available 
> slots in said database are a subset of 32 bit integers.  That 
> subset is determined by a "parent" database which registers 
> (for uniqueness) the entire set of 32 bit integers, and, 
> which records what subsets of the entire set have been 
> registered  to which RIR (or other entity in some rare 
> cases). The "parent" database is operated by IANA.
> 
> The only reason the contents of ARIN's database have any 
> relevance whatsoever is that a large portion of the ISPs have 
> chosen to cooperate in the RIR system such that they treat 
> registrations in the various RIR database as the 
> authoritative source of information they choose to 
> incorporate into routing policy. ARIN does not control this. 
> ARIN does take this trust seriously and works hard to avoid 
> violating this trust.
> 
> NOTE: I am not advocating for this to occur, but, If a 
> sufficient critical mass of ISPs were to choose to create 
> their own registry system, there is little or nothing ARIN 
> could do about it.
> 
> Certainly ARIN would not be able to sue such a competing 
> registry or the ISPs that choose to cooperate with it on the 
> basis that they were using integers which "belonged"
> to ARIN.
> 
> So... If we approach this from the perspective that IP 
> addresses truly are not property and that ARIN does not 
> issue, assign, allocate, or otherwise transfer IP addresses 
> from one entity to another, but, instead, holds a database 
> for a portion of the IP space in which they record 
> registrations which are prevented from overlapping with other 
> registrations held in the ARIN database or the cooperating 
> other RIR/IANA databases.
> 
> Then... We can conclude that ARIN terminating such services 
> means that those slots become available in the ARIN database.
> 
> This means one of two things, depending on how you want to 
> define the term "reclamation".
> 
> If you define "revocation" as marking the space available to 
> be issued to another entity, then, termination of service 
> almost automatically becomes reclamation.
> 
> If you define "revocation" as ARIN preventing someone from 
> using a given integer for some particular purpose, then, ARIN 
> has no ability to reclaim anything.  Never has, and, likely 
> never will.
> 
> Owen
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080910/4c3f8bee/attachment.bin>

From kkargel at polartel.com  Wed Sep 10 09:30:12 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 10 Sep 2008 08:30:12 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C6C981.9030608@rancid.berkeley.edu>
References: <20080909164137.GA68583@ussenterprise.ufp.org><A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
	<48C6C981.9030608@rancid.berkeley.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AE4@mail>

 
> In my case, I suspect state governments and legislatures may 
> have something to say about this.  Given the laws of 
> California as they apply to contracts with state- and 
> state-supported-agencies, I think there might be legal issues 
> in forcing legacy resources into a regular RSA. 
> But, of course, IANAL.
> 
> michael

When it comes down to it nobody will force anybody to do anything.  People
without any agreement or who do not keep registration data current can
continue to use whatever numbers they want, they just won't be in the
database.  ARIN cannot force Legacy users to enter into an agreement, and
the Legacy users cannot force ARIN to list them in the database.  

Networks (the majority of the Internet community) who choose to use this
database will be able to easily communicate with others who use this
database.  If someone wants to communicate with a network that is not in the
database their administrator is free to make a manual route table entry.  So
long as everyone between the two endpoints has the same entry it will route
just fine.

The ARIN database is not a magic thing, it is not a law, it is not even a
requirement.  It is just a tool we use to make our lives easier so we don't
have to type route entries in to our routers or maintain our own database.
ARIN is just a service to save us all work. It is useful because many
networks choose to use it.  You could route just fine without ARIN if you
could just exchange route entries with everyone you need to communicate with
and all their transit peers.

The reason this functions and works is cooperative anarchy. This is a good
thing. Nobody forces anyone to do anything and if you cooperate and play by
negotiated guidelines (RFC's) then everything works.  Simple, cheap and
effective.  What could be better?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080910/133bce34/attachment.bin>

From bjohnson at drtel.com  Wed Sep 10 09:29:24 2008
From: bjohnson at drtel.com (Brian Johnson)
Date: Wed, 10 Sep 2008 08:29:24 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C6F82C.6090108@dilkie.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org><20080909195519.GB83487@ussenterprise.ufp.org>
	<48C6F82C.6090108@dilkie.com>
Message-ID: <29A54911243620478FF59F00EBB12F470135CC6C@ex01.drtel.lan>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Lee Dilkie
> Sent: Tuesday, September 09, 2008 5:27 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] A compromise on legacy space?

<snip>

> I find it hard to believe, in this day of $169 Terabyte drives, that
> *one* entry , that doesn't change, in a database would cost anything
> close to $1, never mind $100. And I also suspect that the number of
> in-addr and whois lookups for my /24 would be a tiny miniscule
fraction
> of those for a /8 and the bandwidth cost would be next to nothing.
> 
> As for all the other services ARIN provides, outreach, meetings, etc,
> etc. Frankly, legacy owners don't need, or use, any of it.
> 
> Is there an way to create a separate "legacy" RIR to simply maintain
> existing legacy records, whois and in-addr. Minimal staff (one would
> likely suffice). Let them paid the costs. I find that the arin-ppml
> list
> is obsessed with issues from the 90's while matters for 2010 and
beyond
> are languishing.
> 
> -lee

In response to Lee, I am still wondering why, other than IPv4
exhaustion, ARIN even needs to do anything with legacy space. Why not
just put them in a box and set them in a closet. Provide them no
services except entries saying that these are legacy assignments... good
luck, if any entries at all.  I would like to see how soon people start
black-hole routing ranges and blocking access for legacy holders to
their networks due to possible abuse.

As a regional provider, I would block any questionable access from
networks without valid contact details readily available. One of my
resources is IP based WHOIS. It could be possible that in the event of
malicious traffic from Lee's network, I would block access to my network
and/or other providers may do the same. This may inspire the legacy
space holders to either get in the boat, or build their own. I think
ARIN would likely be less costly, but have done no research to support
that claim.

I also thought legacy holders always boasted that they were among the
creators/innovators of the Internet. Lee's statements indicate a
stagnant thought pattern. That the Internet is what it is and that's it.
It appears to me that ARIN membership is now taking over the innovator
role for the Internet and that some/most legacy holders are more of a
barrier than a player/enabler/innovator.

The good news is that there will be no legacy space in IPv6. If/when we
move to IPv6 this is a non-issue.

Just my 2 cents. Flame on.

- Brian


From stephen at sprunk.org  Wed Sep 10 10:37:21 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 10 Sep 2008 09:37:21 -0500
Subject: [arin-ppml] LRSA taking back addresses
In-Reply-To: <48C6D019.7050803@cjbsys.bdb.com>
References: <48C6D019.7050803@cjbsys.bdb.com>
Message-ID: <48C7DBA1.6050308@sprunk.org>

Cliff Bedore wrote:
> Quoting from the ARIN legacy page
>
> "Note that ARIN will not reclaim unutilized address space from legacy holders who sign this RSA, nor will ARIN attempt to take away legacy resources from organizations who choose not to sign it. However, signing the Legacy RSA contractually locks in a set of rights, and thus reduces the risk of future change to a minimum."
>
> Note the section that says " nor will ARIN attempt to take away legacy resources from organizations who choose not to sign it."  So if I don't sign it, my address space is safe but if I sign it and then want to terminate for any reason, ARIN can reclaim the addresses.  What's wrong with this picture? 

That is the situation today (a point I think the FAQ doesn't make 
clear), but future policy may change.  For instance, next year, ARIN 
could adopt a proposal to revoke all legacy space.  Signing an LRSA 
before that happened would contractually prevent ARIN from applying that 
policy to you.

> At a minimum, the address space should fall back to the status of those who don't sign the LRSA at all.
>   

I'd prefer that approach, actually.  If a legacy holder doesn't abide by 
the terms of the LRSA, their protection should simply terminate and 
services should revert to the status of anyone else who never signed the 
LRSA -- which, by that point, might mean total loss of services or even 
revocation or it might just mean the same ambiguous status quo as 
today.  If I were depending on those resources for my business, I'd find 
that worth $100/yr.

> Slightly tongue in cheek, the section "However, signing the Legacy RSA contractually locks in a set of rights, and thus reduces the risk of future change to a minimum." doesn't sound a whole lot different from two guys walking into a neighborhood store and saying "You know there's a lot of crime and arson in this area.  If you sign a contract for our security service, your risks in this neighborhood will not be as high as if you don't sign with us."
>   

That's only illegal if the crime is caused by the same organization as 
the folks offering "protection".  ARIN failing to provide services you 
haven't paid for, however, is not a crime.  Lots of companies offer you 
the ability to lock in today's rate with a contract to protect against 
potential rate hikes in the future, and that's perfectly legal.  Lots of 
legitimate security companies will offer you protection against crime in 
addition to the minimal protection provided by the police.

S


From stephen at sprunk.org  Wed Sep 10 10:46:58 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 10 Sep 2008 09:46:58 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <20080909194830.GA83487@ussenterprise.ufp.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>	<48C6C981.9030608@rancid.berkeley.edu>	<20080909164137.GA68583@ussenterprise.ufp.org>	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
	<20080909194830.GA83487@ussenterprise.ufp.org>
Message-ID: <48C7DDE2.10306@sprunk.org>

Leo Bicknell wrote:
> I believe ARIN can stop providing whois, in-addr.arpa, free acceess
> for two members to the public policy meeting and other services to
> legacy holders who terminate their contract. 

There we agree.  I'd also say ARIN could do the same for any legacy 
resources held by anyone who has not signed a contract at all.

> I do not believe ARIN can dump the entry from their internal database or assign the same numbers to someone else.
>   

I do not see any law or contract that would prevent ARIN from assigning 
or allocating those numbers to someone else.

Numbers are not property.  ARIN is selling the service of providing 
uniqueness of registration, not numbers.  If the numbers are no longer 
registered to party X, they can be freely assigned or allocated to party Y.

> I have no issues with limiting the entire scope of my original post to IPv4 only.  Thus group 1 would include any entity with IPv4 addresses under an RSA, and not include IPv6 or ASN holders.
>   

Why exclude ASNs?  My employer has legacy IPv4 space but an ARIN ASN.  
Which group do you think we should fall into?  What is the justification 
for either rolling our legacy space under the RSA or keeping the legacy 
space under LRSA while we have an ASN under RSA?  You haven't convinced 
me that either action is fair.

S


From stephen at sprunk.org  Wed Sep 10 11:07:55 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 10 Sep 2008 10:07:55 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <E1822CB4-59D4-4367-B5CB-7021E0B3F28C@multicasttech.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>	<48C6C981.9030608@rancid.berkeley.edu>	<20080909164137.GA68583@ussenterprise.ufp.org>	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
	<20080909194830.GA83487@ussenterprise.ufp.org>
	<48C7DDE2.10306@sprunk.org>
	<E1822CB4-59D4-4367-B5CB-7021E0B3F28C@multicasttech.com>
Message-ID: <48C7E2CB.4000700@sprunk.org>

Marshall Eubanks wrote:
> On Sep 10, 2008, at 10:46 AM, Stephen Sprunk wrote:
>> Leo Bicknell wrote:
>>> I do not believe ARIN can dump the entry from their internal 
>>> database or assign the same numbers to someone else.
>>
>> I do not see any law or contract that would prevent ARIN from 
>> assigning or allocating those numbers to someone else.
>>
>> Numbers are not property.  ARIN is selling the service of providing 
>> uniqueness of registration, not numbers.  If the numbers are no 
>> longer registered to party X, they can be freely assigned or 
>> allocated to party Y.
>
> But how, in that case, do they guarantee uniqueness ?

The guarantee of uniqueness is only among registered numbers, i.e. no 
two organizations can register the same number.  ARIN, like any other 
RIR, has no ability to prevent organizations from using numbers that 
aren't registered to them.

We've seen countless times where orgs pick random numbers in 
"unassigned" space, rather than getting them from their RIR, and there 
is a collision years later when it gets legitimately assigned to someone 
else by an RIR.  Should those numbers be marked as "bad" and never given 
to someone else, so that the squatter is free to use them forever?  
Think about the consequences of that.

S


From JOHN at egh.com  Wed Sep 10 11:10:29 2008
From: JOHN at egh.com (John Santos)
Date: Wed, 10 Sep 2008 11:10:29 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10AE4@mail>
Message-ID: <1080910110511.13222D@Ives.egh.com>


This argument totally ignores what happens if ARIN allocates a
"slot in the database" to someone when the number corresponding
to that slot was allocated by a predecessor to a legacy holder.

You can't make the issue of legacy assignments go away by
sophistry.  It still has to be dealt with.


-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

From arin-ppml at westbrook.com  Wed Sep 10 11:25:14 2008
From: arin-ppml at westbrook.com (Eric Westbrook)
Date: Wed, 10 Sep 2008 09:25:14 -0600
Subject: [arin-ppml] LRSA taking back addresses
In-Reply-To: <48C7DBA1.6050308@sprunk.org>
References: <48C6D019.7050803@cjbsys.bdb.com> <48C7DBA1.6050308@sprunk.org>
Message-ID: <6905ba860809100825o254cdf4s1ef0513ddbbd627e@mail.gmail.com>

On Wed, Sep 10, 2008 at 8:37 AM, Stephen Sprunk <stephen at sprunk.org> wrote:

> That is the situation today (a point I think the FAQ doesn't make
> clear), but future policy may change.  For instance, next year, ARIN
> could adopt a proposal to revoke all legacy space.  Signing an LRSA
> before that happened would contractually prevent ARIN from applying that
> policy to you.


IANAL (although I do often stay at Holiday Inn Express), but that's not how
I read it.

LRSA signatories agree to be bound by all ARIN policy except where
specifically superceded by LRSA terms themselves.  I don't see such a
superceding clause excluding revocation by current or future policy.

If ARIN were to revoke all legacy registrations by policy (without
mentioning an LRSA exclusion)... poof.

Indeed, if ARIN were to make or change any kind of policy under which some
LRSA registration was then subject to revocation...  poof.  The unlikeliness
of such actions might be extremely low, but as long as the mechanism exists,
I think this kind of exposure is what makes legacy holders reluctant to sign
up.

I've been suggesting that the LRSA explicitly do what it sounds like you
feel it already does, that is, assert that protection explicitly.

If anyone can correct my understanding of the language in the LRSA, to the
effect that does indeed protect against this concern, I would be thrilled to
learn about it.

Thanks,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080910/e1d41395/attachment.htm>

From bicknell at ufp.org  Wed Sep 10 11:28:24 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 10 Sep 2008 11:28:24 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C7DDE2.10306@sprunk.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
	<48C6C981.9030608@rancid.berkeley.edu>
	<20080909164137.GA68583@ussenterprise.ufp.org>
	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
	<20080909194830.GA83487@ussenterprise.ufp.org>
	<48C7DDE2.10306@sprunk.org>
Message-ID: <20080910152824.GA59239@ussenterprise.ufp.org>

In a message written on Wed, Sep 10, 2008 at 09:46:58AM -0500, Stephen Sprunk wrote:
> > I do not believe ARIN can dump the entry from their internal database or assign the same numbers to someone else.
> >   
> 
> I do not see any law or contract that would prevent ARIN from assigning 
> or allocating those numbers to someone else.

There is no law.  As for contract, I believe there is an implied
contract here.  ARIN is a successor in interest to contracts made
between ARINs precedessors and those who received legacy space.

The debate isn't so much about is there or is there not a contract,
from a legal perspective if two people agree to something there is
a contract, perhaps just a verbal one.  The debate is what the terms
of that contract are; and what the obligations are on both sides.

Setting aside my own personal views I attepted to come up with a
compromise that all sides could accept.  To that end I think it's
not unreasonable to accept the premise that legacy records were
assigned "indefinately", and thus should not be "revoked" in the
general case.  Not wanting to purchase ARIN services is not grounds
to revoke.  Fraud against ARIN (as a successor in interest) would
be grounds to revoke; as I think you can argue the original contract
implied you didn't lie to the person you received space from (that's
pretty standard in all contracts, anyway).

> > I have no issues with limiting the entire scope of my original post to IPv4 only.  Thus group 1 would include any entity with IPv4 addresses under an RSA, and not include IPv6 or ASN holders.
> >   
> 
> Why exclude ASNs?  My employer has legacy IPv4 space but an ARIN ASN.  
> Which group do you think we should fall into?  What is the justification 
> for either rolling our legacy space under the RSA or keeping the legacy 
> space under LRSA while we have an ASN under RSA?  You haven't convinced 
> me that either action is fair.

Because it's a compromise.  I am looking at this from the perspective
of what will help the Internet community as a whole.  There are
plenty of individuals who have a /24 and an ASN from the legacy
days.  The effort, on both sides, is high relative to the payoff.

So I lookied for an objective criteria that made the effort by the
legacy holder and ARIN proportional the the benefit to the community.
I believe drawing the line at people who have come back for more IPv4
space is a good line to draw.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080910/10cb4736/attachment.sig>

From stephen at sprunk.org  Wed Sep 10 11:46:31 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 10 Sep 2008 10:46:31 -0500
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <mku6c45m78ke18ol91s81jhjasm0s9rjr6@4ax.com>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C35EDE.5070902@sprunk.org>
	<mku6c45m78ke18ol91s81jhjasm0s9rjr6@4ax.com>
Message-ID: <48C7EBD7.1050008@sprunk.org>

Jeremy H. Griffith wrote:
> On Sat, 06 Sep 2008 23:55:58 -0500, Stephen Sprunk <stephen at sprunk.org> wrote:
>   
>> Jeremy H. Griffith wrote:    
>>     
>>> That's not where I start from.  I start from the belief that a "successor" is necessarily bound to respect the acts of its "predecessors", which issued the legacy resources under terms that were very different from those now being offered:
>>>
>>> *  No possibility of return on an involuntary basis.
>>>    This was essential to encourage us to do the work
>>>    that led to the current Internet.
>>>   
>>>       
>> There was no statement either way about the basis on which addresses were assigned because, at the time, nobody could conceive that we'd actually run out of addresses and need any of them back.
>>     
>
> Exactly.  So there was no such return requirement made.
>   

Nor was there any promise of registration services in perpetuity, nor 
that the numbers could be used on the Internet (which was between the 
user and either ARPA or DDN at the time, between the user and their 
ISP(s) today).

> I license software.  If my license does not specify a time limit, which it does not, it is "in perpetuity" by default.  If I were to sell the product to another company, they could *not* go back to the existing users and demand an annual subscription fee, saying that if it were not paid, their right to use the software would end.
>   

That's because a license is property, created by a contract.  Numbers 
are not property, and you have no _contract_ guaranteeing they'd be 
registered to you nor preventing them from being registered to anyone else.

>>> *  No fees, even though essentially the same services
>>>    for which fees are now deemed appropriate were in
>>>    existence at that time.
>>>   
>>>       
>> That is because, prior to ARIN's creation, number registration services 
>> were subsidized by government grants and then domain registration fees 
>> -- fees that were imposed on domains that had been originally been 
>> granted on the same unspecified basis as numbers.  Like it or not, there 
>> _is_ precedent for imposing fees on previously "free" registrations.  
>>     
>
> Yes, and when it was done for domains, I was not happy.  But I went along with it... which may have been a mistake.
>   

Someone has to pay for the services.  When DoD/DoC stopped paying the 
bills, that responsibility falls on you.  The ARIN community has, so 
far, chosen to give you charity by covering your bills for you.

>> The only reason it hasn't been done in the ARIN region for numbers so 
>> far (unlike other regions) is that so far the community hasn't chosen to 
>> impose them.
>>     
>
> There are limits to what the community can choose to do.  For example, it cannot choose to walk into my office and take away my hardware on the grounds that it's using the community network... 

Taking someone else's property is a crime.  Numbers are not property, 
though, nor can they be taken away from you.  However, the service of 
registration _can_, and since you're not paying for it, deciding not to 
give it to you for free would be perfectly legal -- not theft.

> I don't think any of us really wants to have these particular limits, around number assignment, determined by the Federal court system, but that would be the final arbiter if we cannot agree among ourselves.  All of us.
>   

Unanimous agreement is not required for the policy process, and ARIN's 
counsel would not let a proposal be adopted (or let ARIN take any other 
controversial action) if he did not feel he could defend it successfully 
in court.

2007-14 is the only proposal I'm aware of to date that mentions revoking 
legacy resources (and even then, only unused ones), and counsel did not 
object to it, so I must assume there are no significant legal problems 
there.  Either way, we have been told many times to let counsel (and the 
BoT) worry about that after the community reaches consensus.

>>> Is ARIN going to respect the terms of our previous contract, or not?  (The contract does not have to be written to be a contract, as I hope you know.)  
>>>       
>> Even a verbal contract requires that one party receive consideration of 
>> some sort in return for performing or not performing some act.  
>>     
>
> Not all considerations are cash.

Correct; that's why I wrote "consideration of some sort".

> One condition on the original legacy assignment, IIRC, was to keep contact info current.  I've done that.

Thank you.  However, that does not guarantee you free registration 
services in perpetuity.

> And I'd have no problem with ARIN proceeding to identify those who are no longer at their contact addresses, and recovering their numbers if they were unreachable.
>   

That is one of the goals of 2007-14.  I have no desire to go any further 
than that, nor do I sense than ARIN staff want to.  However, that 
doesn't mean that they are legally prevented from doing so, at some 
point in the future, unless you sign an LRSA.

>> You have no contract with ARIN, and it would be completely legal for 
>> ARIN to stop providing registration services to organizations that 
>> are not paying for them.  
>>     
>
> Would it, now?  Or would it violate ARIN's contract with IANA?
>   

I haven't seen those contracts, so I don't know.  However, given that 
other RIRs have imposed fees on legacy holders, and presumably cut off 
services to those that didn't pay, I don't see that IANA would have a 
problem with ARIN doing the same.

>> I do not think that any court (or jury) would find that deciding (or even 
>> threatening) not to provide you services that you did not pay for was 
>> unlawful.
>>     
>
> Very cute.   But rather disingenuous, don't you think?
>
> I presume the "services" I am provided are IP whois and in-addr, right?  But these services benefit everyone *except* the registrant, who already knows who he is.  In fact, they impose a cost on the registrant, that of processing thousands of spams a day that might not be arriving if it were not for these services.  The real beneficiary is the community itself.
>   

_You_ benefit from those services too, because it's unlikely any ISP 
would accept those addresses from you for use on the public Internet 
without being listed in WHOIS as registered to you.  You also benefit 
from those addresses not being registered to anyone else.

You are correct that rDNS and WHOIS are mainly for the benefit of others 
in the community, which is why (so far) the community has agreed to pick 
up the tab.  However, that does not an obligation make.

>> I've noticed very little anti-legacy vitriol on PPML; most of it comes from the legacy holders themselves and is directed at strawmen that have not actually made an appearance.
>>     
>
> Oh please.  I don't want to exhume all those dead bodies, but even in the last month we've been told that the "elephant in the room" is that those legacy people are just waiting to sell their numbers for the highest price
> they can get.  When the truth is, I doubt if *any* of us want to sell them at all... we just want to continue the "quiet enjoyment" we've had of them all these years.  ;-)
>   

What about all the folks holding on to space, neither using it nor 
willing to return it (for no return)?  There has to be some financial 
motivation there.  Sure, IP resources have zero holding cost today, but 
I bet many of those orgs would be happy to pay $100/yr to hold on to 
their class A/B networks until they could sell them -- assuming a 
transfer proposal passes.  If none does, it's still a trivial cost.

Still, I don't see "vitriol" for such folks; most of us would do the 
same in their shoes.  IMHO, the true vitriol is directed at speculators 
who would trade in blocks (buying, not just selling), destabilizing the 
market.

S


From tme at multicasttech.com  Wed Sep 10 10:49:28 2008
From: tme at multicasttech.com (Marshall Eubanks)
Date: Wed, 10 Sep 2008 10:49:28 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C7DDE2.10306@sprunk.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>	<48C6C981.9030608@rancid.berkeley.edu>	<20080909164137.GA68583@ussenterprise.ufp.org>	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
	<20080909194830.GA83487@ussenterprise.ufp.org>
	<48C7DDE2.10306@sprunk.org>
Message-ID: <E1822CB4-59D4-4367-B5CB-7021E0B3F28C@multicasttech.com>


On Sep 10, 2008, at 10:46 AM, Stephen Sprunk wrote:

> Leo Bicknell wrote:
>> I believe ARIN can stop providing whois, in-addr.arpa, free acceess
>> for two members to the public policy meeting and other services to
>> legacy holders who terminate their contract.
>
> There we agree.  I'd also say ARIN could do the same for any legacy
> resources held by anyone who has not signed a contract at all.
>
>> I do not believe ARIN can dump the entry from their internal  
>> database or assign the same numbers to someone else.
>>
>
> I do not see any law or contract that would prevent ARIN from  
> assigning
> or allocating those numbers to someone else.
>
> Numbers are not property.  ARIN is selling the service of providing
> uniqueness of registration, not numbers.  If the numbers are no longer
> registered to party X, they can be freely assigned or allocated to  
> party Y.
>


But how, in that case, do they guarantee uniqueness ?

Regards
Marshall

>> I have no issues with limiting the entire scope of my original post  
>> to IPv4 only.  Thus group 1 would include any entity with IPv4  
>> addresses under an RSA, and not include IPv6 or ASN holders.
>>
>
> Why exclude ASNs?  My employer has legacy IPv4 space but an ARIN ASN.
> Which group do you think we should fall into?  What is the  
> justification
> for either rolling our legacy space under the RSA or keeping the  
> legacy
> space under LRSA while we have an ASN under RSA?  You haven't  
> convinced
> me that either action is fair.
>
> S
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From ppml at rs.seastrom.com  Wed Sep 10 11:49:35 2008
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Wed, 10 Sep 2008 11:49:35 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <0icec4tdmdn7lvquees7v41o15sd9lp0sa@4ax.com> (Jeremy H.
	Griffith's message of "Tue, 09 Sep 2008 19:39:42 -0700")
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<004d01c912b1$bd228fc0$3767af40$@org>
	<20080909195519.GB83487@ussenterprise.ufp.org>
	<48C6F82C.6090108@dilkie.com>
	<20080909231649.GA97181@ussenterprise.ufp.org>
	<000c01c912e6$c40c2c80$4c248580$@org>
	<0icec4tdmdn7lvquees7v41o15sd9lp0sa@4ax.com>
Message-ID: <86hc8o0zn4.fsf@seastrom.com>


"Jeremy H. Griffith" <jhg at omsys.com> writes:

> Also, if it doesn't already, ARIN should accept credit
> cards, or at least PayPal, for this fee.  That eliminates
> the nuisance of getting a PO out to cut a check.

This has been the case for ages now.

http://www.arin.net/billing/index.html

   Submission of Payment
   When completing ARIN's online billing forms, organizations may choose
   between two payment options:

      Immediate online payment by credit card (American Express, Discover,
      MasterCard, and Visa)
      ...
      Receive an invoice for payment by check or wire transfer

I don't think they take PayPal, e-gold, Linden Dollars, or any other
form of non-traditional payment, though...  :-)

That said, I think quibbling about $25 vs $100 for the yearly fee is
really kind of missing the point - ARIN has been charging $100/year
for directory services for ASNs for a long time.  That's $100/year to
keep your OrgID warm and make contact periodically, it has nothing to
do with the size of the allocation or number of objects your OrgID
points at...  if you (like I) have two legacy /24s and a legacy ASN,
your cost per year is still $100.

-r



From stephen at sprunk.org  Wed Sep 10 12:06:54 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 10 Sep 2008 11:06:54 -0500
Subject: [arin-ppml] LRSA taking back addresses
In-Reply-To: <6905ba860809100825o254cdf4s1ef0513ddbbd627e@mail.gmail.com>
References: <48C6D019.7050803@cjbsys.bdb.com> <48C7DBA1.6050308@sprunk.org>
	<6905ba860809100825o254cdf4s1ef0513ddbbd627e@mail.gmail.com>
Message-ID: <48C7F09E.7080406@sprunk.org>

Eric Westbrook wrote:
> On Wed, Sep 10, 2008 at 8:37 AM, Stephen Sprunk <stephen at sprunk.org 
> <mailto:stephen at sprunk.org>> wrote:
>
>     That is the situation today (a point I think the FAQ doesn't make
>     clear), but future policy may change.  For instance, next year, ARIN
>     could adopt a proposal to revoke all legacy space.  Signing an LRSA
>     before that happened would contractually prevent ARIN from
>     applying that
>     policy to you.
>
>
> IANAL (although I do often stay at Holiday Inn Express), but that's 
> not how I read it.
>
> LRSA signatories agree to be bound by all ARIN policy except where 
> specifically superceded by LRSA terms themselves.  I don't see such a 
> superceding clause excluding revocation by current or future policy.
> ...
> I've been suggesting that the LRSA explicitly do what it sounds like 
> you feel it already does, that is, assert that protection explicitly.
>
> If anyone can correct my understanding of the language in the LRSA, to 
> the effect that does indeed protect against this concern, I would be 
> thrilled to learn about it.

My understanding of LRSA ?10(b) ("ARIN will take no action to reduce the 
services provided for Included Number Resources that are not currently 
being utilized by the Legacy Applicant.") covered that.  That is 
certainly the intent, though I agree it could be more clearly stated.

In theory, we could pass a policy that revokes all LRSA resources, which 
_would_ ironically be binding on those that are unutilized but not 
binding on those that are unutilized, but I don't see even a remote 
chance that would ever gain consensus.  Still, if you want that 
protection explicitly in the LRSA, or my understanding above more 
clearly stated, that's a matter for you to take up with ARIN's counsel 
as input for the next revision.

S


From owen at delong.com  Wed Sep 10 12:38:53 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 10 Sep 2008 09:38:53 -0700
Subject: [arin-ppml] LRSA taking back addresses
In-Reply-To: <48C7DBA1.6050308@sprunk.org>
References: <48C6D019.7050803@cjbsys.bdb.com> <48C7DBA1.6050308@sprunk.org>
Message-ID: <BBEE067B-D1AC-477F-8F20-C91376EF2A76@delong.com>


On Sep 10, 2008, at 7:37 AM, Stephen Sprunk wrote:

> Cliff Bedore wrote:
>> Quoting from the ARIN legacy page
>>
>> "Note that ARIN will not reclaim unutilized address space from  
>> legacy holders who sign this RSA, nor will ARIN attempt to take  
>> away legacy resources from organizations who choose not to sign it.  
>> However, signing the Legacy RSA contractually locks in a set of  
>> rights, and thus reduces the risk of future change to a minimum."
>>
>> Note the section that says " nor will ARIN attempt to take away  
>> legacy resources from organizations who choose not to sign it."  So  
>> if I don't sign it, my address space is safe but if I sign it and  
>> then want to terminate for any reason, ARIN can reclaim the  
>> addresses.  What's wrong with this picture?
>
> That is the situation today (a point I think the FAQ doesn't make
> clear), but future policy may change.  For instance, next year, ARIN
> could adopt a proposal to revoke all legacy space.  Signing an LRSA
> before that happened would contractually prevent ARIN from applying  
> that
> policy to you.
>
I would like to make one small point in this regard...

People keep talking about ARIN adopting policy in the third
term.  For every person present on this mailing list and
for anyone who cares to subscribe, please note that for
the purpose of policy creation:

	ARIN == WE

That is all.

Owen
>



From Lee at Dilkie.com  Wed Sep 10 12:48:42 2008
From: Lee at Dilkie.com (Lee Dilkie)
Date: Wed, 10 Sep 2008 12:48:42 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <29A54911243620478FF59F00EBB12F470135CC6C@ex01.drtel.lan>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org><20080909195519.GB83487@ussenterprise.ufp.org>	<48C6F82C.6090108@dilkie.com>
	<29A54911243620478FF59F00EBB12F470135CC6C@ex01.drtel.lan>
Message-ID: <48C7FA6A.7070101@Dilkie.com>



Brian Johnson wrote:
> In response to Lee, I am still wondering why, other than IPv4
> exhaustion, ARIN even needs to do anything with legacy space. Why not
> just put them in a box and set them in a closet. Provide them no
> services except entries saying that these are legacy assignments... good
> luck, if any entries at all.  I would like to see how soon people start
> black-hole routing ranges and blocking access for legacy holders to
> their networks due to possible abuse.
>   
That was kind of my point, just leave them alone. The problem is the
"ipv4 exhaustion". Some folks seem to view legacy space as a free gold mine.
> As a regional provider, I would block any questionable access from
> networks without valid contact details readily available. One of my
> resources is IP based WHOIS. It could be possible that in the event of
> malicious traffic from Lee's network, I would block access to my network
> and/or other providers may do the same. This may inspire the legacy
> space holders to either get in the boat, or build their own. I think
> ARIN would likely be less costly, but have done no research to support
> that claim.
>   
Presumably you, like I, block malicious traffic from networks regardless
of the contact details, it *is* malicious after all..... The fact is, my
contact information, like many legacy holders, *is* up to date. My
in-addr *is* also up to date. I am a good net citizen and I wouldn't at
all mind contributing a "fair/reasonable" share towards the costs to
keep my records available. (I'd prefer a single 10 year payment than the
yearly stuff, that should cover the lifespan of IPv4) But what I don't
want is to locked into some contract that has clauses that take my space
away from me (or the threat of such). Something along the lines of:
- here's my 10 year, $200 membership, join me up.
- I promise to keep my contact info up-to-date
- here's where/how you can reach me if we need to talk (email addresses
in whois are so spam targeted that they're simply not reliable)
> I also thought legacy holders always boasted that they were among the
> creators/innovators of the Internet. Lee's statements indicate a
> stagnant thought pattern. That the Internet is what it is and that's it.
> It appears to me that ARIN membership is now taking over the innovator
> role for the Internet and that some/most legacy holders are more of a
> barrier than a player/enabler/innovator.
>   
Hey, we were. But guess what, big money and even bigger business took
over. That's the facts. My little community ISP couldn't survive once
the big guns came to town. I'm now the owner of a little /24 and doing
all my "innovation" in IPv6.

Which brings me to another issue....
> The good news is that there will be no legacy space in IPv6. If/when we
> move to IPv6 this is a non-issue.
>   
Well, I'd argue that the lack of any kind of "legacy" IPv6 hasn't helped
get of IPv6 out the door. I'd argue that we're missing the "innovators"
that we need in that space to create the compelling
applications/networks to drive demand for IPv6. I notice that none of
the big guns in my town have rolled out any IPv6. Big money is sitting
on it's hands as far as I can see. But my little network is fully
(although tunneled), IPv6 enabled. (but frankly, tunneling sucks)

Of course, that's only my point of view from my little neck of the woods.

-lee

PS. BTW, I think a fundamental problem ARIN has is the disparity, in
size, between the players in it's "community". Think about the size of
the largest ISPs here, and then about the smallest players (like
myself). It's very difficult to resolve the issues facing the community
across so many orders of magnitude. (A large ISP probably burns $100
just reading this email whereas it's a couple months worth of beer for me!)




From owen at delong.com  Wed Sep 10 12:56:29 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 10 Sep 2008 09:56:29 -0700
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <1080910110511.13222D@Ives.egh.com>
References: <1080910110511.13222D@Ives.egh.com>
Message-ID: <F2E8EDD6-7B18-4BBB-9D93-A2FF3651E729@delong.com>


On Sep 10, 2008, at 8:10 AM, John Santos wrote:

>
> This argument totally ignores what happens if ARIN allocates a
> "slot in the database" to someone when the number corresponding
> to that slot was allocated by a predecessor to a legacy holder.
>
> You can't make the issue of legacy assignments go away by
> sophistry.  It still has to be dealt with.
>

First, I don't think that Stephen's argument is sophistry under
the definition of sophistry:
	The use of fallacious arguments, esp. with the intention
	of deceiving.

What happens if ARIN allocates a "slot in the database" to
someone else when the number corresponding to that
slot was allocated by a predecessor to a legacy holder
is, indeed, the crux of the matter, but, also, happens to
not truly be under ARIN's control.  The possibilities
as I see them are:

1.	A critical mass of ISPs believe the new ARIN entry
	and the legacy holder is SOL.

2.	A critical mass of ISPs believe the legacy holder
	and the new registrant in the ARIN database is
	basically SOL.  Likely, ARIN is also discredited to
	some extent, and things break.

3.	A nearly equal mix of ISPs choose each side and
	nobody is happy.  All sides lose credibility and
	the government decides they've let the amateurs
	control this internet thingy long enough.

I don't believe anyone will actually support the idea of
simply reusing legacy space which was previously
assigned just because the legacy holder does not have
a contract with ARIN in the immediate future.

I do believe that as ARIN outreach to legacy holders
becomes more successful and more legacy holders
do sign agreements with ARIN, the remaining legacy
holders will face increasing pressure and decreasing
credibility.

I'm not sure that's a good thing, but, I think it is a likely
scenario.  I think it is in both ARIN and the legacy
holders' interests to get as many of those resources
protected in the hands of the legitimate legacy holders
through a contractual relationship with ARIN as soon
as possible.

Owen



From kkargel at polartel.com  Wed Sep 10 12:59:51 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 10 Sep 2008 11:59:51 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <1080910110511.13222D@Ives.egh.com>
References: <70DE64CEFD6E9A4EB7FAF3A063141066A10AE4@mail>
	<1080910110511.13222D@Ives.egh.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AE5@mail>

Actually it defines pretty well what happens.  If Arin assigns the database
slot for a.b.c.0/20 to Fred then everyone who uses the ARIN database will by
default route that network to Fred.  If Joe Legacy wants everyone to route
it to him then he needs to cooperate with ARIN to make sure that his network
is assigned the slot in the database and his records are updated.  

That sounds pretty straightforward to me.

> -----Original Message-----
> From: John Santos [mailto:JOHN at egh.com] 
> Sent: Wednesday, September 10, 2008 10:10 AM
> To: Kevin Kargel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] A compromise on legacy space?
> 
> 
> This argument totally ignores what happens if ARIN allocates 
> a "slot in the database" to someone when the number 
> corresponding to that slot was allocated by a predecessor to 
> a legacy holder.
> 
> You can't make the issue of legacy assignments go away by 
> sophistry.  It still has to be dealt with.
> 
> 
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080910/7826d3c7/attachment.bin>

From stephen at sprunk.org  Wed Sep 10 13:46:46 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 10 Sep 2008 12:46:46 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C7FA6A.7070101@Dilkie.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org><20080909195519.GB83487@ussenterprise.ufp.org>	<48C6F82C.6090108@dilkie.com>	<29A54911243620478FF59F00EBB12F470135CC6C@ex01.drtel.lan>
	<48C7FA6A.7070101@Dilkie.com>
Message-ID: <48C80806.6000506@sprunk.org>

Lee Dilkie wrote:
> That was kind of my point, just leave them alone. The problem is the "ipv4 exhaustion". Some folks seem to view legacy space as a free gold mine.
>   

Yes, there are folks who view abandoned or disused legacy space as a 
"gold mine": spammers.  Despite the best (and time-consuming, i.e. 
costly) efforts of ARIN staff, blocks do get hijacked now and then, and 
it's a mess when it happens -- one which is completely avoidable if the 
legacy holders would cooperate even minimally.  Most do not, so someone 
has to be an adult and force them to.

> Presumably you, like I, block malicious traffic from networks regardless of the contact details, it *is* malicious after all..... The fact is, my contact information, like many legacy holders, *is* up to date. My in-addr *is* also up to date.

Thank you.  However, stats at a recent ARIN meeting showed that ~50% of 
legacy records hadn't been updated even once since ARIN's formation a 
decade ago.  A significant fraction of legacy space doesn't show up in 
the DFZ either.

Those "innovators" are not keeping up with their obligations, do not 
appear to be using their space, and may not even _exist_ anymore.  That 
is all _I_ am proposing we attempt to reclaim.  If you're using your 
space (no matter how inefficiently) and you keep in contact with ARIN, 
keep it.  That is how I read the intent behind the LRSA and what I know 
(as a co-author) the intent is behind 2007-14.

> I am a good net citizen and I wouldn't at all mind contributing a "fair/reasonable" share towards the costs to keep my records available. (I'd prefer a single 10 year payment than the yearly stuff, that should cover the lifespan of IPv4)

A side effect of requiring annual payments, rather than letting you 
prepay for a decade, is that it ensures the contact information stays 
current.  While you may be diligent about taking care of that, many 
others obviously are not.  It also means that, when you finally decide 
IPv4 is no longer useful to you (be that in 3 years or 30 years), you 
will return it.  There may be no demand from others at that point, but 
there might for reasons we can't predict today.

S


From captain at netidea.com  Wed Sep 10 14:20:36 2008
From: captain at netidea.com (Kirk Ismay)
Date: Wed, 10 Sep 2008 11:20:36 -0700
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C7FA6A.7070101@Dilkie.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org><20080909195519.GB83487@ussenterprise.ufp.org>	<48C6F82C.6090108@dilkie.com>	<29A54911243620478FF59F00EBB12F470135CC6C@ex01.drtel.lan>
	<48C7FA6A.7070101@Dilkie.com>
Message-ID: <48C80FF4.1090908@netidea.com>


> PS. BTW, I think a fundamental problem ARIN has is the disparity, in
> size, between the players in it's "community". Think about the size of
> the largest ISPs here, and then about the smallest players (like
> myself). It's very difficult to resolve the issues facing the community
> across so many orders of magnitude. (A large ISP probably burns $100
> just reading this email whereas it's a couple months worth of beer for me!)
>   
Despite the size of some members of the community, the large players are 
outnumbered by the small ones.  ARIN's membership structure means that 
both a large player and a small one  get one vote each.

-- 

Sincerely, 
Kirk Ismay
System Administrator

--
Net Idea
201-625 Front Street Nelson, BC V1L 4B6
P:250-352-3512 | F:250-352-9780 | TF:1-888-352-3512

Check out our brand new website! www.netidea.com



From arin-ppml at westbrook.com  Wed Sep 10 15:05:55 2008
From: arin-ppml at westbrook.com (Eric Westbrook)
Date: Wed, 10 Sep 2008 13:05:55 -0600
Subject: [arin-ppml] LRSA taking back addresses
In-Reply-To: <48C7F09E.7080406@sprunk.org>
References: <48C6D019.7050803@cjbsys.bdb.com> <48C7DBA1.6050308@sprunk.org>
	<6905ba860809100825o254cdf4s1ef0513ddbbd627e@mail.gmail.com>
	<48C7F09E.7080406@sprunk.org>
Message-ID: <6905ba860809101205s151d7190ub86d4e9ce39860f@mail.gmail.com>

On Wed, Sep 10, 2008 at 10:06 AM, Stephen Sprunk <stephen at sprunk.org> wrote:

> My understanding of LRSA ?10(b) ("ARIN will take no action to reduce the
> services provided for Included Number Resources that are not currently being
> utilized by the Legacy Applicant.") covered that.  That is certainly the
> intent, though I agree it could be more clearly stated.


Thanks very much for pointing that out, Stephen.  Given the use of
"voluntary" in section 10's heading, I admit I probably didn't give it
sufficient scrutiny.

And now that I do, I think that might be exactly the kind of protection many
people are looking for.  Unfortunately, it wouldn't seem to apply to me,
since I'm actually using my numbers.

Ironic indeed that LRSA resources that are actually utilized do not enjoy
the benefits of ?10(b), while those that aren't utilized enjoy them fully!

Surely this is a mistake?


> Still, if you want that protection explicitly in the LRSA, or my
> understanding above more clearly stated, that's a matter for you to take up
> with ARIN's counsel as input for the next revision.


I'll certainly do that, and thanks for the suggestion.  I'm not immediately
finding that contact information on the website, but I'll keep digging.

Thanks again,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080910/5344fa0e/attachment.htm>

From JOHN at egh.com  Wed Sep 10 15:23:03 2008
From: JOHN at egh.com (John Santos)
Date: Wed, 10 Sep 2008 15:23:03 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <F2E8EDD6-7B18-4BBB-9D93-A2FF3651E729@delong.com>
Message-ID: <1080910141128.2637D-100000@Ives.egh.com>

On Wed, 10 Sep 2008, Owen DeLong wrote:

> 
> On Sep 10, 2008, at 8:10 AM, John Santos wrote:
> 
> >
> > This argument totally ignores what happens if ARIN allocates a
> > "slot in the database" to someone when the number corresponding
> > to that slot was allocated by a predecessor to a legacy holder.
> >
> > You can't make the issue of legacy assignments go away by
> > sophistry.  It still has to be dealt with.
> >
> 
> First, I don't think that Stephen's argument is sophistry under
> the definition of sophistry:
> 	The use of fallacious arguments, esp. with the intention
> 	of deceiving.
> 

Actually, it wasn't Steven's argument that I was responding to,
but Kevin's summary.  Unfortunately, it came as an attachment
rather than in the main text, and when I replied, it got lost.

I'll see if I can retrieve it...

[later...]

Kevin said:

> When it comes down to it nobody will force anybody to do anything.  People
> without any agreement or who do not keep registration data current can
> continue to use whatever numbers they want, they just won't be in the
> database.  ARIN cannot force Legacy users to enter into an agreement, and
> the Legacy users cannot force ARIN to list them in the database.
> 
> Networks (the majority of the Internet community) who choose to use this
> database will be able to easily communicate with others who use this
> database.  If someone wants to communicate with a network that is not 
> in the
> database their administrator is free to make a manual route table 
> entry.  So
> long as everyone between the two endpoints has the same entry it will route
> just fine.
> 
> The ARIN database is not a magic thing, it is not a law, it is not even a
> requirement.  It is just a tool we use to make our lives easier so we don't
> have to type route entries in to our routers or maintain our own database.
> ARIN is just a service to save us all work. It is useful because many
> networks choose to use it.  You could route just fine without ARIN if you
> could just exchange route entries with everyone you need to communicate 
> with and all their transit peers.
> 
> The reason this functions and works is cooperative anarchy. This is a good
> thing. Nobody forces anyone to do anything and if you cooperate and play by
> negotiated guidelines (RFC's) then everything works.  Simple, cheap and
> effective.  What could be better?

The gist of it seems to be that by thinking of it as
"slots in a database" instead of thinking of it as an allocation
or as an IP network number, ARIN could rewrite the rules to do
anything it wants (i.e. ignore legacy assignments.)  I think that
it makes no difference at all what way you think of it.  This is
what I refered to as sophistry.

Kevin, if you were just attempt to rephrase the argument using
the terminology of the "slots in a database" model instead of
the "allocations or assignments" model, then I apologize for
misunderstanding.

I still disagree with removing the legacy assignments (under most
circumstances) and think ARIN would encounter extreme difficulties
(i.e. law suits and/or government intervention) if it attempted
to do so, though.


> What happens if ARIN allocates a "slot in the database" to
> someone else when the number corresponding to that
> slot was allocated by a predecessor to a legacy holder
> is, indeed, the crux of the matter, but, also, happens to
> not truly be under ARIN's control.  The possibilities
> as I see them are:
> 
> 1.	A critical mass of ISPs believe the new ARIN entry
> 	and the legacy holder is SOL.
> 
> 2.	A critical mass of ISPs believe the legacy holder
> 	and the new registrant in the ARIN database is
> 	basically SOL.  Likely, ARIN is also discredited to
> 	some extent, and things break.
> 
> 3.	A nearly equal mix of ISPs choose each side and
> 	nobody is happy.  All sides lose credibility and
> 	the government decides they've let the amateurs
> 	control this internet thingy long enough.
> 

4. Both the legacy holder and the new registrant (and possibly
all legacy holders as a class action) sue ARIN for "conspiracy
in restraint of trade"...  (I was going to put a smiley here,
but I think *no one* on this list would be happy about that.)

> I don't believe anyone will actually support the idea of
> simply reusing legacy space which was previously
> assigned just because the legacy holder does not have
> a contract with ARIN in the immediate future.

That seems to be the opinion of most, but not all, of
the people here.  There are *some* (maybe a very small
minority, maybe not) who seem to want to revoke *all*
legacy space now if not yesterday, some even if it's
under an LRSA.

> 
> I do believe that as ARIN outreach to legacy holders
> becomes more successful and more legacy holders
> do sign agreements with ARIN, the remaining legacy
> holders will face increasing pressure and decreasing
> credibility.
> 

Probably true, which is one reason I would really like to get
something I can live with.

> I'm not sure that's a good thing, but, I think it is a likely
> scenario.  I think it is in both ARIN and the legacy
> holders' interests to get as many of those resources
> protected in the hands of the legitimate legacy holders
> through a contractual relationship with ARIN as soon
> as possible.

I do think we are getting closer.  Unlike some other legacy
holders (apparently), I don't even mind the provisions that
I could lose my "slots in the database" if I sign the LRSA
and then stop paying and don't respond to email or snail
mail or phone calls or any other attempt by ARIN to contact
me.  It seems that if I terminate for cause (or even without
cause if that variation becomes policy and part of the LRSA),
I have to tell ARIN that I'm doing so.  If I've signed the
LRSA and then I just vanish, stop paying and become uncontactable,
it seems reasonable for ARIN to (eventually) assume the space
is abandoned and reclaim it.


As another carrot to signing, it looks like I wouldn't qualify
for PI IPv6 space under current rules (too small), but I think
I could get it if I were an LRSA signer.  My provider seems not
to be doing anything with IPv6 yet, at least I can find *no*
mention of it on their web site, so ISP-provided IPv6 is not
currently an option.  I want to start testing with IPv6 and one
of my customers, who is *also* an ISP (a very big one but not
*my* ISP; I don't know if I can divulge their identity so that's
why I'm being vague) with whom we have a private T1 line carrying
IPv4, is actively investigating IPv6 for its internal network
and when they mandate a transition, our private line will probably
also have to be converted or at least the routers at both ends
dual-stacked.

This is both a carrot for me (I get my IPv6 space) and for all
the people out there urging faster IPv6 adoption.  (Assuming
I haven't completely misunderstood the IPv6 terms.)


> Owen


-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539




From Lee.Howard at stanleyassociates.com  Wed Sep 10 15:43:25 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Wed, 10 Sep 2008 15:43:25 -0400
Subject: [arin-ppml] LRSA taking back addresses
In-Reply-To: <6905ba860809101205s151d7190ub86d4e9ce39860f@mail.gmail.com>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B407301@CL-S-EX-1.stanleyassociates.com>

 

> > Still, if you want that protection explicitly in the LRSA, 
> > or my understanding above more clearly stated, that's a matter 
> > for you to take up with ARIN's counsel as input for the next
revision.

> I'll certainly do that, and thanks for the suggestion.  I'm not 
> immediately finding that contact information on the website, but I'll 
> keep digging. 
	 
http://www.arin.net/registration/legacy/#faq
Q11	
Anyone needing information about legacy space in general or the Legacy
RSA can call the Registration Services Help Desk at +1.703.227. 0660 or
send email to hostmaster at arin.net. If you have legal questions, please
contact ARIN General Counsel, Steve Ryan, at sryan at mwe.com 
	 


From tedm at ipinc.net  Wed Sep 10 16:56:27 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Sep 2008 13:56:27 -0700
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <20080909164137.GA68583@ussenterprise.ufp.org>
Message-ID: <D3C0D50660E44AC19016905E9F6AC8BE@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell
> Sent: Tuesday, September 09, 2008 9:42 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] A compromise on legacy space?
> 
> 
> 
> There are many reasons people are interested in legacy space, 
> and I personally find some level of merit to all of them:
> 


> 
> What do people think?
> 

Hi Leo,

  I think this is premature.  Before spending a lot
of effort in dealing with legacy numbering we really need to know
how extensive the problem is.

  That is why that passing either the "Annual WHOIS POC validation"
or the "whois POC e-mail cleanup" proposal when these come up is
critical.  Both of these proposals are non-invasive in terms of
changing legacy status of IP number blocks - they both leave the
actual "what do we do with them now what we have identified them"
problem to further proposals such as yours.  BUT, they start the
ball rolling on identifying the amount of stale legacy space out
there.  If the ARIN community doesn't have the stomach to support
either of these proposals, then it definitely isn't going to have
the stomach to implement an idea like yours which actually makes
changes to the status of legacy blocks.

Ted



From bmanning at vacation.karoshi.com  Wed Sep 10 17:03:57 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 10 Sep 2008 21:03:57 +0000
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48C7EBD7.1050008@sprunk.org>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C35EDE.5070902@sprunk.org>
	<mku6c45m78ke18ol91s81jhjasm0s9rjr6@4ax.com>
	<48C7EBD7.1050008@sprunk.org>
Message-ID: <20080910210357.GC20855@vacation.karoshi.com.>

On Wed, Sep 10, 2008 at 10:46:31AM -0500, Stephen Sprunk wrote:
> Jeremy H. Griffith wrote:
> > On Sat, 06 Sep 2008 23:55:58 -0500, Stephen Sprunk <stephen at sprunk.org> wrote:
> >   
> >> Jeremy H. Griffith wrote:    
> >>     
> >>> That's not where I start from.  I start from the belief that a "successor" is necessarily bound to respect the acts of its "predecessors", which issued the legacy resources under terms that were very different from those now being offered:
> >>>
> >>> *  No possibility of return on an involuntary basis.
> >>>    This was essential to encourage us to do the work
> >>>    that led to the current Internet.
> >>>   
> >> There was no statement either way about the basis on which addresses were assigned because, at the time, nobody could conceive that we'd actually run out of addresses and need any of them back.
> >>     
> >
> > Exactly.  So there was no such return requirement made.


	actually, there was. as i noted earlier, there were forced returns/renumbering
	events... -if- you wanted to be connected to the "Internet".
	if you were lucky enough not ot have been caught in the  "connected/disconnected"
	network discussions, you might think that no such requirement was implied, but it
	was there.  (deref all the cruft abt implied and verbal contracts)

	It might instructive to go back and review the FNC minutes and the relevent RFCs
	on what the DoD thought about IPv4, its creation and ultimate arbiter of use.
	To my occasionally faulty memory, for some period of time, DoD asserted that since
	they paid for it, IPv4 was theirs to use as they saw fit and could/would exapropriate
	any other use in times of need.  Now I am fairly sure that concept has not carried forward
	into ARIN's day%%, but if one wants to respect the original terms of use, that should be
	part of the consideration.  e.g.  there are potential times/reasons for forceable
	recovery of space assigned in the pre-cambrian era of the Internet and were when the
	resources left the barn.

%% - modulo violation of applicable law - and no ARIN does not decide that, thats what courts are for


> > There are limits to what the community can choose to do.  For example, it cannot choose to walk into my office and take away my hardware on the grounds that it's using the community network... 
> 
> Taking someone else's property is a crime.  Numbers are not property, 
> though, nor can they be taken away from you.  However, the service of 
> registration _can_, and since you're not paying for it, deciding not to 
> give it to you for free would be perfectly legal -- not theft.

	see http://en.wikipedia.org/wiki/Eminent_domain

> > Oh please.  I don't want to exhume all those dead bodies, but even in the last month we've been told that the "elephant in the room" is that those legacy people are just waiting to sell their numbers for the highest price

	generally by folks w/ their wallets out, wanting to buy... :)

> > they can get.  When the truth is, I doubt if *any* of us want to sell them at all... we just want to continue the "quiet enjoyment" we've had of them all these years.

	amen. :)


--bill



From jhg at omsys.com  Wed Sep 10 17:09:30 2008
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Wed, 10 Sep 2008 14:09:30 -0700
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <86hc8o0zn4.fsf@seastrom.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<004d01c912b1$bd228fc0$3767af40$@org>
	<20080909195519.GB83487@ussenterprise.ufp.org>
	<48C6F82C.6090108@dilkie.com>
	<20080909231649.GA97181@ussenterprise.ufp.org>
	<000c01c912e6$c40c2c80$4c248580$@org>
	<0icec4tdmdn7lvquees7v41o15sd9lp0sa@4ax.com>
	<86hc8o0zn4.fsf@seastrom.com>
Message-ID: <0ddgc45kombpu6uu8vnpba8obs6ljlcvu5@4ax.com>

On Wed, 10 Sep 2008 11:49:35 -0400, "Robert E. Seastrom" 
<ppml at rs.seastrom.com> wrote:

>That said, I think quibbling about $25 vs $100 for the yearly fee is
>really kind of missing the point - ARIN has been charging $100/year
>for directory services for ASNs for a long time.  That's $100/year to
>keep your OrgID warm and make contact periodically, it has nothing to
>do with the size of the allocation or number of objects your OrgID
>points at...  if you (like I) have two legacy /24s and a legacy ASN,
>your cost per year is still $100.

True, but the idea here is *outreach* to people who are used to
paying $0 per year.  Any way we can reduce the perception of a
barrier will help induce them to sign.  Any barriers we leave up
will do the opposite.  Like it or not, outside of ARIN the only
Internet registration service most people are used to is the
domain name registry, so that becomes the standard of comparison.
By that standard, $25 is reasonable and $100 is outlandish, no
matter what those who have been paying $100 for years may think.

In that perspective, I think the $25 idea, which more than one 
person on list has considered reasonable, will help further the
goal of signing up all legacy holders who are still breathing.
It's not a "quibble".  IMHO.

--JHG <jhg at omsys.com>


From tme at multicasttech.com  Wed Sep 10 17:25:51 2008
From: tme at multicasttech.com (Marshall Eubanks)
Date: Wed, 10 Sep 2008 17:25:51 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C7E2CB.4000700@sprunk.org>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>	<48C6C981.9030608@rancid.berkeley.edu>	<20080909164137.GA68583@ussenterprise.ufp.org>	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
	<20080909194830.GA83487@ussenterprise.ufp.org>
	<48C7DDE2.10306@sprunk.org>
	<E1822CB4-59D4-4367-B5CB-7021E0B3F28C@multicasttech.com>
	<48C7E2CB.4000700@sprunk.org>
Message-ID: <DF67869F-E5D4-479B-973D-CC035F3BFC3C@multicasttech.com>


On Sep 10, 2008, at 11:07 AM, Stephen Sprunk wrote:

> Marshall Eubanks wrote:
>> On Sep 10, 2008, at 10:46 AM, Stephen Sprunk wrote:
>>> Leo Bicknell wrote:
>>>> I do not believe ARIN can dump the entry from their internal  
>>>> database or assign the same numbers to someone else.
>>>
>>> I do not see any law or contract that would prevent ARIN from  
>>> assigning or allocating those numbers to someone else.
>>>
>>> Numbers are not property.  ARIN is selling the service of  
>>> providing uniqueness of registration, not numbers.  If the numbers  
>>> are no longer registered to party X, they can be freely assigned  
>>> or allocated to party Y.
>>
>> But how, in that case, do they guarantee uniqueness ?
>
> The guarantee of uniqueness is only among registered numbers, i.e.  
> no two organizations can register the same number.  ARIN, like any  
> other RIR, has no ability to prevent organizations from using  
> numbers that aren't registered to them.



>
> We've seen countless times where orgs pick random numbers in  
> "unassigned" space, rather than getting them from their RIR, and  
> there is a collision years later when it gets legitimately assigned  
> to someone else by an RIR.  Should those numbers be marked as "bad"  
> and never given to someone else, so that the squatter is free to use  
> them forever?  Think about the consequences of that.
>

Yes, they would be unique. That seems like a good thing to me.

Regards
Marshall


> S



From stephen at sprunk.org  Wed Sep 10 17:27:35 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 10 Sep 2008 16:27:35 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <0ddgc45kombpu6uu8vnpba8obs6ljlcvu5@4ax.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>	<004d01c912b1$bd228fc0$3767af40$@org>	<20080909195519.GB83487@ussenterprise.ufp.org>	<48C6F82C.6090108@dilkie.com>	<20080909231649.GA97181@ussenterprise.ufp.org>	<000c01c912e6$c40c2c80$4c248580$@org>	<0icec4tdmdn7lvquees7v41o15sd9lp0sa@4ax.com>	<86hc8o0zn4.fsf@seastrom.com>
	<0ddgc45kombpu6uu8vnpba8obs6ljlcvu5@4ax.com>
Message-ID: <48C83BC7.4030002@sprunk.org>

Jeremy H. Griffith wrote:
> On Wed, 10 Sep 2008 11:49:35 -0400, "Robert E. Seastrom" 
> <ppml at rs.seastrom.com> wrote:
>   
>> That said, I think quibbling about $25 vs $100 for the yearly fee is really kind of missing the point - ARIN has been charging $100/year for directory services for ASNs for a long time.  That's $100/year to keep your OrgID warm and make contact periodically, it has nothing to do with the size of the allocation or number of objects your OrgID points at...  if you (like I) have two legacy /24s and a legacy ASN, your cost per year is still $100.
>>     
>
> True, but the idea here is *outreach* to people who are used to paying $0 per year.  Any way we can reduce the perception of a barrier will help induce them to sign.  Any barriers we leave up will do the opposite.  Like it or not, outside of ARIN the only Internet registration service most people are used to is the domain name registry, so that becomes the standard of comparison.  By that standard, $25 is reasonable and $100 is outlandish, no matter what those who have been paying $100 for years may think.
>
> In that perspective, I think the $25 idea, which more than one person on list has considered reasonable, will help further the goal of signing up all legacy holders who are still breathing.  It's not a "quibble".  IMHO.
>   

Personally, I think that we need to do a better job of pointing out that 
the $100/org fee is for an unlimited number of objects.  I think most 
folks would prefer paying $100/org for an unlimited number of domains , 
rather than $25 (or whatever) per domain and would grasp the idea quite 
quickly...  We should also emphasize the other things that ARIN does 
with that money, as opposed to domain registrars that just provide a web 
order form, pass on the request and money to someone else to process, 
and take a small cut for themselves.

The idea of $25/object (not per org) is not unreasonable and would make 
things more directly comparable to domain fees, but it calls for a 
significant change in the way ARIN does billing.  I disagree that 
different orgs, whether under RSA or LRSA, should pay different rates 
for the same services.  If we change the model for one, we should change 
it for all of them.  Ultimately, however, the fee schedule is up to the 
BoT and members, not PPML.

S


From bmanning at vacation.karoshi.com  Wed Sep 10 17:32:07 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 10 Sep 2008 21:32:07 +0000
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <0ddgc45kombpu6uu8vnpba8obs6ljlcvu5@4ax.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<004d01c912b1$bd228fc0$3767af40$@org>
	<20080909195519.GB83487@ussenterprise.ufp.org>
	<48C6F82C.6090108@dilkie.com>
	<20080909231649.GA97181@ussenterprise.ufp.org>
	<000c01c912e6$c40c2c80$4c248580$@org>
	<0icec4tdmdn7lvquees7v41o15sd9lp0sa@4ax.com>
	<86hc8o0zn4.fsf@seastrom.com>
	<0ddgc45kombpu6uu8vnpba8obs6ljlcvu5@4ax.com>
Message-ID: <20080910213207.GE20855@vacation.karoshi.com.>


While I agree that times are tough fiscally, I note that 
often times, lower costs are reflective of percevied value.
if you truely beleive that your prefix has the same value 
as a "throw-away" domin from go-daddy - then I become concerned.
Carrying the domain analogy further, why shouldnt we allow
"address-tasting" etc...  

In this context, domains are nothing like addresses although
the registration/publication desires/requirements are (roughly) the
same.

Back to the value proposition.  Back in the day, when I started
consulting, I charged USD50/hr ... and work was hard to come by.
A wise soul told me to raise my rates to USD250/hr - which I did,
and there was more work than I could shake a stick at.  Percieved
Value.

in real terms,
	25/yr  == 0.068/day  eg less than a dime.  
	100/yr == 0.274/day  eg a bit more than a quarter

your daily starbucks == 4.00

from a pragmatic point, it costs more to do the accounting to send/track
process a payment for 25/yr than the income - based on the size of ARIN
membership.  Even after adding all the potental legacy holders, it would not
break even.  Now if we were Bank of NewYork, or ConEd, with 100,000's of 
thousands of users - we could likely make up the difference in volume and
automation.

--bill
(ranting before the day really starts up)



On Wed, Sep 10, 2008 at 02:09:30PM -0700, Jeremy H. Griffith wrote:
> On Wed, 10 Sep 2008 11:49:35 -0400, "Robert E. Seastrom" 
> <ppml at rs.seastrom.com> wrote:
> 
> >That said, I think quibbling about $25 vs $100 for the yearly fee is
> >really kind of missing the point - ARIN has been charging $100/year
> >for directory services for ASNs for a long time.  That's $100/year to
> >keep your OrgID warm and make contact periodically, it has nothing to
> >do with the size of the allocation or number of objects your OrgID
> >points at...  if you (like I) have two legacy /24s and a legacy ASN,
> >your cost per year is still $100.
> 
> True, but the idea here is *outreach* to people who are used to
> paying $0 per year.  Any way we can reduce the perception of a
> barrier will help induce them to sign.  Any barriers we leave up
> will do the opposite.  Like it or not, outside of ARIN the only
> Internet registration service most people are used to is the
> domain name registry, so that becomes the standard of comparison.
> By that standard, $25 is reasonable and $100 is outlandish, no
> matter what those who have been paying $100 for years may think.
> 
> In that perspective, I think the $25 idea, which more than one 
> person on list has considered reasonable, will help further the
> goal of signing up all legacy holders who are still breathing.
> It's not a "quibble".  IMHO.
> 
> --JHG <jhg at omsys.com>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From jcurran at istaff.org  Wed Sep 10 17:44:02 2008
From: jcurran at istaff.org (John Curran)
Date: Wed, 10 Sep 2008 17:44:02 -0400
Subject: [arin-ppml] LRSA taking back addresses
In-Reply-To: <6905ba860809101205s151d7190ub86d4e9ce39860f@mail.gmail.com>
References: <48C6D019.7050803@cjbsys.bdb.com> <48C7DBA1.6050308@sprunk.org>
	<6905ba860809100825o254cdf4s1ef0513ddbbd627e@mail.gmail.com>
	<48C7F09E.7080406@sprunk.org>
	<6905ba860809101205s151d7190ub86d4e9ce39860f@mail.gmail.com>
Message-ID: <F53F63CE-2FD2-4095-BCF6-DD475986DF22@istaff.org>

On Sep 10, 2008, at 3:05 PM, Eric Westbrook wrote:

> On Wed, Sep 10, 2008 at 10:06 AM, Stephen Sprunk  
> <stephen at sprunk.org> wrote:
> My understanding of LRSA ?10(b) ("ARIN will take no action to reduce  
> the services provided for Included Number Resources that are not  
> currently being utilized by the Legacy Applicant.") covered that.   
> That is certainly the intent, though I agree it could be more  
> clearly stated.
> ...
> Ironic indeed that LRSA resources that are actually utilized do not  
> enjoy the benefits of ?10(b), while those that aren't utilized enjoy  
> them fully!
>
> Surely this is a mistake?

The concept of ARIN reducing services for number resources that
are actually being used by a legacy holder is sufficiently alien that
it likely just didn't occur to those involved in drafting the LRSA...

/John
(personal guess only)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080910/0ea4fb8e/attachment.htm>

From Lee.Howard at stanleyassociates.com  Wed Sep 10 17:57:33 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Wed, 10 Sep 2008 17:57:33 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <DF67869F-E5D4-479B-973D-CC035F3BFC3C@multicasttech.com>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B4074D4@CL-S-EX-1.stanleyassociates.com>

> > We've seen countless times where orgs pick random numbers in 
> > "unassigned" space, rather than getting them from their 
> RIR, and there 
> > is a collision years later when it gets legitimately assigned to 
> > someone else by an RIR.  Should those numbers be marked as "bad"
> > and never given to someone else, so that the squatter is 
> free to use 
> > them forever?  Think about the consequences of that.
> >
> 
> Yes, they would be unique. That seems like a good thing to me.

Er, sorry. . . did you just say that when someone arbitrarily
announces (squats on) unassigned space, that space should be
permanently reserved?


> 
> Regards
> Marshall


Lee


From bill at herrin.us  Wed Sep 10 18:20:41 2008
From: bill at herrin.us (William Herrin)
Date: Wed, 10 Sep 2008 18:20:41 -0400
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
References: <20080909164137.GA68583@ussenterprise.ufp.org>
	<A55ECF2D-A427-478A-B0D3-289C991FEF8B@delong.com>
Message-ID: <3c3e3fca0809101520ufb1d975h4bef43e5005c5d6b@mail.gmail.com>

On Tue, Sep 9, 2008 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
> ARIN does not give, lease, transfer, or otherwise grant numbers
> to people.  Integers are integers and regardless of what ARIN
> does, every member of society remains perfectly within their
> rights to use any integer they choose for any lawful purpose they
> wish.
>
> We have (perhaps mistakenly) referred to these registrations
> as assignments and/or allocations, but, we aren't really assigning
> or allocating integers.

Uh huh. And McDonalds doesn't feed people; it just sells them squishy
objects in bags.

Regards,
Bill


-- 
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From stephen at sprunk.org  Wed Sep 10 18:21:39 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 10 Sep 2008 17:21:39 -0500
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <20080910210357.GC20855@vacation.karoshi.com.>
References: <200809062105.m86L5LTA005771@cjbsys.bdb.com>
	<4FE5345C-A60D-4B33-B213-BAF67089B2FB@istaff.org>
	<ck66c4tt63ipmuavhiisos0fbp6lelbu2v@4ax.com>
	<B3EC1B23-1910-4470-BDD7-82615505A618@istaff.org>
	<12h6c49ko9olrl28r7p7pdq02dsl1rg9gl@4ax.com>
	<48C35EDE.5070902@sprunk.org>
	<mku6c45m78ke18ol91s81jhjasm0s9rjr6@4ax.com>
	<48C7EBD7.1050008@sprunk.org>
	<20080910210357.GC20855@vacation.karoshi.com.>
Message-ID: <48C84873.8080700@sprunk.org>

bmanning at vacation.karoshi.com wrote:
> On Wed, Sep 10, 2008 at 10:46:31AM -0500, Stephen Sprunk wrote:
>   
>> Jeremy H. Griffith wrote:
>>     
>>> There are limits to what the community can choose to do.  For example, it cannot choose to walk into my office and take away my hardware on the grounds that it's using the community network... 
>>>       
>> Taking someone else's property is a crime.  Numbers are not property, though, nor can they be taken away from you.  However, the service of registration _can_, and since you're not paying for it, deciding not to give it to you for free would be perfectly legal -- not theft.
>>     
>
> 	see http://en.wikipedia.org/wiki/Eminent_domain
>   

Well, of course the politicians have monkeyed with the laws so that when 
_they_ want to steal someone else's property (whether land or income), 
it's legal.  For the rest of us, it's not.  However, since numbers 
cannot be property (they are "facts of nature"), they cannot be stolen 
or otherwise expropriated.

S


From tedm at ipinc.net  Wed Sep 10 19:42:54 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Sep 2008 16:42:54 -0700
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <3c3e3fca0809101520ufb1d975h4bef43e5005c5d6b@mail.gmail.com>
Message-ID: <DCCF3E2F7CD74B5891C4467A8CF94861@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> Sent: Wednesday, September 10, 2008 3:21 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] A compromise on legacy space?
> 
> 
> On Tue, Sep 9, 2008 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
> > ARIN does not give, lease, transfer, or otherwise grant numbers to 
> > people.  Integers are integers and regardless of what ARIN 
> does, every 
> > member of society remains perfectly within their rights to use any 
> > integer they choose for any lawful purpose they wish.
> >
> > We have (perhaps mistakenly) referred to these registrations as 
> > assignments and/or allocations, but, we aren't really assigning or 
> > allocating integers.
> 
> Uh huh. And McDonalds doesn't feed people; it just sells them 
> squishy objects in bags.
> 

Your definition of "food" is rather elastic. ;-)

There is much precedence for this in law.  If you go to your
state DMV and request a "custom" license plate with, for example,
the words "IP ADDR" on it, you may get the plate but you will
not "own" the plate - if the state decides at some later date that
your plate is objectionable when viewed in a mirror (or some other
such nonsense) it can revoke your use of the alphanumeric
characters used on the plate.

Ted



From cliffb at cjbsys.bdb.com  Wed Sep 10 20:22:31 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Wed, 10 Sep 2008 20:22:31 -0400
Subject: [arin-ppml] A compromise on legacy space?
Message-ID: <48C864C7.3030700@cjbsys.bdb.com>

> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> > Sent: Wednesday, September 10, 2008 3:21 PM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] A compromise on legacy space?
> > 
> > 
> > On Tue, Sep 9, 2008 at 2:22 PM, Owen DeLong <owen at delong.com> wrote:
> > > ARIN does not give, lease, transfer, or otherwise grant numbers to 
> > > people.  Integers are integers and regardless of what ARIN 
> > does, every 
> > > member of society remains perfectly within their rights to use any 
> > > integer they choose for any lawful purpose they wish.
> > >
> > > We have (perhaps mistakenly) referred to these registrations as 
> > > assignments and/or allocations, but, we aren't really assigning or 
> > > allocating integers.
> > 
> > Uh huh. And McDonalds doesn't feed people; it just sells them 
> > squishy objects in bags.
> > 
> 
> Your definition of "food" is rather elastic. ;-)
> 
> There is much precedence for this in law.  If you go to your
> state DMV and request a "custom" license plate with, for example,
> the words "IP ADDR" on it, you may get the plate but you will
> not "own" the plate - if the state decides at some later date that
> your plate is objectionable when viewed in a mirror (or some other
> such nonsense) it can revoke your use of the alphanumeric
> characters used on the plate.

Um Yeah and it's all spelled out in your application for the plate. 
That was
not the case for the legacy address holders.

Cliff

> 
> Ted
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20740
cliffb at cjbsys.bdb.com http://www.bdb.com
Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/



From tedm at ipinc.net  Thu Sep 11 18:47:44 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 11 Sep 2008 15:47:44 -0700
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <48C864C7.3030700@cjbsys.bdb.com>
Message-ID: <254114424C0C42818768595BD47CD833@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Cliff Bedore
> Sent: Wednesday, September 10, 2008 5:23 PM
> To: PPML
> Subject: Re: [arin-ppml] A compromise on legacy space?
> 
> 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net
> > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> > > Sent: Wednesday, September 10, 2008 3:21 PM
> > > To: arin-ppml at arin.net
> > > Subject: Re: [arin-ppml] A compromise on legacy space?
> > > 
> > > 
> > > On Tue, Sep 9, 2008 at 2:22 PM, Owen DeLong 
> <owen at delong.com> wrote:
> > > > ARIN does not give, lease, transfer, or otherwise grant 
> numbers to
> > > > people.  Integers are integers and regardless of what ARIN 
> > > does, every
> > > > member of society remains perfectly within their rights 
> to use any
> > > > integer they choose for any lawful purpose they wish.
> > > >
> > > > We have (perhaps mistakenly) referred to these registrations as
> > > > assignments and/or allocations, but, we aren't really 
> assigning or 
> > > > allocating integers.
> > > 
> > > Uh huh. And McDonalds doesn't feed people; it just sells them
> > > squishy objects in bags.
> > > 
> > 
> > Your definition of "food" is rather elastic. ;-)
> > 
> > There is much precedence for this in law.  If you go to 
> your state DMV 
> > and request a "custom" license plate with, for example, the 
> words "IP 
> > ADDR" on it, you may get the plate but you will not "own" 
> the plate - 
> > if the state decides at some later date that your plate is 
> > objectionable when viewed in a mirror (or some other such 
> nonsense) it 
> > can revoke your use of the alphanumeric characters used on 
> the plate.
> 
> Um Yeah and it's all spelled out in your application for the plate. 
> That was
> not the case for the legacy address holders.
> 

But it WAS spelled out for the post-legacy holders.

As for the argument that "legacy holders own their IPv4 addresses"
that is an entirely separate discussion from the concept that
ANY IPv4/IPv6 address holder "owns" their IP address allocations.

I frankly don't believe that it even was spelled out to the
legacy holders that they ever would "own" their IPv4 assignments,
but I also don't think that it is worth attempting to get into
an argument with legacy holders at this time who are "defending
their ownership" of their legacy blocks.  If you want to hold to
that, then go ahead - you must, however, be bound by your own
definition of "ownership" which INCLUDES the legal concept of
"abandonment of property"  Meaning that if a legacy holder
fails to use their IPv4, then by your own definition, they
have abandonded their ownership of it.

Ted



From farmer at umn.edu  Thu Sep 11 18:49:50 2008
From: farmer at umn.edu (David Farmer)
Date: Thu, 11 Sep 2008 17:49:50 -0500
Subject: [arin-ppml] A compromise on legacy space?
In-Reply-To: <29A54911243620478FF59F00EBB12F470135CC6C@ex01.drtel.lan>
References: <20080909164137.GA68583@ussenterprise.ufp.org>,
	<48C6F82C.6090108@dilkie.com>,
	<29A54911243620478FF59F00EBB12F470135CC6C@ex01.drtel.lan>
Message-ID: <48C95A3E.29165.DDEE74@farmer.umn.edu>

On 10 Sep 2008 Brian Johnson wrote:

> The good news is that there will be no legacy space in IPv6. If/when
> we move to IPv6 this is a non-issue.

I don't know about that, there are always Legacy issues.  I suspect in 10 or 
20 years everyone who got IPv6 space now will be the cause of some kind 
of Legacy issue.  Thank god it will be different than the current IPv4 Legacy 
issue.  So in a very narrow way, you are correct the specific issues of IPv4 
Legacy will not be an issue.  But there will be a legacy issue, as sure as 
technology marches on, it is just a fact of life in technology.  No one has any 
idea what it will be, if they did, we could plan to avoid it.  But there will be a 
legacy issue with IPv6.



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From info at arin.net  Fri Sep 12 11:07:33 2008
From: info at arin.net (Member Services)
Date: Fri, 12 Sep 2008 11:07:33 -0400
Subject: [arin-ppml] ARIN XXII: All We Are Missing Is You!
Message-ID: <48CA85B5.30405@arin.net>

We are looking forward to the ARIN XXII Public Policy and Members 
Meeting, taking place 15-17 October 2008, in Los Angeles, California, 
and we hope you are too. Come be a part of the community in action - 
don?t let your voice go unheard! Register today to take advantage of the 
early registration fee of $100. It increases to $150 on 15 September.

The meeting will take place at the Millennium Biltmore Hotel. ARIN XXII 
attendees are eligible for a special room rate of $189 (USD), based on 
availability, if reservations are made before 19 September.

In addition to the Public Policy and Members Meeting, there will be a 
number of informative events, including a introduction to the ARIN 
Policy development process and Open Policy Hour. The meeting will open 
on Wednesday with a special panel discussion, co-hosted with NANOG, 
titled ?What Would Jon have done about the Addressing Challenges 
Currently Facing Us??

Hotel and travel information, meeting registration, and an agenda 
overview are available through http://www.arin.net/ARIN-XXII/.

A more detailed agenda will be posted soon.

Can?t make it to the meeting? Be on the lookout for details on new and 
improved remote participation opportunities.

As always, please contact ARIN Member Services at info at arin.net with any 
questions. We look forward to seeing you in LA!

Regards,

Member Services
American Registry for Internet Numbers (ARIN)





From arin-ppml at westbrook.com  Fri Sep 12 13:09:15 2008
From: arin-ppml at westbrook.com (Eric Westbrook)
Date: Fri, 12 Sep 2008 11:09:15 -0600
Subject: [arin-ppml] LRSA taking back addresses
In-Reply-To: <F53F63CE-2FD2-4095-BCF6-DD475986DF22@istaff.org>
References: <48C6D019.7050803@cjbsys.bdb.com> <48C7DBA1.6050308@sprunk.org>
	<6905ba860809100825o254cdf4s1ef0513ddbbd627e@mail.gmail.com>
	<48C7F09E.7080406@sprunk.org>
	<6905ba860809101205s151d7190ub86d4e9ce39860f@mail.gmail.com>
	<F53F63CE-2FD2-4095-BCF6-DD475986DF22@istaff.org>
Message-ID: <6905ba860809121009w3cdadb95xf60449745c3eddc0@mail.gmail.com>

On Wed, Sep 10, 2008 at 3:44 PM, John Curran <jcurran at istaff.org> wrote:

> The concept of ARIN reducing services for number resources that
> are actually being used by a legacy holder is sufficiently alien that
> it likely just didn't occur to those involved in drafting the LRSA...
>
> /John
> (personal guess only)
>

Makes sense.

I tend to think of legal documents a little bit like software, in at least
one respect -- careful handling of unlikely input conditions is a healthy
practice.

I will suggest that ?10(b) be slightly amended to read, "ARIN will take no
action to reduce the services provided for Included Number Resources,
whether utilized by the Legacy Applicant or not."  I think that would more
accurately reflect the intent with which it was apparently written, and
would alleviate a big concern of many unsigned legacy holders.  I'll
correspond to ARIN Counsel with that recommendation; my thanks to those who
provided pointers.

I'm surprised ?10(b) in specific isn't more frequently pointed to when these
concerns come up.  In its intent, at least, it removes a big worry many
legacy holders seem to have.  Perhaps better illumination and clarification
of that clause can help us all reach higher comfort levels.

Thanks again,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080912/d5bc9aff/attachment.htm>

From bicknell at ufp.org  Fri Sep 12 14:44:09 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 12 Sep 2008 14:44:09 -0400
Subject: [arin-ppml] Taking back UNUSED addresses.
Message-ID: <20080912184409.GA84710@ussenterprise.ufp.org>


There's been a lot of speculation on the LRSA around the premise
that ARIN wants to "take back addresses".  While I have no doubt
that some people have that view, I don't think the vast majority
of people want to take back any addresses in active use.

One of the items that comes up is the question of how much fallow
space may be out there.  It would seem the skeptics think there is
very little fallow space, to which the "attack" must be on space
in use.  Here are some snippets (including how to get the full
report) from the CIDR report posted today to the NANOG mailing
list...

> This is an automated weekly mailing describing the state of the Internet
> Routing Table as seen from APNIC's router in Japan.
> Daily listings are sent to bgp-stats at lists.apnic.net
>  
> For historical data, please see http://thyme.apnic.net.
>  
> If you have any comments please contact Philip Smith <pfs at cisco.com>.
>  
> Routing Table Report   04:00 +10GMT Sat 13 Sep, 2008
>  
> Report Website:     http://thyme.apnic.net
> Detailed Analysis:  http://thyme.apnic.net/current/
 
[snip]
 
> Analysis Summary
> ----------------
 
[snip]
 
> Number of addresses announced to Internet:                   1916473632
>     Equivalent to 114 /8s, 59 /16s and 17 /24s
>     Percentage of available address space announced:               51.7
>     Percentage of allocated address space announced:               62.8
>     Percentage of available address space allocated:               82.3
>     Percentage of address space in use by end-sites:               73.5
 
So globally around the world 19.5% (82.3 - 62.8) of all space that
has been allocated is not routed on the public Internet.
 
> ARIN Region Analysis Summary
> ----------------------------
 
[snip]
 
> Number of ARIN addresses announced to Internet:               361286880
>     Equivalent to 21 /8s, 136 /16s and 204 /24s
>     Percentage of available ARIN address space announced:          74.3

In the ARIN region, 25.7% of all IP space that has been allocated is not
routed on the public Internet.

To be clear, this number will likely never be zero for a number of
legitmate reasons:

- Newly allocated space may take days/weeks/months to be actually
  routed.
- Some space is used for semi-connected networks, or private networks
  that interconnect public players and thus will never appear on this
  report.
- Some people are in the process of moving from one provider to another
  and their space is unused for a brief period of time in the middle.

However, as we reach a point where there is no more free IPv4 space
to be given out, I suspect everyone is going to start to look at
that 25.7%.  Some fraction of that, perhaps a large fraction, is
likely not in use at all.  These range from situations where I think we
all agree space should be reclaimed:

- The person who requested it has died.
- The company was dissolved.
- The original requester has moved to PA space and no longer needs PI.

To situations where it is a bit murkier if reclamation is a good idea or
not:

- Two companies, both with a /24 each and only using 20 IP's merge, and 
  end up using 40 IP's in a single /24, holding the other in "reserve".
- A company that previously justified a /16 has seen their customer base
  shrunk to 10% of what it was when they requested the /16.

In my opinion ARIN should be aggressively "going after" that 25.7%
of the space that isn't routed.  They should be documenting if it
is used on private networks, or if the contact is totally gone.  I
believe this needs to happen via multiple methods, not just one.
Most importantly, ARIN needs to be positioning itself for a future
where that 25.7% is under great scrutiny, as there is no more free
space and plenty of people who would like to use it if it is free.
I believe ARIN needs stronger relationships with address space users
to make that happen, which is why I am pushing for there to be
contracts and regular contact with legacy space holders.

This has implications for the LRSA discussion.  While I don't want
to take any space away from someone who is using it the contract
can't be so lopsided such as if someone really and truly isn't using
it they can keep it from the community forever.  It's a concept I
haven't seen discussed much.  I wonder if those who put forth the
view that the legacy assignment was made "forever, with no conditions"
would defend the right of the legacy holder to hold on to the
numbers and not use them.  Is holding the space in reserve, unused,
one of the "rights" of legacy holders?

It's fun to talk about the implications of contracts and policies
today, but with an available free pool there is little "threat" to
anyones use of IP space.  It's much more interesting, and useful,
to think about a world where there is no free pool.  The pressure
on people, legacy or not, who have space but are not using it at
all will be huge.  By the numbers that is ONE in FOUR of the people
who have received space in the ARIN region....


-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080912/fc787453/attachment.sig>

From bill at herrin.us  Fri Sep 12 16:06:45 2008
From: bill at herrin.us (William Herrin)
Date: Fri, 12 Sep 2008 16:06:45 -0400
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <20080912184409.GA84710@ussenterprise.ufp.org>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>

On Fri, Sep 12, 2008 at 2:44 PM, Leo Bicknell <bicknell at ufp.org> wrote:
>> Number of addresses announced to Internet:                   1916473632
>>     Equivalent to 114 /8s, 59 /16s and 17 /24s
>>     Percentage of available address space announced:               51.7
>>     Percentage of allocated address space announced:               62.8
>>     Percentage of available address space allocated:               82.3
>>     Percentage of address space in use by end-sites:               73.5
>
> So globally around the world 19.5% (82.3 - 62.8) of all space that
> has been allocated is not routed on the public Internet.

The way I read this is .823 * .628 = .517

In other words, 100 - 62.8 = 37.2% of allocated space is not routed on
the public Internet.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bicknell at ufp.org  Fri Sep 12 16:20:00 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 12 Sep 2008 16:20:00 -0400
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
Message-ID: <20080912202000.GA94971@ussenterprise.ufp.org>

In a message written on Fri, Sep 12, 2008 at 04:06:45PM -0400, William Herrin wrote:
> On Fri, Sep 12, 2008 at 2:44 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> >> Number of addresses announced to Internet:                   1916473632
> >>     Equivalent to 114 /8s, 59 /16s and 17 /24s
> >>     Percentage of available address space announced:               51.7
> >>     Percentage of allocated address space announced:               62.8
> >>     Percentage of available address space allocated:               82.3
> >>     Percentage of address space in use by end-sites:               73.5
> >
> > So globally around the world 19.5% (82.3 - 62.8) of all space that
> > has been allocated is not routed on the public Internet.
> 
> The way I read this is .823 * .628 = .517
> 
> In other words, 100 - 62.8 = 37.2% of allocated space is not routed on
> the public Internet.

Two other people have e-mailed me the same thing.  I believe you are
correct.

However, this effor is in the direction that puts more weight behind my
argument.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080912/fe9ddaa7/attachment.sig>

From bill at herrin.us  Fri Sep 12 17:42:42 2008
From: bill at herrin.us (William Herrin)
Date: Fri, 12 Sep 2008 17:42:42 -0400
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <20080912202000.GA94971@ussenterprise.ufp.org>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
	<20080912202000.GA94971@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>

On Fri, Sep 12, 2008 at 4:20 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Sep 12, 2008 at 04:06:45PM -0400, William Herrin wrote:
>> In other words, 100 - 62.8 = 37.2% of allocated space is not routed on
>> the public Internet.
>
> Two other people have e-mailed me the same thing.  I believe you are
> correct.
>
> However, this effor is in the direction that puts more weight behind my
> argument.

Do we have an independent confirmation of the numbers? As I recall,
that particular computation is not the primary purpose of that report.

Regards,
Bill



-- 
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From gih at apnic.net  Sun Sep 14 17:26:54 2008
From: gih at apnic.net (Geoff Huston)
Date: Mon, 15 Sep 2008 07:26:54 +1000
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
	<20080912202000.GA94971@ussenterprise.ufp.org>
	<3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>
Message-ID: <7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>


On 13/09/2008, at 7:42 AM, William Herrin wrote:

> On Fri, Sep 12, 2008 at 4:20 PM, Leo Bicknell <bicknell at ufp.org>  
> wrote:
>> In a message written on Fri, Sep 12, 2008 at 04:06:45PM -0400,  
>> William Herrin wrote:
>>> In other words, 100 - 62.8 = 37.2% of allocated space is not  
>>> routed on
>>> the public Internet.
>>
>> Two other people have e-mailed me the same thing.  I believe you are
>> correct.
>>
>> However, this effor is in the direction that puts more weight  
>> behind my
>> argument.
>
> Do we have an independent confirmation of the numbers? As I recall,
> that particular computation is not the primary purpose of that report.

I'll be brief - this list is already very busy and I'm reluctant to  
add to the reading volume unnecessarily.

The figures Leo Quotes appear to be from a weekly report generated by  
a BGP analysis script set up by Philip Smith of Cisco.

Another view of the advertised / unadvertised ratio can be seen at  
Figure 13 of http://www.potaroo.net/tools/ipv4/ (http://www.potaroo.net/tools/ipv4/fig13.png 
), using an independently authored set of tools that I set up that  
looks at the BGP routing table and the RIR's published data regarding  
allocated addresses.

This graph expresses the size of the unadvertised address pool as a  
percentage of the size of the advertised address pool over time.

The current value is 0.4322 (unadvertised addresses are 43.22% of the  
advertised address) Which means that of the total allocated address  
pool, 30.17% of the addresses are not _currently_ advertised into my  
particular view of the global routing table.

Its slightly lower than the figure that Leo quotes in the thread, but  
then again I can readily see that there are different methods of  
counting what's actually "allocated" and there are certainly scope for  
considerable variation here (see http://www.cidr-report.org/bogons/rir-data.html 
  if you want to have a feel for the quality of the input data on  
"allocated" addresses) and of course every view of the routing table  
differs to some small extent.

The current ratio has been stable, more or less, since early 2007 (the  
unadvertised address pool has been growing at the same relative rate  
as the advertised address pool in size)

   Geoff











From bicknell at ufp.org  Sun Sep 14 21:06:04 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Sun, 14 Sep 2008 21:06:04 -0400
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
	<20080912202000.GA94971@ussenterprise.ufp.org>
	<3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>
	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
Message-ID: <20080915010604.GA60456@ussenterprise.ufp.org>

In a message written on Mon, Sep 15, 2008 at 07:26:54AM +1000, Geoff Huston wrote:
> The current value is 0.4322 (unadvertised addresses are 43.22% of the  
> advertised address) Which means that of the total allocated address  
> pool, 30.17% of the addresses are not _currently_ advertised into my  
> particular view of the global routing table.

I wonder if any of the parties could easily re-generate the numbers
for two groups of addresses, those allocated prior to December 1997
(ARIN's founding date), and those after.

I note of course that the date alone does not 100% match legacy/non-legacy
for a number of reasons, but I suspect it's 99% correct, and by far
the easiest way for the records to be quickly separated.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080914/768d543d/attachment.sig>

From iljitsch at muada.com  Tue Sep 16 06:37:14 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Tue, 16 Sep 2008 12:37:14 +0200
Subject: [arin-ppml] CIDR v2.0
Message-ID: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>

In the early 1990s IPv4 address space was running out. They fixed this  
by changing routing protocols. Maybe we should try to do that again.

<history>

In the early days of the internet you could only use IPv4 addresses as  
blocks of 16777216, 65536 or 256 addresses. 256 was too small for most  
people so 65536 was a popular choice, but there are only some 16000 of  
these class B blocks and it was looking like those would be exhausted  
by the mid-1990s. So they started giving people a bunch of class C  
blocks (256 addresses each) but now the routing tables started to  
explode because a university that needed a single class B block before  
now used something like 16 class C blocks, which had to appear in  
routing tables individually. To fix this, routing protocols,  
especially BGP, were changed to be able to work with address blocks of  
arbitrary power of two sizes so address space and routing table slots  
could be managed much more efficiently. (This is "classless  
interdomain routing".)

</history>

Now that IPv4 address space is becoming scarce again, why not do the  
same thing again? But now rather than arbitrary powers of 2, we modify  
the protocols to work with arbitrary address ranges. I.e., 192.0.2.27  
- 192.0.2.43.

To accommodate legacy routers that can't do lookups based on ranges we  
can put in backward compatibility mechanisms from BGP5 to BGP4 similar  
to the ones from BGP4 (with CIDR) to BGP3 (no CIDR).


From bmanning at vacation.karoshi.com  Tue Sep 16 07:09:20 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 16 Sep 2008 11:09:20 +0000
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
Message-ID: <20080916110920.GA24231@vacation.karoshi.com.>

On Tue, Sep 16, 2008 at 12:37:14PM +0200, Iljitsch van Beijnum wrote:
> In the early 1990s IPv4 address space was running out. They fixed this  
> by changing routing protocols. Maybe we should try to do that again.
> 
> <history>
> 
> In the early days of the internet you could only use IPv4 addresses as  
> blocks of 16777216, 65536 or 256 addresses. 256 was too small for most  
> people so 65536 was a popular choice, but there are only some 16000 of  
> these class B blocks and it was looking like those would be exhausted  
> by the mid-1990s. So they started giving people a bunch of class C  
> blocks (256 addresses each) but now the routing tables started to  
> explode because a university that needed a single class B block before  
> now used something like 16 class C blocks, which had to appear in  
> routing tables individually. To fix this, routing protocols,  
> especially BGP, were changed to be able to work with address blocks of  
> arbitrary power of two sizes so address space and routing table slots  
> could be managed much more efficiently. (This is "classless  
> interdomain routing".)
> 
> </history>
> 
> Now that IPv4 address space is becoming scarce again, why not do the  
> same thing again? But now rather than arbitrary powers of 2, we modify  
> the protocols to work with arbitrary address ranges. I.e., 192.0.2.27  
> - 192.0.2.43.
> 
> To accommodate legacy routers that can't do lookups based on ranges we  
> can put in backward compatibility mechanisms from BGP5 to BGP4 similar  
> to the ones from BGP4 (with CIDR) to BGP3 (no CIDR).


	Thats a whole lot of work to support bitstrings in routing protocols.
	If its just to support IPv4 then I am not sure I see the long-term value
	in making such a change.  Now if we were going to start supporting 
	variable length addresses then I could see a compelling case for making
	such a change.  

	Mind you, I am a fan of variable length addressing.

--bill


From bicknell at ufp.org  Tue Sep 16 08:06:14 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 16 Sep 2008 08:06:14 -0400
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
Message-ID: <20080916120614.GA97670@ussenterprise.ufp.org>

In a message written on Tue, Sep 16, 2008 at 12:37:14PM +0200, Iljitsch van Beijnum wrote:
> Now that IPv4 address space is becoming scarce again, why not do the  
> same thing again? But now rather than arbitrary powers of 2, we modify  
> the protocols to work with arbitrary address ranges. I.e., 192.0.2.27  
> - 192.0.2.43.

If given the choice of having to debug an entirely new routing
protocol and deploy it to every Internet router to make things work,
isn't moving to IPv6 a more intelligent use of that time and effort?

Were there no IPv6, I might support your idea.  However, even at
today's limited state IPv6 is both far more deployed than the
solution you propose, and solves the problem in a way that will
last for many more years.  From a code perspective, your solution would
start from scratch in another 1-2 years, if we could get people to agree
real fast.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080916/62dd2bd3/attachment.sig>

From kkargel at polartel.com  Tue Sep 16 09:11:51 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 16 Sep 2008 08:11:51 -0500
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>

The difficulty with this is that we already have problems of hardware
that is insufficient to support the routing tables.  ISP's are already
filtering long CIDR routes (>24bit) because there isn't sufficient
memory or processor in the hardware to support the number of routes it
would require.  

Your idea would work, but only if we got rid of PI space and forced
everyone to use IP space from their ISP so that there could be efficient
route aggregation.  If you search through threads you will see that
there is violent opposition by end users who want to be provider
independent.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, September 16, 2008 5:37 AM
> To: PPML PPML
> Subject: [arin-ppml] CIDR v2.0
> 
> In the early 1990s IPv4 address space was running out. They 
> fixed this by changing routing protocols. Maybe we should try 
> to do that again.
> 
> <history>
> 
> In the early days of the internet you could only use IPv4 
> addresses as blocks of 16777216, 65536 or 256 addresses. 256 
> was too small for most people so 65536 was a popular choice, 
> but there are only some 16000 of these class B blocks and it 
> was looking like those would be exhausted by the mid-1990s. 
> So they started giving people a bunch of class C blocks (256 
> addresses each) but now the routing tables started to explode 
> because a university that needed a single class B block 
> before now used something like 16 class C blocks, which had 
> to appear in routing tables individually. To fix this, 
> routing protocols, especially BGP, were changed to be able to 
> work with address blocks of arbitrary power of two sizes so 
> address space and routing table slots could be managed much 
> more efficiently. (This is "classless interdomain routing".)
> 
> </history>
> 
> Now that IPv4 address space is becoming scarce again, why not 
> do the same thing again? But now rather than arbitrary powers 
> of 2, we modify the protocols to work with arbitrary address 
> ranges. I.e., 192.0.2.27
> - 192.0.2.43.
> 
> To accommodate legacy routers that can't do lookups based on 
> ranges we can put in backward compatibility mechanisms from 
> BGP5 to BGP4 similar to the ones from BGP4 (with CIDR) to 
> BGP3 (no CIDR).
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From ryan.e.berse at citi.com  Tue Sep 16 09:52:26 2008
From: ryan.e.berse at citi.com (Berse, Ryan E )
Date: Tue, 16 Sep 2008 09:52:26 -0400
Subject: [arin-ppml] Taking back UNUSED addresses.
References: <20080912184409.GA84710@ussenterprise.ufp.org><3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com><20080912202000.GA94971@ussenterprise.ufp.org><3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>
	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
Message-ID: <D8368E540714E245882EFDCF161241710C99BBE6@EXNJMB49.nam.nsroot.net>


When looking at these numbers, you need to keep in mind that just
because a particular block of space is not advertised to the (public)
Internet does not mean it is unused.  Organizations also use their
registered address space on B2B links between their own network and
those of partners/clients/vendors/etc.  I would bet such use accounts
for a significant chunk of the allocated but unadvertised space.
Attempting to reclaim such space would probably meet with fierce
resistance from the registrants (especially if legacy) and their legal
departments.  

Ryan




-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Geoff Huston
Sent: Sunday, September 14, 2008 5:27 PM
To: William Herrin
Cc: ppml at arin.net
Subject: Re: [arin-ppml] Taking back UNUSED addresses.


On 13/09/2008, at 7:42 AM, William Herrin wrote:

> On Fri, Sep 12, 2008 at 4:20 PM, Leo Bicknell <bicknell at ufp.org>  
> wrote:
>> In a message written on Fri, Sep 12, 2008 at 04:06:45PM -0400,  
>> William Herrin wrote:
>>> In other words, 100 - 62.8 = 37.2% of allocated space is not  
>>> routed on
>>> the public Internet.
>>
>> Two other people have e-mailed me the same thing.  I believe you are
>> correct.
>>
>> However, this effor is in the direction that puts more weight  
>> behind my
>> argument.
>
> Do we have an independent confirmation of the numbers? As I recall,
> that particular computation is not the primary purpose of that report.

I'll be brief - this list is already very busy and I'm reluctant to  
add to the reading volume unnecessarily.

The figures Leo Quotes appear to be from a weekly report generated by  
a BGP analysis script set up by Philip Smith of Cisco.

Another view of the advertised / unadvertised ratio can be seen at  
Figure 13 of http://www.potaroo.net/tools/ipv4/
(http://www.potaroo.net/tools/ipv4/fig13.png 
), using an independently authored set of tools that I set up that  
looks at the BGP routing table and the RIR's published data regarding  
allocated addresses.

This graph expresses the size of the unadvertised address pool as a  
percentage of the size of the advertised address pool over time.

The current value is 0.4322 (unadvertised addresses are 43.22% of the  
advertised address) Which means that of the total allocated address  
pool, 30.17% of the addresses are not _currently_ advertised into my  
particular view of the global routing table.

Its slightly lower than the figure that Leo quotes in the thread, but  
then again I can readily see that there are different methods of  
counting what's actually "allocated" and there are certainly scope for  
considerable variation here (see
http://www.cidr-report.org/bogons/rir-data.html 
  if you want to have a feel for the quality of the input data on  
"allocated" addresses) and of course every view of the routing table  
differs to some small extent.

The current ratio has been stable, more or less, since early 2007 (the  
unadvertised address pool has been growing at the same relative rate  
as the advertised address pool in size)

   Geoff









_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From info at arin.net  Tue Sep 16 10:31:17 2008
From: info at arin.net (Member Services)
Date: Tue, 16 Sep 2008 10:31:17 -0400
Subject: [arin-ppml] 2008-3: Community Networks IPv6 Allocation - Revised
Message-ID: <48CFC335.9030207@arin.net>

Policy Proposal "2008-3: Community Networks IPv6 Allocation" has been
revised. This proposal is open for discussion on this mailing list and
will be on the agenda at the upcoming ARIN XXII Public Policy Meeting in
Los Angeles.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2008_3.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 2008-3
Community Networks IPv6 Allocation

Author: Joshua King

Date: 16 September 2008

Proposal type: new

Policy term: permanent

Policy statement:

[Add Section 2.8 to the NRPM.]

2.8 Community Network
A community network is a generic reference to a network that is
operated by a group of people living in a particular local area
organized for the purposes of delivery or provision of free or low-cost
network services to the residents of an incorporated or unincorporated
regional municipality, city, town, village, rural municipality,
township, county, district or other municipality or other such
geographic space, however designated. In order to qualify as a community
network under this policy, the community network must certify to ARIN
that their staff is at least half volunteer and that their annual
revenue is less than $250000 (in 2009 dollars, adjusted for inflation).
Legal responsibility for the network as a whole must be held by an
organization either possessing non-profit status or fiscally sponsored
by a non-profit organization or university.

[Modify 6.5.8.1b as follows.]

b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4
policy currently in effect or be a qualifying Community Network as
defined in Section 2.8, with allocation criteria defined in section 6.5.9.

[Add Section 6.5.9 to the NRPM.]

6.5.9 Community Network Allocations
6.5.9.1. Initial assignment size
Organizations defined as Community Networks under section 2.8 are
eligible to receive a direct assignment. The minimum size of the
assignment is /48. Organizations requesting a larger assignment must
provide documentation of the characteristics of the Community Network's
size and architecture that require the use of additional subnets. An
HD-Ratio of .94 with respect to subnet utilization within the network
must be met for all assignments larger than a /48.

These assignments shall be made from a distinctly identified prefix and
shall be made with a reservation for growth of at least a /44. This
reservation may be assigned to other organizations later, at ARIN's
discretion.

6.5.9.2. Subsequent assignment size
Additional assignments may be made when the need for additional subnets
is justified. Justification will be determined based on a detailed plan
of the network's architecture and the .94 HD-Ratio metric. When
possible, assignments will be made from an adjacent address block.

6.5.9.3. Number of customers
Community Networks seeking an allocation must demonstrate that they
provide for a user base of at least 100 through connectivity to homes
and businesses, public facilities, public access points, or mobile
users. Community Networks with user bases of under 200 must also submit
a plan for doubling their service base over the next year.


Rationale:

There are currently a number of projects globally that aim to develop
community network infrastructure and related technologies. These are
usually coordinated by volunteer-run, grassroots organizations which
lack many of the resources of traditional internet service providers and
other network operators. They have diverse goals, including public
policy, software development, and implementation of community services
and resources. Many of them provide services free of charge, and thus
lack any paying user base. However, in order to create and maintain
community networks that are often composed of hundreds if not thousands
of inexpensive consumer-grade network devices, a significant amount of
address space will be required. Current-generation workarounds to this
problem, such as NAT, not only make it difficult to develop
next-generation decentralized network technology by segmenting the
community's architecture from the Internet as a whole, but will cease to
be as viable a stopgap as the Internet moves towards IPv6 integration.

Community-based, volunteer-run organizations that are operated with an
eye towards the public good often do not have the resources to qualify
as an LIR under the current policy. They are often multi-homed networks
utilizing multiple, relatively inexpensive consumer-grade internet
uplinks and lacking the funds to meet the qualifications for an IPv4
allocation, but which wish an avenue to develop future IPv6 capability
for their constituent users. If this proposal is adopted, I intend to
immediately move forward with the process to request a change in fee
structure for community networks so that they are permitted to pay a
small percentage of their annual revenue in lieu of a flat fee. By
establishing a procedure by which these organizations can seek to
acquire the resources they require for further development, ARIN can
reach out to this active community and establish a small but definite
space for them in the future of Internet.


Timetable for implementation: Immediate.






From info at arin.net  Tue Sep 16 10:33:34 2008
From: info at arin.net (Member Services)
Date: Tue, 16 Sep 2008 10:33:34 -0400
Subject: [arin-ppml] Policy Proposals and Draft Agenda
Message-ID: <48CFC3BE.6020301@arin.net>

The following policy proposals have been under discussion on the ARIN
Public Policy Mailing List and will be presented for consideration at
the upcoming ARIN XXII Public Policy Meeting in Los Angeles on 15-16
October 2008.

2007-14: Resource Review Process

2008-2: IPv4 Transfer Policy Proposal

2008-3: Community Networks IPv6 Allocation

2008-4: Minimum Allocation in the Caribbean Region

2008-5: Dedicated IPv4 block to facilitate IPv6 Deployment

2008-6: Emergency Transfer Policy for IPv4 Addresses

2008-7: Whois Integrity Policy Proposal

The full text for each proposal can be found at:
http://www.arin.net/policy/proposal_archive.html

Agenda information has been updated. Find the draft agenda as well as
hotel information at:
http://www.arin.net/ARIN-XXII/

ARIN XXII attendees: To ensure you get the special reserved rate of $189
single/double, please make your reservation before 19 September!

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From mksmith at adhost.com  Tue Sep 16 11:31:03 2008
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 16 Sep 2008 08:31:03 -0700
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
Message-ID: <17838240D9A5544AAA5FF95F8D52031604A64237@ad-exh01.adhost.lan>

> 
> The difficulty with this is that we already have problems of hardware
> that is insufficient to support the routing tables.  ISP's are already
> filtering long CIDR routes (>24bit) because there isn't sufficient
> memory or processor in the hardware to support the number of routes it
> would require.
> 
> Your idea would work, but only if we got rid of PI space and forced
> everyone to use IP space from their ISP so that there could be efficient
> route aggregation.  If you search through threads you will see that
> there is violent opposition by end users who want to be provider
> independent.
> 
Perhaps I'm being dense, but I don't understand how using PA space is going to save any routing table entries.  If I get a /20 from one of my providers, I have to announce it as a /20 through all of my providers.  How is this more efficient than receiving a /20 from ARIN and announcing that over multiple providers?  Same goes for IPv6.

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080916/dc4bd432/attachment.sig>

From kkargel at polartel.com  Tue Sep 16 12:15:48 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 16 Sep 2008 11:15:48 -0500
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031604A64237@ad-exh01.adhost.lan>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
	<17838240D9A5544AAA5FF95F8D52031604A64237@ad-exh01.adhost.lan>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AFC@mail>

 

> -----Original Message-----
> From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] 
> Sent: Tuesday, September 16, 2008 10:31 AM
> To: Kevin Kargel; PPML
> Subject: RE: [arin-ppml] CIDR v2.0
> 
> > 
> > The difficulty with this is that we already have problems 
> of hardware 
> > that is insufficient to support the routing tables.  ISP's 
> are already 
> > filtering long CIDR routes (>24bit) because there isn't sufficient 
> > memory or processor in the hardware to support the number 
> of routes it 
> > would require.
> > 
> > Your idea would work, but only if we got rid of PI space and forced 
> > everyone to use IP space from their ISP so that there could be 
> > efficient route aggregation.  If you search through threads 
> you will 
> > see that there is violent opposition by end users who want to be 
> > provider independent.
> > 
> Perhaps I'm being dense, but I don't understand how using PA 
> space is going to save any routing table entries.  If I get a 
> /20 from one of my providers, I have to announce it as a /20 
> through all of my providers.  How is this more efficient than 
> receiving a /20 from ARIN and announcing that over multiple 
> providers?  Same goes for IPv6.
> 
> Mike
> 

Exactly, that is why routers and route tables have a problem with small PI
networks.
It works if you are not multi-homed, or if all of your multi-home providers
have peering agreements with the provider of your PA space..  In those
scenarios route aggregation can be effective.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080916/bdf7cf2b/attachment.bin>

From bmanning at vacation.karoshi.com  Tue Sep 16 14:23:39 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 16 Sep 2008 18:23:39 +0000
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
Message-ID: <20080916182339.GA27959@vacation.karoshi.com.>


	Kevin, 
		in some ideal world, aggregation into some small set of
	"ISP" space would be fine.  but things have not worked out that way.
	for efficent address utilization, I expect we will see >24 bit allocations
	more and more.  esp if that is all you need to support a translation function.

--bill



On Tue, Sep 16, 2008 at 08:11:51AM -0500, Kevin Kargel wrote:
> The difficulty with this is that we already have problems of hardware
> that is insufficient to support the routing tables.  ISP's are already
> filtering long CIDR routes (>24bit) because there isn't sufficient
> memory or processor in the hardware to support the number of routes it
> would require.  
> 
> Your idea would work, but only if we got rid of PI space and forced
> everyone to use IP space from their ISP so that there could be efficient
> route aggregation.  If you search through threads you will see that
> there is violent opposition by end users who want to be provider
> independent.
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Iljitsch van Beijnum
> > Sent: Tuesday, September 16, 2008 5:37 AM
> > To: PPML PPML
> > Subject: [arin-ppml] CIDR v2.0
> > 
> > In the early 1990s IPv4 address space was running out. They 
> > fixed this by changing routing protocols. Maybe we should try 
> > to do that again.
> > 
> > <history>
> > 
> > In the early days of the internet you could only use IPv4 
> > addresses as blocks of 16777216, 65536 or 256 addresses. 256 
> > was too small for most people so 65536 was a popular choice, 
> > but there are only some 16000 of these class B blocks and it 
> > was looking like those would be exhausted by the mid-1990s. 
> > So they started giving people a bunch of class C blocks (256 
> > addresses each) but now the routing tables started to explode 
> > because a university that needed a single class B block 
> > before now used something like 16 class C blocks, which had 
> > to appear in routing tables individually. To fix this, 
> > routing protocols, especially BGP, were changed to be able to 
> > work with address blocks of arbitrary power of two sizes so 
> > address space and routing table slots could be managed much 
> > more efficiently. (This is "classless interdomain routing".)
> > 
> > </history>
> > 
> > Now that IPv4 address space is becoming scarce again, why not 
> > do the same thing again? But now rather than arbitrary powers 
> > of 2, we modify the protocols to work with arbitrary address 
> > ranges. I.e., 192.0.2.27
> > - 192.0.2.43.
> > 
> > To accommodate legacy routers that can't do lookups based on 
> > ranges we can put in backward compatibility mechanisms from 
> > BGP5 to BGP4 similar to the ones from BGP4 (with CIDR) to 
> > BGP3 (no CIDR).
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to 
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From kkargel at polartel.com  Tue Sep 16 14:52:43 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 16 Sep 2008 13:52:43 -0500
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <20080916182339.GA27959@vacation.karoshi.com.>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
	<20080916182339.GA27959@vacation.karoshi.com.>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10AFE@mail>

I wasn't advocating enforced route aggregation as a viable method..  I was
just stating it is the only way I know of to allow >24bit network
allocations and make them work given todays routing hardware.

If route tables are going to multiply, which is what would happen if subC PI
networks became common, routing hardware would have to make a quantum leap
in power.  

I run mid level (Cisco 10K, 72xx, 76xx) enterprise routers, and they do not
have a lot of excess space or power for the route tables I manage today.
Even doubling or tripling the size of the route tables would cause problems,
much less the increase we would see if sub-C PI space became common.  

I am sure that there are millions of business cases for routing sub-C
networks, but stuffing the route tables like that before hardware to handle
them is available and affordable will bring us to critical mass in short
order.


> -----Original Message-----
> From: bmanning at vacation.karoshi.com 
> [mailto:bmanning at vacation.karoshi.com] 
> Sent: Tuesday, September 16, 2008 1:24 PM
> To: Kevin Kargel
> Cc: PPML
> Subject: Re: [arin-ppml] CIDR v2.0
> 
> 
> 	Kevin, 
> 		in some ideal world, aggregation into some small set of
> 	"ISP" space would be fine.  but things have not worked 
> out that way.
> 	for efficent address utilization, I expect we will see 
> >24 bit allocations
> 	more and more.  esp if that is all you need to support 
> a translation function.
> 
> --bill
> 
> 
> 
> On Tue, Sep 16, 2008 at 08:11:51AM -0500, Kevin Kargel wrote:
> > The difficulty with this is that we already have problems 
> of hardware 
> > that is insufficient to support the routing tables.  ISP's 
> are already 
> > filtering long CIDR routes (>24bit) because there isn't sufficient 
> > memory or processor in the hardware to support the number 
> of routes it 
> > would require.
> > 
> > Your idea would work, but only if we got rid of PI space and forced 
> > everyone to use IP space from their ISP so that there could be 
> > efficient route aggregation.  If you search through threads 
> you will 
> > see that there is violent opposition by end users who want to be 
> > provider independent.
> > 
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net
> > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Iljitsch van 
> > > Beijnum
> > > Sent: Tuesday, September 16, 2008 5:37 AM
> > > To: PPML PPML
> > > Subject: [arin-ppml] CIDR v2.0
> > > 
> > > In the early 1990s IPv4 address space was running out. They fixed 
> > > this by changing routing protocols. Maybe we should try 
> to do that 
> > > again.
> > > 
> > > <history>
> > > 
> > > In the early days of the internet you could only use IPv4 
> addresses 
> > > as blocks of 16777216, 65536 or 256 addresses. 256 was 
> too small for 
> > > most people so 65536 was a popular choice, but there are 
> only some 
> > > 16000 of these class B blocks and it was looking like 
> those would be 
> > > exhausted by the mid-1990s.
> > > So they started giving people a bunch of class C blocks (256 
> > > addresses each) but now the routing tables started to explode 
> > > because a university that needed a single class B block 
> before now 
> > > used something like 16 class C blocks, which had to appear in 
> > > routing tables individually. To fix this, routing protocols, 
> > > especially BGP, were changed to be able to work with 
> address blocks 
> > > of arbitrary power of two sizes so address space and 
> routing table 
> > > slots could be managed much more efficiently. (This is "classless 
> > > interdomain routing".)
> > > 
> > > </history>
> > > 
> > > Now that IPv4 address space is becoming scarce again, why 
> not do the 
> > > same thing again? But now rather than arbitrary powers of 2, we 
> > > modify the protocols to work with arbitrary address ranges. I.e., 
> > > 192.0.2.27
> > > - 192.0.2.43.
> > > 
> > > To accommodate legacy routers that can't do lookups based 
> on ranges 
> > > we can put in backward compatibility mechanisms from
> > > BGP5 to BGP4 similar to the ones from BGP4 (with CIDR) to
> > > BGP3 (no CIDR).
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to the 
> > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > > 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080916/feae32c9/attachment.bin>

From stephen at sprunk.org  Tue Sep 16 16:19:15 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 16 Sep 2008 15:19:15 -0500
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <20080915010604.GA60456@ussenterprise.ufp.org>
References: <20080912184409.GA84710@ussenterprise.ufp.org>	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>	<20080912202000.GA94971@ussenterprise.ufp.org>	<3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
	<20080915010604.GA60456@ussenterprise.ufp.org>
Message-ID: <48D014C3.6020109@sprunk.org>

Leo Bicknell wrote:
> In a message written on Mon, Sep 15, 2008 at 07:26:54AM +1000, Geoff Huston wrote:
>   
>> The current value is 0.4322 (unadvertised addresses are 43.22% of the  
>> advertised address) Which means that of the total allocated address pool, 30.17% of the addresses are not _currently_ advertised into my particular view of the global routing table.
>>     
>
> I wonder if any of the parties could easily re-generate the numbers for two groups of addresses, those allocated prior to December 1997 (ARIN's founding date), and those after.
>   

The only official stats I've seen that break out legacy assignments are at:
http://www.arin.net/meetings/minutes/ARIN_XIX/PDF/monday/Legacy_stats_Plzak.pdf

According to that preso, 56% of legacy assignments that don't show up, 
even partially, in the DFZ.  Also, 52% of the network records and 48% of 
org records haven't been updated since 1997 and I'll wager there is a 
very high correlation between the sets.  Some is in private use, sure, 
but a lot of that space that has been abandoned and could be reclaimed 
with no complaints, if there were policy allowing ARIN to do so.

Unfortunately, those statistics do not account for the varying size of 
legacy blocks; they just count records, which could be anywhere from /8 
to /24.  It is "common knowledge" that the problem is worst at the 
smaller end of the spectrum, but I personally know of more Class B (er, 
/16) blocks than Class C (er, /24) ones that aren't in use, so I wonder 
how correct that assumption is.

Not that any of this is going to make any significant difference to the 
exhaustion date, but IMHO it does make ARIN less of a target for 
complaints (legal or moral) if we've cleaned up the most obvious waste 
of space before we have to start denying qualified new applicants.

S


From bicknell at ufp.org  Tue Sep 16 16:52:37 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 16 Sep 2008 16:52:37 -0400
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <48D014C3.6020109@sprunk.org>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
	<20080912202000.GA94971@ussenterprise.ufp.org>
	<3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>
	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
	<20080915010604.GA60456@ussenterprise.ufp.org>
	<48D014C3.6020109@sprunk.org>
Message-ID: <20080916205236.GA45300@ussenterprise.ufp.org>

In a message written on Tue, Sep 16, 2008 at 03:19:15PM -0500, Stephen Sprunk wrote:
> The only official stats I've seen that break out legacy assignments are at:
> http://www.arin.net/meetings/minutes/ARIN_XIX/PDF/monday/Legacy_stats_Plzak.pdf
> 
> According to that preso, 56% of legacy assignments that don't show up, 
> even partially, in the DFZ.  Also, 52% of the network records and 48% of 

That is what I figured would be the case.

> Not that any of this is going to make any significant difference to the 
> exhaustion date, but IMHO it does make ARIN less of a target for 
> complaints (legal or moral) if we've cleaned up the most obvious waste 
> of space before we have to start denying qualified new applicants.

I agree 100% this will make no significant difference in the IPv4
exhaustion date.  My worry here has nothing to do with "extending"
IPv4.

Today there is a very limited motivation to hijack these fallow
blocks.  Generally hijacking is only done by "bad actors" pushing
spam or malware, and thus is a relatively minor problem that can
be kept under control.

When there are no more free IPv4 addresses though everyone who needs
space has an instant motive to hijack a unused legacy block.  This
activity could grow quite frenzied quite quickly, and cause ARIN
to expend a lot of time and effort to try and keep records accurate.

I would much prefer if this space was all returned to the free pool
first such that it could be given out and used actively, and thus
not be a hijacking target.

I think we need to find a way to solve this, and solve it quickly.
If it means we have to let someone using a single IP address keep
their /16, that's fine with me as long as it is announced on the
global internet.  The legacy space problem isn't about taking away
anyone's space.

Unfortunately I can't think of a more effective way to figure out
which space to reclaim than to tell all those still using the space
to sign a contract and pay a fee yearly, and any block without a
contract after a particular date will be automatically reclaimed.

It's quite possible the LRSA still needs work to accomplish this goal,
but the time is fading fast.

The down side is huge, if 56% of the legacy space ends up being a
"free for all" of hijackers trying to get space it will cost all
of us in the form of huge operational issues, costs for ARIN, and
ultimately the decrease in value of IPv4.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080916/e4d2ec29/attachment.sig>

From bmanning at vacation.karoshi.com  Tue Sep 16 16:55:07 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 16 Sep 2008 20:55:07 +0000
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10AFE@mail>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
	<20080916182339.GA27959@vacation.karoshi.com.>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AFE@mail>
Message-ID: <20080916205507.GB29768@vacation.karoshi.com.>

 soooo... you see real problems with accepting /32 prefixes in IPv6 space
then.  (since there are the same number of /32's in either family).

--bill


On Tue, Sep 16, 2008 at 01:52:43PM -0500, Kevin Kargel wrote:
> I wasn't advocating enforced route aggregation as a viable method..  I was
> just stating it is the only way I know of to allow >24bit network
> allocations and make them work given todays routing hardware.
> 
> If route tables are going to multiply, which is what would happen if subC PI
> networks became common, routing hardware would have to make a quantum leap
> in power.  
> 
> I run mid level (Cisco 10K, 72xx, 76xx) enterprise routers, and they do not
> have a lot of excess space or power for the route tables I manage today.
> Even doubling or tripling the size of the route tables would cause problems,
> much less the increase we would see if sub-C PI space became common.  
> 
> I am sure that there are millions of business cases for routing sub-C
> networks, but stuffing the route tables like that before hardware to handle
> them is available and affordable will bring us to critical mass in short
> order.
> 
> 
> > -----Original Message-----
> > From: bmanning at vacation.karoshi.com 
> > [mailto:bmanning at vacation.karoshi.com] 
> > Sent: Tuesday, September 16, 2008 1:24 PM
> > To: Kevin Kargel
> > Cc: PPML
> > Subject: Re: [arin-ppml] CIDR v2.0
> > 
> > 
> > 	Kevin, 
> > 		in some ideal world, aggregation into some small set of
> > 	"ISP" space would be fine.  but things have not worked 
> > out that way.
> > 	for efficent address utilization, I expect we will see 
> > >24 bit allocations
> > 	more and more.  esp if that is all you need to support 
> > a translation function.
> > 
> > --bill
> > 
> > 
> > 
> > On Tue, Sep 16, 2008 at 08:11:51AM -0500, Kevin Kargel wrote:
> > > The difficulty with this is that we already have problems 
> > of hardware 
> > > that is insufficient to support the routing tables.  ISP's 
> > are already 
> > > filtering long CIDR routes (>24bit) because there isn't sufficient 
> > > memory or processor in the hardware to support the number 
> > of routes it 
> > > would require.
> > > 
> > > Your idea would work, but only if we got rid of PI space and forced 
> > > everyone to use IP space from their ISP so that there could be 
> > > efficient route aggregation.  If you search through threads 
> > you will 
> > > see that there is violent opposition by end users who want to be 
> > > provider independent.
> > > 
> > > > -----Original Message-----
> > > > From: arin-ppml-bounces at arin.net
> > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Iljitsch van 
> > > > Beijnum
> > > > Sent: Tuesday, September 16, 2008 5:37 AM
> > > > To: PPML PPML
> > > > Subject: [arin-ppml] CIDR v2.0
> > > > 
> > > > In the early 1990s IPv4 address space was running out. They fixed 
> > > > this by changing routing protocols. Maybe we should try 
> > to do that 
> > > > again.
> > > > 
> > > > <history>
> > > > 
> > > > In the early days of the internet you could only use IPv4 
> > addresses 
> > > > as blocks of 16777216, 65536 or 256 addresses. 256 was 
> > too small for 
> > > > most people so 65536 was a popular choice, but there are 
> > only some 
> > > > 16000 of these class B blocks and it was looking like 
> > those would be 
> > > > exhausted by the mid-1990s.
> > > > So they started giving people a bunch of class C blocks (256 
> > > > addresses each) but now the routing tables started to explode 
> > > > because a university that needed a single class B block 
> > before now 
> > > > used something like 16 class C blocks, which had to appear in 
> > > > routing tables individually. To fix this, routing protocols, 
> > > > especially BGP, were changed to be able to work with 
> > address blocks 
> > > > of arbitrary power of two sizes so address space and 
> > routing table 
> > > > slots could be managed much more efficiently. (This is "classless 
> > > > interdomain routing".)
> > > > 
> > > > </history>
> > > > 
> > > > Now that IPv4 address space is becoming scarce again, why 
> > not do the 
> > > > same thing again? But now rather than arbitrary powers of 2, we 
> > > > modify the protocols to work with arbitrary address ranges. I.e., 
> > > > 192.0.2.27
> > > > - 192.0.2.43.
> > > > 
> > > > To accommodate legacy routers that can't do lookups based 
> > on ranges 
> > > > we can put in backward compatibility mechanisms from
> > > > BGP5 to BGP4 similar to the ones from BGP4 (with CIDR) to
> > > > BGP3 (no CIDR).
> > > > _______________________________________________
> > > > PPML
> > > > You are receiving this message because you are subscribed to the 
> > > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > Unsubscribe or manage your mailing list subscription at:
> > > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > Please contact info at arin.net if you experience any issues.
> > > > 
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed 
> > to the ARIN 
> > > Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > 



> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From bicknell at ufp.org  Tue Sep 16 16:58:57 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 16 Sep 2008 16:58:57 -0400
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <20080916205507.GB29768@vacation.karoshi.com.>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
	<20080916182339.GA27959@vacation.karoshi.com.>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AFE@mail>
	<20080916205507.GB29768@vacation.karoshi.com.>
Message-ID: <20080916205857.GA46610@ussenterprise.ufp.org>

In a message written on Tue, Sep 16, 2008 at 08:55:07PM +0000, bmanning at vacation.karoshi.com wrote:
>  soooo... you see real problems with accepting /32 prefixes in IPv6 space
> then.  (since there are the same number of /32's in either family).

There's a big difference between populating the IPv4 table with
/32's by 2020, and fully populating the IPv6 table with them by
2080.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080916/4c08d373/attachment.sig>

From george at dmu.edu  Tue Sep 16 17:26:31 2008
From: george at dmu.edu (Davey, George)
Date: Tue, 16 Sep 2008 16:26:31 -0500
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <20080916205236.GA45300@ussenterprise.ufp.org>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
	<20080912202000.GA94971@ussenterprise.ufp.org>
	<3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>
	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
	<20080915010604.GA60456@ussenterprise.ufp.org>	<48D014C3.6020109@sprunk.org>
	<20080916205236.GA45300@ussenterprise.ufp.org>
Message-ID: <C43F8F3AB0C0E64795715C179C1E86801CCF20EB1D@WILMA>

> I agree 100% this will make no significant difference in the IPv4 exhaustion date.  My worry here has nothing to do with "extending"
IPv4.
Then don't waste your time doing it or writing about doing it.

> I would much prefer if this space was all returned to the free pool first such that it could be given out and used actively, and thus not be a hijacking target.
99.9% Hacking/spamming occurs from compromised Windows boxes connected on properly allocated non-legacy IP blocks, such as rr.com DSL for instance.

> Unfortunately I can't think of a more effective way to figure out which space to reclaim than to tell all those still using the space to sign a contract and pay a fee yearly, and any block without a contract after a particular date will be automatically reclaimed.

Alas the true motive is spoken, getting more people to buy into the LRSA scam.


Maybe I am the only one that seems to see a sense of repetition gravitating toward selling of the LRSA agreement using different carrots and bogus scams and stats.
I feel like I am stuck in quick sand....or like I am being brainwashed.


George Davey, B.S. MCSE
Network Administrator
3200 Grand Avenue
Des Moines, IA  50312
515.271.1544
FAX 515.271.4200
George.Davey at dmu.edu
www.dmu.edu



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell
Sent: Tuesday, September 16, 2008 3:53 PM
To: ppml at arin.net
Subject: Re: [arin-ppml] Taking back UNUSED addresses.

In a message written on Tue, Sep 16, 2008 at 03:19:15PM -0500, Stephen Sprunk wrote:
> The only official stats I've seen that break out legacy assignments are at:
> http://www.arin.net/meetings/minutes/ARIN_XIX/PDF/monday/Legacy_stats_
> Plzak.pdf
>
> According to that preso, 56% of legacy assignments that don't show up,
> even partially, in the DFZ.  Also, 52% of the network records and 48%
> of

That is what I figured would be the case.

> Not that any of this is going to make any significant difference to
> the exhaustion date, but IMHO it does make ARIN less of a target for
> complaints (legal or moral) if we've cleaned up the most obvious waste
> of space before we have to start denying qualified new applicants.

I agree 100% this will make no significant difference in the IPv4 exhaustion date.  My worry here has nothing to do with "extending"
IPv4.

Today there is a very limited motivation to hijack these fallow blocks.  Generally hijacking is only done by "bad actors" pushing spam or malware, and thus is a relatively minor problem that can be kept under control.

When there are no more free IPv4 addresses though everyone who needs space has an instant motive to hijack a unused legacy block.  This activity could grow quite frenzied quite quickly, and cause ARIN to expend a lot of time and effort to try and keep records accurate.

I would much prefer if this space was all returned to the free pool first such that it could be given out and used actively, and thus not be a hijacking target.

I think we need to find a way to solve this, and solve it quickly.
If it means we have to let someone using a single IP address keep their /16, that's fine with me as long as it is announced on the global internet.  The legacy space problem isn't about taking away anyone's space.

Unfortunately I can't think of a more effective way to figure out which space to reclaim than to tell all those still using the space to sign a contract and pay a fee yearly, and any block without a contract after a particular date will be automatically reclaimed.

It's quite possible the LRSA still needs work to accomplish this goal, but the time is fading fast.

The down side is huge, if 56% of the legacy space ends up being a "free for all" of hijackers trying to get space it will cost all of us in the form of huge operational issues, costs for ARIN, and ultimately the decrease in value of IPv4.

--
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/


From dwcarder at wisc.edu  Tue Sep 16 17:26:35 2008
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Tue, 16 Sep 2008 16:26:35 -0500
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <48D014C3.6020109@sprunk.org>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
	<20080912202000.GA94971@ussenterprise.ufp.org>
	<3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>
	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
	<20080915010604.GA60456@ussenterprise.ufp.org>
	<48D014C3.6020109@sprunk.org>
Message-ID: <5C97F2E1-0263-4306-B35A-3FD3E026AB9F@wisc.edu>


On Sep 16, 2008, at 3:19 PM, Stephen Sprunk wrote:
>  Also, 52% of the network records and 48% of org records
> haven't been updated since 1997

For one datapoint, we have been at the same street address
as when we were on CSNET 20+ years ago.  My guess would be
that not a whole lot of legacy .edu's have moved that couldn't
be found easily.

> Unfortunately, those statistics do not account for the varying
> size of legacy blocks; they just count records, which could be
> anywhere from /8 to /24.

We've returned most of our swamp /24's that I know of, but
I doubt having substantially more of the swamp show up in the
DFZ would be in everyone's best interest.

Dale



From cgrundemann at gmail.com  Tue Sep 16 19:15:17 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 16 Sep 2008 17:15:17 -0600
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <C43F8F3AB0C0E64795715C179C1E86801CCF20EB1D@WILMA>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
	<20080912202000.GA94971@ussenterprise.ufp.org>
	<3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>
	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
	<20080915010604.GA60456@ussenterprise.ufp.org>
	<48D014C3.6020109@sprunk.org>
	<20080916205236.GA45300@ussenterprise.ufp.org>
	<C43F8F3AB0C0E64795715C179C1E86801CCF20EB1D@WILMA>
Message-ID: <443de7ad0809161615y2267d5c1k85e2d3a41b78eeeb@mail.gmail.com>

On Tue, Sep 16, 2008 at 2:52 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> Unfortunately I can't think of a more effective way to figure out
> which space to reclaim than to tell all those still using the space
> to sign a contract and pay a fee yearly, and any block without a
> contract after a particular date will be automatically reclaimed.
>
What about cleaning up WHOIS?  There are two policy proposals that aim
to (among other things) locate fallow space by identifying any space
with no active POC.  Would that be an effective approach, in your
opinion?

On Tue, Sep 16, 2008 at 3:26 PM, Davey, George <george at dmu.edu> wrote:
> 99.9% Hacking/spamming occurs from compromised Windows boxes connected on properly allocated non-legacy IP blocks, such as rr.com DSL for instance.
>
I believe the hijacking referred to is more along the line of ORG X
deciding to "take" an orphaned block and start using it or assigning
it to customers.  Since there is no legitimate way to record this
squatting in a meaningful way; there is not a lot stopping multiple
bad actors to do the same thing and create quite a mess.  Of course
even if all space is in use (being advertised) there remains the
potential that ORG X decide to "take" a block that is in use on the
other side of the globe and start using it.  The difference is that in
the second scenario, the rightful owner of the hijacked block will
more than likely notice and report the hijacking.  In the first
scenario, chaos reigns as the rightful owner is not a player.


-- 
Chris Grundemann
www.linkedin.com/in/cgrundemann


From bmanning at vacation.karoshi.com  Tue Sep 16 19:47:52 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 16 Sep 2008 23:47:52 +0000
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <20080916205857.GA46610@ussenterprise.ufp.org>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
	<20080916182339.GA27959@vacation.karoshi.com.>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AFE@mail>
	<20080916205507.GB29768@vacation.karoshi.com.>
	<20080916205857.GA46610@ussenterprise.ufp.org>
Message-ID: <20080916234752.GA31467@vacation.karoshi.com.>

On Tue, Sep 16, 2008 at 04:58:57PM -0400, Leo Bicknell wrote:
> In a message written on Tue, Sep 16, 2008 at 08:55:07PM +0000, bmanning at vacation.karoshi.com wrote:
> >  soooo... you see real problems with accepting /32 prefixes in IPv6 space
> > then.  (since there are the same number of /32's in either family).
> 
> There's a big difference between populating the IPv4 table with
> /32's by 2020, and fully populating the IPv6 table with them by
> 2080.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/


	assuming facts not in evidence.  check out Eugene Spafford or Rod VanMeters
analysis of the effects of the end of Moores Law within the decade(2020).  Or are you making
a prediction on the state of routing protocols in the next half-century?  Could be you
are betting on full up quantum computing being a commercially viable tool in that timeframe.

quite frankly i find the idea of a routing table fully populated w/ /32's daunting.
regarding the existance of /32's in the routing table today, yeah, I see them.

--bill



From jmaimon at chl.com  Tue Sep 16 20:42:45 2008
From: jmaimon at chl.com (Joe Maimon)
Date: Tue, 16 Sep 2008 20:42:45 -0400
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <D8368E540714E245882EFDCF161241710C99BBE6@EXNJMB49.nam.nsroot.net>
References: <20080912184409.GA84710@ussenterprise.ufp.org><3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com><20080912202000.GA94971@ussenterprise.ufp.org><3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
	<D8368E540714E245882EFDCF161241710C99BBE6@EXNJMB49.nam.nsroot.net>
Message-ID: <48D05285.4080802@chl.com>



Berse, Ryan E wrote:
> When looking at these numbers, you need to keep in mind that just
> because a particular block of space is not advertised to the (public)
> Internet does not mean it is unused.  Organizations also use their
> registered address space on B2B links between their own network and
> those of partners/clients/vendors/etc.  I would bet such use accounts
> for a significant chunk of the allocated but unadvertised space.
> Attempting to reclaim such space would probably meet with fierce
> resistance from the registrants (especially if legacy) and their legal
> departments.  
> 
> Ryan
> 


With which exact legal leg to stand on? What contract do they have with 
whom that prevents ARIN from writing down in its book that some other 
organization is now associated with a set of numbers?

Suppose it was my book. Suppose I published a blog where I randomly 
associated ranges of 32 bit numbers to organizations and friends of 
mine. Suppose I even took "donations" to run this blog. What cause of 
action would you have to stop me from doing so with some arbitrary 
subset of those 32 bit numbers?

And suppose ARIN is indeed immune to those whom it does not have a 
contractual relationship. Who else would you go after? The organization 
now trying to use those numbers on this shared network called the internet?

What legal leg does an organization have to stand on when another 
organization claims the use of some set of numbers they feel somehow 
"belong" to them?

Here is a fairly non-malicious example.

Suppose org a has swamp space x/8, they dont advertise it to the world, 
they use it only on b2b links. Suppose org b decides to also use x/8 on 
their b2b links. Suppose org a wants to stop org b from doing so. What 
legal theory would they use?

When a real hijacking of active ip space happens, what legal wheel 
turning occurs then? I havent heard of anything much.

Numbers dont belong to anyone. The use of a set of numbers on a shared 
network is _tracked_ centrally *by consensus*, because of the mutual 
common benefit that brings.

This consensus is lot weaker for non-advertised space, precisely because 
the benefits consensus brings there is some fraction as compared to 
advertised.

Networks operate according to or enter into contract with this central 
tracking _voluntarily_, and most do so with varying amounts of exceptions.

Before too long, things may degenerate to the point that this becomes 
more than armchair wrangling.

Joe


From jmaimon at chl.com  Tue Sep 16 21:03:40 2008
From: jmaimon at chl.com (Joe Maimon)
Date: Tue, 16 Sep 2008 21:03:40 -0400
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
Message-ID: <48D0576C.8070005@chl.com>

This is a joke, right? Arent you of the ipv6 do or die persuasion?

> 
> Now that IPv4 address space is becoming scarce again, why not do the  
> same thing again? But now rather than arbitrary powers of 2, we modify  
> the protocols to work with arbitrary address ranges. I.e., 192.0.2.27  
> - 192.0.2.43.

Yes, and we will use something other than binary to describe the ranges.


From iljitsch at muada.com  Wed Sep 17 03:20:44 2008
From: iljitsch at muada.com (Iljitsch van Beijnum)
Date: Wed, 17 Sep 2008 09:20:44 +0200
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <48D0576C.8070005@chl.com>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
	<48D0576C.8070005@chl.com>
Message-ID: <88416C84-2168-4E8A-B1F4-0FB8F307727B@muada.com>

On 17 sep 2008, at 3:03, Joe Maimon wrote:

> This is a joke, right?

No. I think it's a good way to free up address space that would  
otherwise go to waste because of the need to use power of two address  
blocks. Not that I think it's going to happen anytime soon... Just  
like with any problem, the issue isn't finding a solution, but paying  
the price.

> Arent you of the ipv6 do or die persuasion?

IPv6 is the way forward. But even if you run IPv6, you can't turn off  
IPv4 just yet so we collectively need to figure out what to do with it  
until we can.


From bicknell at ufp.org  Wed Sep 17 09:10:03 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 17 Sep 2008 09:10:03 -0400
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <20080916234752.GA31467@vacation.karoshi.com.>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AF5@mail>
	<20080916182339.GA27959@vacation.karoshi.com.>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10AFE@mail>
	<20080916205507.GB29768@vacation.karoshi.com.>
	<20080916205857.GA46610@ussenterprise.ufp.org>
	<20080916234752.GA31467@vacation.karoshi.com.>
Message-ID: <20080917131003.GA11164@ussenterprise.ufp.org>

In a message written on Tue, Sep 16, 2008 at 11:47:52PM +0000, bmanning at vacation.karoshi.com wrote:
> 	assuming facts not in evidence.  check out Eugene Spafford or Rod VanMeters
> analysis of the effects of the end of Moores Law within the decade(2020).  Or are you making
> a prediction on the state of routing protocols in the next half-century?  Could be you
> are betting on full up quantum computing being a commercially viable tool in that timeframe.

I am assuming that an extra 50 years of technology will find some
solution to the problem.  Faster chips?  Better software?  I don't
know.

If I had a nickel for every time someone predicted technology would
stop advancing and was wrong I'd be the richest man in the world.
Maybe mores law fails by 2020, but something new will come along.
It always does.

Even if technology can't meet the needs, having 50 more years to
figure out another way around the problem is better than 10.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080917/59716a04/attachment.sig>

From kkargel at polartel.com  Wed Sep 17 09:15:02 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 17 Sep 2008 08:15:02 -0500
Subject: [arin-ppml] CIDR v2.0
In-Reply-To: <88416C84-2168-4E8A-B1F4-0FB8F307727B@muada.com>
References: <EF2DCBB5-D0C0-4853-959F-D1A71F9FC714@muada.com><48D0576C.8070005@chl.com>
	<88416C84-2168-4E8A-B1F4-0FB8F307727B@muada.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B05@mail>

^2 is in use because that is the architecture the hardware runs on.  The
routers and computers are binary machines.  From the routers point of view
things like octal and hex or even decimal don't exist, they are just
notations representing binary to make it more useable for we limited humans.
"digital" is based on two digits, not ten.

I am sure that if someone wants to build a production computer that uses
base-8 or even decimal instead of binary the world will be thrilled, but I
haven't seen any evidence of viable many-state quantum logic yet. 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Iljitsch van Beijnum
> Sent: Wednesday, September 17, 2008 2:21 AM
> To: Joe Maimon
> Cc: PPML PPML
> Subject: Re: [arin-ppml] CIDR v2.0
> 
> On 17 sep 2008, at 3:03, Joe Maimon wrote:
> 
> > This is a joke, right?
> 
> No. I think it's a good way to free up address space that 
> would otherwise go to waste because of the need to use power 
> of two address blocks. Not that I think it's going to happen 
> anytime soon... Just like with any problem, the issue isn't 
> finding a solution, but paying the price.
> 
> > Arent you of the ipv6 do or die persuasion?
> 
> IPv6 is the way forward. But even if you run IPv6, you can't turn off
> IPv4 just yet so we collectively need to figure out what to 
> do with it until we can.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080917/fa8b9dae/attachment.bin>

From michael.dillon at bt.com  Wed Sep 17 11:15:40 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 17 Sep 2008 16:15:40 +0100
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <200809071201.m87C18QR012303@cjbsys.bdb.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC0819562A@E03MVZ2-UKDY.domain1.systemhost.net>

> I posted this once before (July 07) but it may be worth 
> looking at again.  I see no reference to any document about 
> "right to recall", fees, etc etc.  It just says here's your 
> addresses.  I don't have an AS but my upstream ISP does and I 
> assume they have permission to connect to the internet. :-)
> 
> http://www.bdb.com/~cliffb/bdb_netreg.jpg

Seems to me that they gave you the right to use these addresses
on the ARPA Internet and the DDN Internet, subject to the permission
of these network operators. But they did not give you the right
to use these addresses on the public commercial Internet.

--Michael Dillon




From vixie at isc.org  Wed Sep 17 18:33:02 2008
From: vixie at isc.org (Paul Vixie)
Date: Wed, 17 Sep 2008 22:33:02 +0000
Subject: [arin-ppml] "IPv6 and the Business-Case Skeptics" (slashdot)
Message-ID: <42672.1221690782@nsa.vix.com>

"Experts keep screaming that the IPv4 sky is falling. Three such experts
were recently asked point-blank to state an irrefutable business case for
moving to IPv6 now, and their answer was more plausible than the old
refrain (the lack of addresses and a yet-to-be-seen killer IPv6 app). They
said that there isn't a business case. No company that is satisfied with
all of its Internet services will need to move, even in the next few
years. They also pointed out that Microsoft is a unique position in the
industry both causing and hindering adoption IPv6 causing through its IPv6
support in its OSes, and hindering by not extending IPv6 support into very
many of its apps."
 
http://tech.slashdot.org/article.pl?sid=08/09/16/1828231


From cliffb at cjbsys.bdb.com  Wed Sep 17 19:39:27 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Wed, 17 Sep 2008 19:39:27 -0400 (EDT)
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC0819562A@E03MVZ2-UKDY.domain1.systemhost.net>
	from "michael.dillon@bt.com" at Sep 17, 2008 04:15:40 PM
Message-ID: <200809172339.m8HNdRo1024741@cjbsys.bdb.com>

> 
> > I posted this once before (July 07) but it may be worth 
> > looking at again.  I see no reference to any document about 
> > "right to recall", fees, etc etc.  It just says here's your 
> > addresses.  I don't have an AS but my upstream ISP does and I 
> > assume they have permission to connect to the internet. :-)
> > 
> > http://www.bdb.com/~cliffb/bdb_netreg.jpg
> 
> Seems to me that they gave you the right to use these addresses
> on the ARPA Internet and the DDN Internet, subject to the permission
> of these network operators. But they did not give you the right
> to use these addresses on the public commercial Internet.

Well Duh.  There wasn't one then.  They gave me the numbers as unique numbers
out of the entire IPv4 address space.  I now have contracted with an ISP who 
has agreed to give me the right to be on the commercial Internet using numbers
given me by the people who controlled the unique IPv4 address space.  

What the letter said was that I needed separate authorization to connect to
ARPANET or DDN.  Since I never connected to them, I never got that permission.
Remember back then, 32 bits was more than they'd ever use (like 64 Kbytes of
RAM on CPM systems)  They were in fact "guaranteed" to be unique and mine in
the whole IPv4 universe.

Cliff
> 
> --Michael Dillon
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20740
cliffb at cjbsys.bdb.com http://www.bdb.com
Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/


From joelja at bogus.com  Wed Sep 17 19:38:14 2008
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 17 Sep 2008 16:38:14 -0700
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <48D014C3.6020109@sprunk.org>
References: <20080912184409.GA84710@ussenterprise.ufp.org>	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>	<20080912202000.GA94971@ussenterprise.ufp.org>	<3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>	<20080915010604.GA60456@ussenterprise.ufp.org>
	<48D014C3.6020109@sprunk.org>
Message-ID: <48D194E6.5060902@bogus.com>

Stephen Sprunk wrote:
> Unfortunately, those statistics do not account for the varying size of 
> legacy blocks; they just count records, which could be anywhere from /8 
> to /24.  It is "common knowledge" that the problem is worst at the 
> smaller end of the spectrum, but I personally know of more Class B (er, 
> /16) blocks than Class C (er, /24) ones that aren't in use, so I wonder 
> how correct that assumption is.

In the swamp there is a Record for each class C. If you didn't update
them, Then 4 contiguous class-c blocks (/22) have 4 records...





From jrhett at svcolo.com  Wed Sep 17 20:39:24 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 17 Sep 2008 17:39:24 -0700
Subject: [arin-ppml] would you support a proposal to tighten usage
	documentation requirements?
Message-ID: <DBD0B920-CDE2-4203-8FCF-F675E5316C5C@svcolo.com>

I'd like to get some feedback on the following.  Just tell me if you  
think it's a good idea or not.  The specifics would have to be  
hammered out, obviously.  This is a "thumbs up/down" poll.

Problem: right now the NRPM doesn't document explicitly what  
information to provide to document usage information.  Many non-ARIN  
people read it and get the impression that saying "I have 50 hosts" is  
enough to justify their usage.  Section 4.2.3.7.5 says "No. of  
Internal Machines".

Talking with ARIN staff, they agree that explicit examples might be a  
good thing to have in the book.  They do *not* feel that limiting the  
input to a specific format would go over well, but it would certainly  
make their job easier.

I therefore propose to write up a policy proposal with the following  
goals.  Tell me whether or not you'd support it.  I hate pissing  
upwind, so I'm only going to spend time doing this if enough of you  
guys and gals think this is a good idea.

1. Replace section 4.2.3.7.5 with some explicit examples of acceptable  
input.

2. Change the NRPM wording to say that any documentation provided that  
doesn't match the supplied guidelines will be evaluated on a case-by- 
case basis.

NOTE: This would not change ARIN acceptance guidelines.  This would  
simply better document the existing evaluation process.

    -or-

A. Codify the acceptable format(s) in a way which is easy for us to  
machine generate.  (starting with the formats we use today so no  
change is necessary)

B. Change the NRPM to require submission in one of the documented  
formats.

NOTE: This *would* change ARIN acceptance guidelines by limiting the  
acceptable submission format.  It would not otherwise change the  
acceptance guidelines.

Frankly, I'm in favor of the latter (alphabetic one) though that will  
come as no surprise to anyone who knows me.  But I'd happily write up  
and support the former (numeric) proposal because it would vastly  
improve the current situation.

And before you reply, repeat after me "Neither of these proposals  
would actually change whether or not a given usage would be acceptable  
for a given allocation size."

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550


From owen at delong.com  Wed Sep 17 21:23:19 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 17 Sep 2008 18:23:19 -0700
Subject: [arin-ppml] would you support a proposal to tighten usage
	documentation requirements?
In-Reply-To: <DBD0B920-CDE2-4203-8FCF-F675E5316C5C@svcolo.com>
References: <DBD0B920-CDE2-4203-8FCF-F675E5316C5C@svcolo.com>
Message-ID: <5FDD1182-B446-4E45-AB8B-51EFF82E003F@delong.com>

I would rather expand upon this in the ACSP and put it into the
operational documentation that stuff it into the NRPM.

Just my $0.02.

Owen

On Sep 17, 2008, at 5:39 PM, Jo Rhett wrote:

> I'd like to get some feedback on the following.  Just tell me if you
> think it's a good idea or not.  The specifics would have to be
> hammered out, obviously.  This is a "thumbs up/down" poll.
>
> Problem: right now the NRPM doesn't document explicitly what
> information to provide to document usage information.  Many non-ARIN
> people read it and get the impression that saying "I have 50 hosts" is
> enough to justify their usage.  Section 4.2.3.7.5 says "No. of
> Internal Machines".
>
> Talking with ARIN staff, they agree that explicit examples might be a
> good thing to have in the book.  They do *not* feel that limiting the
> input to a specific format would go over well, but it would certainly
> make their job easier.
>
> I therefore propose to write up a policy proposal with the following
> goals.  Tell me whether or not you'd support it.  I hate pissing
> upwind, so I'm only going to spend time doing this if enough of you
> guys and gals think this is a good idea.
>
> 1. Replace section 4.2.3.7.5 with some explicit examples of acceptable
> input.
>
> 2. Change the NRPM wording to say that any documentation provided that
> doesn't match the supplied guidelines will be evaluated on a case-by-
> case basis.
>
> NOTE: This would not change ARIN acceptance guidelines.  This would
> simply better document the existing evaluation process.
>
>    -or-
>
> A. Codify the acceptable format(s) in a way which is easy for us to
> machine generate.  (starting with the formats we use today so no
> change is necessary)
>
> B. Change the NRPM to require submission in one of the documented
> formats.
>
> NOTE: This *would* change ARIN acceptance guidelines by limiting the
> acceptable submission format.  It would not otherwise change the
> acceptance guidelines.
>
> Frankly, I'm in favor of the latter (alphabetic one) though that will
> come as no surprise to anyone who knows me.  But I'd happily write up
> and support the former (numeric) proposal because it would vastly
> improve the current situation.
>
> And before you reply, repeat after me "Neither of these proposals
> would actually change whether or not a given usage would be acceptable
> for a given allocation size."
>
> -- 
> Jo Rhett
> senior geek
>
> Silicon Valley Colocation
> Support Phone: 408-400-0550
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080917/75963acf/attachment.p7s>

From bicknell at ufp.org  Wed Sep 17 21:48:37 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 17 Sep 2008 21:48:37 -0400
Subject: [arin-ppml] would you support a proposal to tighten usage
	documentation requirements?
In-Reply-To: <DBD0B920-CDE2-4203-8FCF-F675E5316C5C@svcolo.com>
References: <DBD0B920-CDE2-4203-8FCF-F675E5316C5C@svcolo.com>
Message-ID: <20080918014836.GA74464@ussenterprise.ufp.org>

In a message written on Wed, Sep 17, 2008 at 05:39:24PM -0700, Jo Rhett wrote:
> Talking with ARIN staff, they agree that explicit examples might be a  
> good thing to have in the book.  They do *not* feel that limiting the  
> input to a specific format would go over well, but it would certainly  
> make their job easier.

There is a generic idea that has been floating around for some time
to create a companion to the NRPM.  It has been proposed as a
separate document to provide operational details like you describe,
or as an "annotated" version of the NRPM.

I would be much happier if we could get the community, and then by
extension ARIN behind this idea.  I do believe staff could provide
some additional information in several areas, and a prime one is
the one you mentioned, what forms of documentation are acceptable?
I think having staff publish a representative, but perhaps not all
encompassing set of examples could help a lot of people understand
the policies and how they are implemented.

The problem with putting this sort of information in policy is we
neither want to tie staff's hands by having the policy specify
something that is out of date or otherwise inappropriate nor do we
want to have to put trivial changes (e.g. replace document xyz with
document abc) through the policy process.  For both of these reasons
I am skeptical that the policy process is the right place for this
sort of information.

I would urge you to use ppml to build community support for the
idea and some specific recommendations on areas where this information
should augment the NRPM, and then submit that output to the suggestion
process (ACSP).

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080917/6d59a7ab/attachment.sig>

From jrhett at svcolo.com  Wed Sep 17 22:37:40 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 17 Sep 2008 19:37:40 -0700
Subject: [arin-ppml] would you support a proposal to tighten usage
	documentation requirements?
In-Reply-To: <5FDD1182-B446-4E45-AB8B-51EFF82E003F@delong.com>
References: <DBD0B920-CDE2-4203-8FCF-F675E5316C5C@svcolo.com>
	<5FDD1182-B446-4E45-AB8B-51EFF82E003F@delong.com>
Message-ID: <26A9A8DE-0401-4E94-885E-2A3E7A4B8C1C@svcolo.com>

One of the goals is to give us something to point customers to  
existing policy.  Hiding it behind ARIN doesn't affect the bad  
description "No. of hosts" that exists in the NRPM today.

On Sep 17, 2008, at 6:23 PM, Owen DeLong wrote:
> I would rather expand upon this in the ACSP and put it into the
> operational documentation that stuff it into the NRPM.
>
> Just my $0.02.
>
> Owen
>
> On Sep 17, 2008, at 5:39 PM, Jo Rhett wrote:
>
>> I'd like to get some feedback on the following.  Just tell me if you
>> think it's a good idea or not.  The specifics would have to be
>> hammered out, obviously.  This is a "thumbs up/down" poll.
>>
>> Problem: right now the NRPM doesn't document explicitly what
>> information to provide to document usage information.  Many non-ARIN
>> people read it and get the impression that saying "I have 50 hosts"  
>> is
>> enough to justify their usage.  Section 4.2.3.7.5 says "No. of
>> Internal Machines".
>>
>> Talking with ARIN staff, they agree that explicit examples might be a
>> good thing to have in the book.  They do *not* feel that limiting the
>> input to a specific format would go over well, but it would certainly
>> make their job easier.
>>
>> I therefore propose to write up a policy proposal with the following
>> goals.  Tell me whether or not you'd support it.  I hate pissing
>> upwind, so I'm only going to spend time doing this if enough of you
>> guys and gals think this is a good idea.
>>
>> 1. Replace section 4.2.3.7.5 with some explicit examples of  
>> acceptable
>> input.
>>
>> 2. Change the NRPM wording to say that any documentation provided  
>> that
>> doesn't match the supplied guidelines will be evaluated on a case-by-
>> case basis.
>>
>> NOTE: This would not change ARIN acceptance guidelines.  This would
>> simply better document the existing evaluation process.
>>
>>   -or-
>>
>> A. Codify the acceptable format(s) in a way which is easy for us to
>> machine generate.  (starting with the formats we use today so no
>> change is necessary)
>>
>> B. Change the NRPM to require submission in one of the documented
>> formats.
>>
>> NOTE: This *would* change ARIN acceptance guidelines by limiting the
>> acceptable submission format.  It would not otherwise change the
>> acceptance guidelines.
>>
>> Frankly, I'm in favor of the latter (alphabetic one) though that will
>> come as no surprise to anyone who knows me.  But I'd happily write up
>> and support the former (numeric) proposal because it would vastly
>> improve the current situation.
>>
>> And before you reply, repeat after me "Neither of these proposals
>> would actually change whether or not a given usage would be  
>> acceptable
>> for a given allocation size."
>>
>> -- 
>> Jo Rhett
>> senior geek
>>
>> Silicon Valley Colocation
>> Support Phone: 408-400-0550
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From michael.dillon at bt.com  Thu Sep 18 07:31:23 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 18 Sep 2008 12:31:23 +0100
Subject: [arin-ppml] would you support a proposal to tighten
	usagedocumentation requirements?
In-Reply-To: <20080918014836.GA74464@ussenterprise.ufp.org>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC081E195F@E03MVZ2-UKDY.domain1.systemhost.net>


> There is a generic idea that has been floating around for 
> some time to create a companion to the NRPM.  It has been 
> proposed as a separate document to provide operational 
> details like you describe, or as an "annotated" version of the NRPM.

That kind of work fits well with the idea of a wiki. Since ARIN
currently runs an instance of Wikimedia for the www.getipv6.info
site, perhaps another wiki coukd be set up for general IP address
management practices. Wikimedia includes the concept of protected
pages so once some aspect of the documentation has "crystalised"
it can be protected until agreement is reached on a new version.
These "crystalised" pages can then be made available on another
ARIN website or as PDF downloads. 

An advantage of doing this on a wiki is that staff could seed it
with initial information and then others can add to it and comment
freely. Because of the wiki format, people are unlikely to misunderstand
this as some sort of decree from the staff.

This is something like what the FAA does at
http://www.faa.gov/airports_airtraffic/air_traffic/publications/ except
that
the publications would be written on a public wiki.

--Michael Dillon


From info at arin.net  Thu Sep 18 09:22:37 2008
From: info at arin.net (Member Services)
Date: Thu, 18 Sep 2008 09:22:37 -0400
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal -
	Revised
Message-ID: <48D2561D.2040205@arin.net>

Policy Proposal "2008-2: IPv4 Transfer Policy Proposal" has been 
revised. This proposal is open for discussion on this mailing list and 
will be on the agenda at the upcoming ARIN XXII Public Policy Meeting in 
Los Angeles.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2008_2.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)
## * ##

Policy Proposal 2008-2

IPv4 Transfer Policy Proposal

Author: ARIN Advisory Council

Proposal Version: 1.4

Date: 09/18/2008

Proposal type: modify

Policy term: permanent

Policy statement:

Modify the current NRPM section 8 as follows --

8. Transfers

[8.1. Transfers ? retain as is]

[8.2 ? remove the word ?only?, and retitle to ?Transfers as an Artifact 
of Change in Resource Holder Ownership?]

[Renumber existing 8.3 to 8.2.1 and retitle to ?Documentation 
Requirements for Transfers as an Artifact of Change in Resource Holder 
Ownership?]

[Add the following new section:]

8.3. Simple Transfer of IPv4 Addresses

In light of the pending exhaustion of the IANA IPv4 free pool, ARIN will 
also process IPv4 address transfer requests subject to the following 
conditions. These conditions apply only to Simple IPv4 transfers, not to 
transfers performed according to section 8.2.

8.3.1 Conditions on the transferor (the organization providing addresses 
for transfer):

? The transferor has no outstanding balances with ARIN.

? The transferor has not received any IPv4 allocations or assignments 
from ARIN (through ordinary allocations or assignments, or through this 
Simple Transfer policy) within the preceding 12 months.

? If the transferor elects to retain a portion of a block pursuant to 
8.3.6, rather than transferring an entire block, the transferor must 
sign (or have previously signed) a RSA or LRSA covering the retained 
portion.

8.3.2 Conditions on the transferee (the organization receiving the 
transferred addresses):

? The transferee intends to use the transferred IPv4 addresses within 
the ARIN service area.

? The transferee has no outstanding balances with ARIN.

? The transferee?s need is confirmed by ARIN, according to current ARIN 
policies.

? The transferee signs (or has previously signed) an RSA covering the 
IPv4 addresses transferred.

? The transferee may request and receive a contiguous CIDR block large 
enough to provide a 12 month supply of IPv4 addresses.

? The transferee may only receive one IPv4 address transfer through this 
Simple Transfer process every 6 months.

8.3.3 Conditions on the IPv4 address block to be transferred:

? The IPv4 block must comply with applicable ARIN allocation 
requirements, including minimum allocation size. However, an IPv4 
allocation or assignment of /24 or larger, but smaller than the current 
minimum allocation size, may be transferred as a whole resource (but may 
not be subdivided).

? The IPv4 block must currently be registered for use within the ARIN 
service area.

? There must be no dispute as to the status of the IPv4 block or 
regarding the allocation or assignment of such block to the transferor.

8.3.4 [Section omitted]

8.3.5 Pre-qualification

? An interested transferee must seek pre-qualification from ARIN to 
confirm its eligibility to receive a transfer (including satisfaction of 
need according to current ARIN policies) before making any solicitation 
for transfer. Upon pre-qualification, ARIN will provide the transferee 
with documentation of the pre-qualification, including the size (CIDR 
prefix length) of the largest IPv4 address block the transferee is 
eligible to receive, and the expiration date of the pre-qualification.

? An interested transferor may seek pre-qualification from ARIN to 
confirm its eligibility to offer a transfer before offering IPv4 address 
resources for transfer. Upon pre-qualification, ARIN will provide the 
transferor with documentation of the pre-qualification, including the 
network block and the expiration date of the pre-qualification.

8.3.6 Deaggregation when Permitted by ARIN

ARIN may allow transferors to subdivide network blocks. ARIN will 
attempt to ensure an adequate supply of small blocks while minimizing 
deaggregation.

8.3.7. Safe Harbor

The fact that an IPv4 address holder is making IPv4 addresses available 
for transfer, pursuant to this policy, does not, in and of itself, 
indicate that the address holder lacks the need required for an 
allocation under ARIN policy.

8.3.8. Organizations under Common Ownership or Control

If an IPv4 transferor or transferee is under common ownership or control 
with any other organization that holds one or more IPv4 blocks, the IPv4 
transfer request must report all such organizations under common 
ownership or control. When evaluating compliance with IPv4 Simple 
Transfer conditions, ARIN may consider a transfer request in light of 
requests from other organizations under common ownership or control.

8.3.9. Record-keeping and Publication

ARIN will develop and operate a listing service to assist interested 
transferors and transferees by providing them a centralized location to 
post information about IPv4 blocks available from pre-qualified 
transferors and IPv4 blocks needed by pre-qualified transferees.

Participation in the listing service is voluntary.

After completion of a transfer, ARIN will update the registration and 
WHOIS records pertaining to the IPv4 block. ARIN will also publish a log 
of all transfers, including block, transferor, transferee, and date.


Rationale:

The ARIN Board of Trustees asked the Advisory Council to consider a set 
of questions around the depletion of the free pool of IPv4 addresses, 
the transition to IPv6 for Internet address needs in the future, and 
ARIN's possible role in easing the transition.

Over the course of the year, the Advisory Council has worked to solicit 
input from all parts of the policy-making community, through the ARIN 
XXI public policy meeting, the Public Policy Mailing List (PPML), sector 
meetings, and a poll of PPML subscribers. As a result of the input 
received, this policy has been simplified considerably, removing or 
modifying text and restrictions deemed unnecessary, while preserving 
those aspects that seem to be supported by consensus.

This policy proposal would create a transfer mechanism for IPv4 number 
resources between those who have excess resources and those who have a 
need, thereby allowing ARIN to continue to serve its mission after IANA 
free pool exhaustion. This proposal would also set conditions on such 
transfers intended to preserve as much as possible the existing policy 
related to efficient, needs-based resource issuance, and would leverage 
ARIN's control systems, audit trails, and recognized position as a 
trusted agent to avoid speculation and hoarding and diminish the 
likelihood and extent of an uncontrolled 'black market' where the risk 
and potential for fraud is immeasurably higher.

Many of the transfer conditions are self-explanatory, but some worth 
highlighting are that:

? To discourage speculation, a waiting period (proposed at 12 months) is 
required before a recipient of space can transfer it to another 
organization.

? Transferees must qualify for IPv4 space (just as they do today when 
getting it from ARIN) before they can receive address space by transfer, 
or solicit space on a listing service.

? To discourage unnecessarily rapid growth of routing tables, an 
allocation or assignment may not be arbitrarily deaggregated. To ensure 
an adequate supply of small blocks while minimizing deaggregation, ARIN 
may allow transferors to subdivide network blocks. A suggested starting 
point is to allow transferors to subdivide an IPv4 block into up to four 
smaller blocks on CIDR bit-boundaries, provided each resulting block 
satisfies the minimum allocation size.

? A transferee may receive one transfer every 6 months, and may receive 
at least 12 months worth of space, so they?ll be incented to transfer a 
block appropriately sized for their needs, which will further discourage 
deaggregation and keep smaller blocks available for smaller organizations.

The proposal would also have ARIN develop and operate a listing service 
to facilitate transfers and provide an authoritative central source of 
information on space available and requested for transfer. It would not 
prohibit private party transactions, but would encourage potential 
transferors and transferees be pre-qualified first, so that neither 
party will encounter any surprises when they ask ARIN to process the 
transfer.


Timetable for implementation: immediately upon ratification by the Board 
of Trustees



From michael.dillon at bt.com  Thu Sep 18 09:42:58 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 18 Sep 2008 14:42:58 +0100
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
	Proposal -Revised
In-Reply-To: <48D2561D.2040205@arin.net>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>

> * The IPv4 block must currently be registered for use within 
> the ARIN service area.

What does this mean?

Since when does ARIN restrict the use of IP address blocks to 
specific geographical regions? Does the ARIN restriction apply
only to use as a source address, or also in the destination
address field?

To which organization should one apply if one want to receive
IP address blocks which can be used globally without geographic
restrictions?

--Michael Dillon


From sleibrand at internap.com  Thu Sep 18 09:54:55 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 18 Sep 2008 06:54:55 -0700
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer
 Policy	Proposal -Revised
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <48D25DAF.7030305@internap.com>

michael.dillon at bt.com wrote:
>> * The IPv4 block must currently be registered for use within 
>> the ARIN service area.
> 
> What does this mean?

The intent there is that it simply has to be ARIN space.  We're open to 
suggestions for improved wording.

> Since when does ARIN restrict the use of IP address blocks to 
> specific geographical regions? Does the ARIN restriction apply
> only to use as a source address, or also in the destination
> address field?
> 
> To which organization should one apply if one want to receive
> IP address blocks which can be used globally without geographic
> restrictions?

I don't believe IANA has any intent to distribute address space to ISPs or 
end users that can be used globally without geographic restrictions.  In 
the current system, addresses are allocated from the registry in the 
region in which they are primarily to be used, and we aren't trying to 
upset that apple cart just yet.

-Scott



From kkargel at polartel.com  Thu Sep 18 10:11:39 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 18 Sep 2008 09:11:39 -0500
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer
	Policy	Proposal -Revised
In-Reply-To: <48D25DAF.7030305@internap.com>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>
	<48D25DAF.7030305@internap.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail>

I did not know that there was any way to control geographic use area..  So
far as I know there is no way I can tell my router to deny from Tanzania..
(sorry Tanzania, I don't hate you, I just had to pick somebody)..

Is there some BGP trick I don't know about that prevents me from advertising
an out of area network?

If it cannot be policed then it shouldn't be in the verbage.  Nothing will
erode authority quicker than making rules you cannot enforce.


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> Sent: Thursday, September 18, 2008 8:55 AM
> To: michael.dillon at bt.com
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
> Transfer Policy Proposal -Revised
> 
> michael.dillon at bt.com wrote:
> >> * The IPv4 block must currently be registered for use 
> within the ARIN 
> >> service area.
> > 
> > What does this mean?
> 
> The intent there is that it simply has to be ARIN space.  
> We're open to suggestions for improved wording.
> 
> > Since when does ARIN restrict the use of IP address blocks 
> to specific 
> > geographical regions? Does the ARIN restriction apply only 
> to use as a 
> > source address, or also in the destination address field?
> > 
> > To which organization should one apply if one want to receive IP 
> > address blocks which can be used globally without geographic 
> > restrictions?
> 
> I don't believe IANA has any intent to distribute address 
> space to ISPs or end users that can be used globally without 
> geographic restrictions.  In the current system, addresses 
> are allocated from the registry in the region in which they 
> are primarily to be used, and we aren't trying to upset that 
> apple cart just yet.
> 
> -Scott
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080918/33e507de/attachment.bin>

From sleibrand at internap.com  Thu Sep 18 10:15:06 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 18 Sep 2008 07:15:06 -0700
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4
 Transfer	Policy	Proposal -Revised
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>	<48D25DAF.7030305@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail>
Message-ID: <48D2626A.8060509@internap.com>

It doesn't say it must be used in North America.  It says it must be 
*registered* for use there.  That means it must be registered with ARIN.

This is not (intended to be) a new restriction: we're just trying to avoid 
having people come to us with LACNIC, AFRINIC, RIPE, or APNIC space and 
asking ARIN to transfer it.

As I mentioned before, suggestions for improved wording are welcome.

-Scott

Kevin Kargel wrote:
> I did not know that there was any way to control geographic use area..  So
> far as I know there is no way I can tell my router to deny from Tanzania..
> (sorry Tanzania, I don't hate you, I just had to pick somebody)..
> 
> Is there some BGP trick I don't know about that prevents me from advertising
> an out of area network?
> 
> If it cannot be policed then it shouldn't be in the verbage.  Nothing will
> erode authority quicker than making rules you cannot enforce.
> 
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
>> Sent: Thursday, September 18, 2008 8:55 AM
>> To: michael.dillon at bt.com
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
>> Transfer Policy Proposal -Revised
>>
>> michael.dillon at bt.com wrote:
>>>> * The IPv4 block must currently be registered for use 
>> within the ARIN 
>>>> service area.
>>> What does this mean?
>> The intent there is that it simply has to be ARIN space.  
>> We're open to suggestions for improved wording.
>>
>>> Since when does ARIN restrict the use of IP address blocks 
>> to specific 
>>> geographical regions? Does the ARIN restriction apply only 
>> to use as a 
>>> source address, or also in the destination address field?
>>>
>>> To which organization should one apply if one want to receive IP 
>>> address blocks which can be used globally without geographic 
>>> restrictions?
>> I don't believe IANA has any intent to distribute address 
>> space to ISPs or end users that can be used globally without 
>> geographic restrictions.  In the current system, addresses 
>> are allocated from the registry in the region in which they 
>> are primarily to be used, and we aren't trying to upset that 
>> apple cart just yet.
>>
>> -Scott
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to 
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.


From sleibrand at internap.com  Thu Sep 18 10:21:26 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 18 Sep 2008 07:21:26 -0700
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4
 Transfer	Policy	Proposal -Revised
In-Reply-To: <48D2626A.8060509@internap.com>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>	<48D25DAF.7030305@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail>
	<48D2626A.8060509@internap.com>
Message-ID: <48D263E6.7010102@internap.com>

FWIW, the text at issue here is simplified and less restrictive than was 
in the last version of 2008-2.  That text read:

?	The IPv4 block must currently be registered for use within the ARIN 
service area, either as part of an address block assigned by IANA to ARIN, 
or as part of a legacy address block allocated within the ARIN service area.

In addition, we've *removed* the following restrictions from the most 
recent version:

?	The transferor resides in the ARIN service area.
?	The transferee resides in the ARIN service area.

-Scott

Scott Leibrand wrote:
> It doesn't say it must be used in North America.  It says it must be 
> *registered* for use there.  That means it must be registered with ARIN.
> 
> This is not (intended to be) a new restriction: we're just trying to 
> avoid having people come to us with LACNIC, AFRINIC, RIPE, or APNIC 
> space and asking ARIN to transfer it.
> 
> As I mentioned before, suggestions for improved wording are welcome.
> 
> -Scott
> 
> Kevin Kargel wrote:
>> I did not know that there was any way to control geographic use 
>> area..  So
>> far as I know there is no way I can tell my router to deny from 
>> Tanzania..
>> (sorry Tanzania, I don't hate you, I just had to pick somebody)..
>>
>> Is there some BGP trick I don't know about that prevents me from 
>> advertising
>> an out of area network?
>>
>> If it cannot be policed then it shouldn't be in the verbage.  Nothing 
>> will
>> erode authority quicker than making rules you cannot enforce.
>>
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
>>> On Behalf Of Scott Leibrand
>>> Sent: Thursday, September 18, 2008 8:55 AM
>>> To: michael.dillon at bt.com
>>> Cc: arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy 
>>> Proposal -Revised
>>>
>>> michael.dillon at bt.com wrote:
>>>>> * The IPv4 block must currently be registered for use 
>>> within the ARIN
>>>>> service area.
>>>> What does this mean?
>>> The intent there is that it simply has to be ARIN space.  We're open 
>>> to suggestions for improved wording.
>>>
>>>> Since when does ARIN restrict the use of IP address blocks 
>>> to specific
>>>> geographical regions? Does the ARIN restriction apply only 
>>> to use as a
>>>> source address, or also in the destination address field?
>>>>
>>>> To which organization should one apply if one want to receive IP 
>>>> address blocks which can be used globally without geographic 
>>>> restrictions?
>>> I don't believe IANA has any intent to distribute address space to 
>>> ISPs or end users that can be used globally without geographic 
>>> restrictions.  In the current system, addresses are allocated from 
>>> the registry in the region in which they are primarily to be used, 
>>> and we aren't trying to upset that apple cart just yet.
>>>
>>> -Scott
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the ARIN 
>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.


From kkargel at polartel.com  Thu Sep 18 10:58:46 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 18 Sep 2008 09:58:46 -0500
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4
	Transfer	Policy	Proposal -Revised
In-Reply-To: <48D2626A.8060509@internap.com>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>	<48D25DAF.7030305@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail>
	<48D2626A.8060509@internap.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B0E@mail>

I think this is more of an operational issue than a policy issue.
Wouldn't it be better to work out a referral agreement with the other
registries where you refer requests to the proper registrar and they
refer requests to ARIN?  I don't know how you would do this other than
based on registration address, and there would be nothing preventing the
Tanzania hosting company from registering their network with a Canadian
address..  

Much the same situation exists with maritime ship registrations..  I
don't really see how to avoid or manage the issue.  

To restate my earlier posit..  Let's not make rules we can't enforce.
 

> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com] 
> Sent: Thursday, September 18, 2008 9:15 AM
> To: Kevin Kargel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
> Transfer Policy Proposal -Revised
> 
> It doesn't say it must be used in North America.  It says it must be
> *registered* for use there.  That means it must be registered 
> with ARIN.
> 
> This is not (intended to be) a new restriction: we're just 
> trying to avoid having people come to us with LACNIC, 
> AFRINIC, RIPE, or APNIC space and asking ARIN to transfer it.
> 
> As I mentioned before, suggestions for improved wording are welcome.
> 
> -Scott
> 
> Kevin Kargel wrote:
> > I did not know that there was any way to control geographic 
> use area..  
> > So far as I know there is no way I can tell my router to 
> deny from Tanzania..
> > (sorry Tanzania, I don't hate you, I just had to pick somebody)..
> > 
> > Is there some BGP trick I don't know about that prevents me from 
> > advertising an out of area network?
> > 
> > If it cannot be policed then it shouldn't be in the 
> verbage.  Nothing 
> > will erode authority quicker than making rules you cannot enforce.
> > 
> > 
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net
> >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> >> Sent: Thursday, September 18, 2008 8:55 AM
> >> To: michael.dillon at bt.com
> >> Cc: arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
> Transfer Policy 
> >> Proposal -Revised
> >>
> >> michael.dillon at bt.com wrote:
> >>>> * The IPv4 block must currently be registered for use
> >> within the ARIN
> >>>> service area.
> >>> What does this mean?
> >> The intent there is that it simply has to be ARIN space.  
> >> We're open to suggestions for improved wording.
> >>
> >>> Since when does ARIN restrict the use of IP address blocks
> >> to specific
> >>> geographical regions? Does the ARIN restriction apply only
> >> to use as a
> >>> source address, or also in the destination address field?
> >>>
> >>> To which organization should one apply if one want to receive IP 
> >>> address blocks which can be used globally without geographic 
> >>> restrictions?
> >> I don't believe IANA has any intent to distribute address space to 
> >> ISPs or end users that can be used globally without geographic 
> >> restrictions.  In the current system, addresses are allocated from 
> >> the registry in the region in which they are primarily to be used, 
> >> and we aren't trying to upset that apple cart just yet.
> >>
> >> -Scott
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >>
> >>
> >> 
> ---------------------------------------------------------------------
> >> ---
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> 


From vixie at isc.org  Thu Sep 18 11:02:54 2008
From: vixie at isc.org (Paul Vixie)
Date: Thu, 18 Sep 2008 15:02:54 +0000
Subject: [arin-ppml] "IPv6 and the Business-Case Skeptics" (slashdot)
In-Reply-To: Your message of "Thu, 18 Sep 2008 10:59:04 -0400."
	<20080918145906.60411114097@mx.isc.org> 
References: <42672.1221690782@nsa.vix.com>
	<20080918145906.60411114097@mx.isc.org> 
Message-ID: <32133.1221750174@nsa.vix.com>

>   "satisfied with all of its Internet services"  <--this might be empty.

:-).

>   I guess that also means, "has no plans for expansion"

it's the wrong rubrik.  folks happy with ipv4 will need to run dual stack
in order to reach the people who will come later on and not be able to get
enough ipv4 or won't want to pay for it or are, for whatever reason, not
satisfied with THEIR ipv4-only internet services.

so expansion is a barbell.  you can run out of ipv4, or other people can,
and either way you've got to run dual-stack as soon as economically possible,
and the economics are actually quite favourable (i.e., it's kinda cheap.)


From owen at delong.com  Thu Sep 18 12:36:32 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 18 Sep 2008 09:36:32 -0700
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4
	Transfer	Policy	Proposal -Revised
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B0E@mail>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>	<48D25DAF.7030305@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail>
	<48D2626A.8060509@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0E@mail>
Message-ID: <A06F0E20-A25B-4E4F-AA2D-E1A127049E93@delong.com>

Not so much.  The different registries have different transfer  
policies (if
they have any at all).  I think the best thing is to make sure that  
ARIN policy
applies to space which is administered by ARIN and leave it at that.

Owen

On Sep 18, 2008, at 7:58 AM, Kevin Kargel wrote:

> I think this is more of an operational issue than a policy issue.
> Wouldn't it be better to work out a referral agreement with the other
> registries where you refer requests to the proper registrar and they
> refer requests to ARIN?  I don't know how you would do this other than
> based on registration address, and there would be nothing preventing  
> the
> Tanzania hosting company from registering their network with a  
> Canadian
> address..
>
> Much the same situation exists with maritime ship registrations..  I
> don't really see how to avoid or manage the issue.
>
> To restate my earlier posit..  Let's not make rules we can't enforce.
>
>
>> -----Original Message-----
>> From: Scott Leibrand [mailto:sleibrand at internap.com]
>> Sent: Thursday, September 18, 2008 9:15 AM
>> To: Kevin Kargel
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
>> Transfer Policy Proposal -Revised
>>
>> It doesn't say it must be used in North America.  It says it must be
>> *registered* for use there.  That means it must be registered
>> with ARIN.
>>
>> This is not (intended to be) a new restriction: we're just
>> trying to avoid having people come to us with LACNIC,
>> AFRINIC, RIPE, or APNIC space and asking ARIN to transfer it.
>>
>> As I mentioned before, suggestions for improved wording are welcome.
>>
>> -Scott
>>
>> Kevin Kargel wrote:
>>> I did not know that there was any way to control geographic
>> use area..
>>> So far as I know there is no way I can tell my router to
>> deny from Tanzania..
>>> (sorry Tanzania, I don't hate you, I just had to pick somebody)..
>>>
>>> Is there some BGP trick I don't know about that prevents me from
>>> advertising an out of area network?
>>>
>>> If it cannot be policed then it shouldn't be in the
>> verbage.  Nothing
>>> will erode authority quicker than making rules you cannot enforce.
>>>
>>>
>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net
>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
>>>> Sent: Thursday, September 18, 2008 8:55 AM
>>>> To: michael.dillon at bt.com
>>>> Cc: arin-ppml at arin.net
>>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
>> Transfer Policy
>>>> Proposal -Revised
>>>>
>>>> michael.dillon at bt.com wrote:
>>>>>> * The IPv4 block must currently be registered for use
>>>> within the ARIN
>>>>>> service area.
>>>>> What does this mean?
>>>> The intent there is that it simply has to be ARIN space.
>>>> We're open to suggestions for improved wording.
>>>>
>>>>> Since when does ARIN restrict the use of IP address blocks
>>>> to specific
>>>>> geographical regions? Does the ARIN restriction apply only
>>>> to use as a
>>>>> source address, or also in the destination address field?
>>>>>
>>>>> To which organization should one apply if one want to receive IP
>>>>> address blocks which can be used globally without geographic
>>>>> restrictions?
>>>> I don't believe IANA has any intent to distribute address space to
>>>> ISPs or end users that can be used globally without geographic
>>>> restrictions.  In the current system, addresses are allocated from
>>>> the registry in the region in which they are primarily to be used,
>>>> and we aren't trying to upset that apple cart just yet.
>>>>
>>>> -Scott
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed
>> to the ARIN
>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> ---
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed
>> to the ARIN
>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080918/fd825e20/attachment.p7s>

From cgrundemann at gmail.com  Thu Sep 18 12:54:28 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 18 Sep 2008 10:54:28 -0600
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
	Proposal -Revised
In-Reply-To: <48D25DAF.7030305@internap.com>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>
	<48D25DAF.7030305@internap.com>
Message-ID: <443de7ad0809180954t58dde884u436d464a0e55042e@mail.gmail.com>

On Thu, Sep 18, 2008 at 7:54 AM, Scott Leibrand <sleibrand at internap.com> wrote:
> michael.dillon at bt.com wrote:
>>> * The IPv4 block must currently be registered for use within
>>> the ARIN service area.
>>
>> What does this mean?
>
> The intent there is that it simply has to be ARIN space.  We're open to
> suggestions for improved wording.
>
A quick stab at it:
// The IPv4 block must currently be registered with ARIN or be
recognized legacy space within the ARIN service area. //
IMHO that wording may avoid misconceptions / perceptions about (new)
geographic limitations.



-- 
Chris Grundemann
www.linkedin.com/in/cgrundemann


From cliffb at cjbsys.bdb.com  Thu Sep 18 13:09:17 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Thu, 18 Sep 2008 13:09:17 -0400 (EDT)
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
In-Reply-To: <443de7ad0809180954t58dde884u436d464a0e55042e@mail.gmail.com>
	from "Chris Grundemann" at Sep 18, 2008 10:54:28 AM
Message-ID: <200809181709.m8IH9HMf003900@cjbsys.bdb.com>

I like what Chris says below regarding this item.

Cliff

> 
> On Thu, Sep 18, 2008 at 7:54 AM, Scott Leibrand <sleibrand at internap.com> wrote:
> > michael.dillon at bt.com wrote:
> >>> * The IPv4 block must currently be registered for use within
> >>> the ARIN service area.
> >>
> >> What does this mean?
> >
> > The intent there is that it simply has to be ARIN space.  We're open to
> > suggestions for improved wording.
> >
> A quick stab at it:
> // The IPv4 block must currently be registered with ARIN or be
> recognized legacy space within the ARIN service area. //
> IMHO that wording may avoid misconceptions / perceptions about (new)
> geographic limitations.
> 
> 
> 
> -- 
> Chris Grundemann
> www.linkedin.com/in/cgrundemann
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20740
cliffb at cjbsys.bdb.com http://www.bdb.com
Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/


From sleibrand at internap.com  Thu Sep 18 13:10:20 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 18 Sep 2008 10:10:20 -0700
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
In-Reply-To: <200809181709.m8IH9HMf003900@cjbsys.bdb.com>
References: <200809181709.m8IH9HMf003900@cjbsys.bdb.com>
Message-ID: <48D28B7C.1060409@internap.com>

Ok, thanks.  I think we'll go ahead and put the legacy language back in to 
avoid any confusion or misconceptions.

-Scott

Cliff Bedore wrote:
> I like what Chris says below regarding this item.
> 
> Cliff
> 
>> On Thu, Sep 18, 2008 at 7:54 AM, Scott Leibrand <sleibrand at internap.com> wrote:
>>> michael.dillon at bt.com wrote:
>>>>> * The IPv4 block must currently be registered for use within
>>>>> the ARIN service area.
>>>> What does this mean?
>>> The intent there is that it simply has to be ARIN space.  We're open to
>>> suggestions for improved wording.
>>>
>> A quick stab at it:
>> // The IPv4 block must currently be registered with ARIN or be
>> recognized legacy space within the ARIN service area. //
>> IMHO that wording may avoid misconceptions / perceptions about (new)
>> geographic limitations.
>>
>>
>>
>> -- 
>> Chris Grundemann
>> www.linkedin.com/in/cgrundemann
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
> 
> 


From stephen at sprunk.org  Thu Sep 18 13:21:53 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Thu, 18 Sep 2008 12:21:53 -0500
Subject: [arin-ppml] Taking back UNUSED addresses.
In-Reply-To: <5C97F2E1-0263-4306-B35A-3FD3E026AB9F@wisc.edu>
References: <20080912184409.GA84710@ussenterprise.ufp.org>
	<3c3e3fca0809121306i2e91b3bdwb43b8aea24e60bd2@mail.gmail.com>
	<20080912202000.GA94971@ussenterprise.ufp.org>
	<3c3e3fca0809121442g1644ccccwdc25662c554dfefc@mail.gmail.com>
	<7C73F05C-8576-4A48-8ECB-DCEA6DFA78B1@apnic.net>
	<20080915010604.GA60456@ussenterprise.ufp.org>
	<48D014C3.6020109@sprunk.org>
	<5C97F2E1-0263-4306-B35A-3FD3E026AB9F@wisc.edu>
Message-ID: <48D28E31.4070405@sprunk.org>

Dale W. Carder wrote:
> On Sep 16, 2008, at 3:19 PM, Stephen Sprunk wrote:
>>  Also, 52% of the network records and 48% of org records haven't been 
>> updated since 1997
>
> For one datapoint, we have been at the same street address as when we 
> were on CSNET 20+ years ago.  My guess would be that not a whole lot 
> of legacy .edu's have moved that couldn't be found easily.

OTOH, those prefixes should be showing up in the DFZ, so I'm not 
particularly concerned about them.

However, IT departments _do_ change address even if the overall 
university doesn't; area codes change, POCs change, NSes, change, etc.  
For instance, out of the 11 OrgID records I see in a query for 
"University of Wisconsin", 10 have been updated since 2001; 3 of 5 ASN 
records have been updated; and 14 of 18 network records have been 
updated.  And, with UW having at least some resources under RSA, I'm not 
particularly worried about the others even if they _aren't_ in use, 
though it'd be nice if you'd return them if not.

>> Unfortunately, those statistics do not account for the varying size 
>> of legacy blocks; they just count records, which could be anywhere 
>> from /8 to /24.
>
> We've returned most of our swamp /24's that I know of, but I doubt 
> having substantially more of the swamp show up in the DFZ would be in 
> everyone's best interest.

Current policy would not allow ARIN to hand them back out as /24s.  If 
some could be aggregated into /20s, that's a good thing.  And, most 
importantly, if they're not registered to anyone, then spammers (or 
anyone else who can't get legitimate space -- which will be a lot of 
folks in a few years) can't hijack them.

S


From kkargel at polartel.com  Thu Sep 18 13:39:51 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 18 Sep 2008 12:39:51 -0500
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4
	Transfer	Policy	Proposal -Revised
In-Reply-To: <A06F0E20-A25B-4E4F-AA2D-E1A127049E93@delong.com>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>	<48D25DAF.7030305@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail>
	<48D2626A.8060509@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0E@mail>
	<A06F0E20-A25B-4E4F-AA2D-E1A127049E93@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B11@mail>

 By "space" do you mean IP space or geo-space?  

In either case I still think the best solution is just to forward requests
from outside of "ARIN space" to the appropriate registry..

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Thursday, September 18, 2008 11:37 AM
> To: Kevin Kargel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
> Transfer Policy Proposal -Revised
> 
> Not so much.  The different registries have different 
> transfer policies (if they have any at all).  I think the 
> best thing is to make sure that ARIN policy applies to space 
> which is administered by ARIN and leave it at that.
> 
> Owen
> 
> On Sep 18, 2008, at 7:58 AM, Kevin Kargel wrote:
> 
> > I think this is more of an operational issue than a policy issue.
> > Wouldn't it be better to work out a referral agreement with 
> the other 
> > registries where you refer requests to the proper registrar 
> and they 
> > refer requests to ARIN?  I don't know how you would do this 
> other than 
> > based on registration address, and there would be nothing 
> preventing 
> > the Tanzania hosting company from registering their network with a 
> > Canadian address..
> >
> > Much the same situation exists with maritime ship 
> registrations..  I 
> > don't really see how to avoid or manage the issue.
> >
> > To restate my earlier posit..  Let's not make rules we 
> can't enforce.
> >
> >
> >> -----Original Message-----
> >> From: Scott Leibrand [mailto:sleibrand at internap.com]
> >> Sent: Thursday, September 18, 2008 9:15 AM
> >> To: Kevin Kargel
> >> Cc: arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
> Transfer Policy 
> >> Proposal -Revised
> >>
> >> It doesn't say it must be used in North America.  It says 
> it must be
> >> *registered* for use there.  That means it must be registered with 
> >> ARIN.
> >>
> >> This is not (intended to be) a new restriction: we're just 
> trying to 
> >> avoid having people come to us with LACNIC, AFRINIC, RIPE, 
> or APNIC 
> >> space and asking ARIN to transfer it.
> >>
> >> As I mentioned before, suggestions for improved wording 
> are welcome.
> >>
> >> -Scott
> >>
> >> Kevin Kargel wrote:
> >>> I did not know that there was any way to control geographic
> >> use area..
> >>> So far as I know there is no way I can tell my router to
> >> deny from Tanzania..
> >>> (sorry Tanzania, I don't hate you, I just had to pick somebody)..
> >>>
> >>> Is there some BGP trick I don't know about that prevents me from 
> >>> advertising an out of area network?
> >>>
> >>> If it cannot be policed then it shouldn't be in the
> >> verbage.  Nothing
> >>> will erode authority quicker than making rules you cannot enforce.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: arin-ppml-bounces at arin.net
> >>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> >>>> Sent: Thursday, September 18, 2008 8:55 AM
> >>>> To: michael.dillon at bt.com
> >>>> Cc: arin-ppml at arin.net
> >>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> >> Transfer Policy
> >>>> Proposal -Revised
> >>>>
> >>>> michael.dillon at bt.com wrote:
> >>>>>> * The IPv4 block must currently be registered for use
> >>>> within the ARIN
> >>>>>> service area.
> >>>>> What does this mean?
> >>>> The intent there is that it simply has to be ARIN space.
> >>>> We're open to suggestions for improved wording.
> >>>>
> >>>>> Since when does ARIN restrict the use of IP address blocks
> >>>> to specific
> >>>>> geographical regions? Does the ARIN restriction apply only
> >>>> to use as a
> >>>>> source address, or also in the destination address field?
> >>>>>
> >>>>> To which organization should one apply if one want to 
> receive IP 
> >>>>> address blocks which can be used globally without geographic 
> >>>>> restrictions?
> >>>> I don't believe IANA has any intent to distribute 
> address space to 
> >>>> ISPs or end users that can be used globally without geographic 
> >>>> restrictions.  In the current system, addresses are 
> allocated from 
> >>>> the registry in the region in which they are primarily 
> to be used, 
> >>>> and we aren't trying to upset that apple cart just yet.
> >>>>
> >>>> -Scott
> >>>>
> >>>> _______________________________________________
> >>>> PPML
> >>>> You are receiving this message because you are subscribed
> >> to the ARIN
> >>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>> Unsubscribe or manage your mailing list subscription at:
> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>> Please contact info at arin.net if you experience any issues.
> >>>>
> >>>>
> >>>>
> >> 
> ---------------------------------------------------------------------
> >>>> ---
> >>>>
> >>>> _______________________________________________
> >>>> PPML
> >>>> You are receiving this message because you are subscribed
> >> to the ARIN
> >>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>> Unsubscribe or manage your mailing list subscription at:
> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>> Please contact info at arin.net if you experience any issues.
> >>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080918/f6a3cb50/attachment.bin>

From kkargel at polartel.com  Thu Sep 18 13:49:34 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 18 Sep 2008 12:49:34 -0500
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer
	PolicyProposal -Revised
In-Reply-To: <443de7ad0809180954t58dde884u436d464a0e55042e@mail.gmail.com>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net><48D25DAF.7030305@internap.com>
	<443de7ad0809180954t58dde884u436d464a0e55042e@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B13@mail>

What actions are we going to take regarding ARIN registered IP space that is
being used on a host or network geographically located outside of "ARIN
service area"?  

Are you saying that if "International Widgit Import Company" out of
Winnipeg, Manitoba,Canada gets an IP block that they cannot use a subnet of
that network at their office in Hong Kong?  If so what are we going to do to
police that?

The same questions apply to Mitsuyama Ball Bearing Co. who registers a
network using their Grafton, Iowa, USA address and then implements them at
their Tokyo, Japan plant..  

If the answer to what we are going to do is "Nothing" then the verbage
itself is superfluous..   



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann
> Sent: Thursday, September 18, 2008 11:54 AM
> To: Scott Leibrand
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
> Transfer PolicyProposal -Revised
> 
> On Thu, Sep 18, 2008 at 7:54 AM, Scott Leibrand 
> <sleibrand at internap.com> wrote:
> > michael.dillon at bt.com wrote:
> >>> * The IPv4 block must currently be registered for use within the 
> >>> ARIN service area.
> >>
> >> What does this mean?
> >
> > The intent there is that it simply has to be ARIN space.  
> We're open 
> > to suggestions for improved wording.
> >
> A quick stab at it:
> // The IPv4 block must currently be registered with ARIN or 
> be recognized legacy space within the ARIN service area. // 
> IMHO that wording may avoid misconceptions / perceptions 
> about (new) geographic limitations.
> 
> 
> 
> --
> Chris Grundemann
> www.linkedin.com/in/cgrundemann
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080918/6db33511/attachment.bin>

From kkargel at polartel.com  Thu Sep 18 14:01:22 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 18 Sep 2008 13:01:22 -0500
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4
	Transfer	Policy	Proposal -Revised
In-Reply-To: <218797CE-B4D9-45F9-9130-583DF487E0B6@delong.com>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>	<48D25DAF.7030305@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail>
	<48D2626A.8060509@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0E@mail>
	<A06F0E20-A25B-4E4F-AA2D-E1A127049E93@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B11@mail>
	<218797CE-B4D9-45F9-9130-583DF487E0B6@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B14@mail>

Ah, so if Mitsuyama Corp in Japan wants an ARIN IP block they just need to
get a mailing address in the US for the transfer process, give the US
corporation a bunch of money, get posession of the IP's, and abandon the
CONUS mailing address..  Then they are operating within the policy and
everything is ok..  

It doesn't look like we are solving anything..  Just making another red tape
loop..  

  

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Thursday, September 18, 2008 12:50 PM
> To: Kevin Kargel
> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
> Transfer Policy Proposal -Revised
> 
> 
> On Sep 18, 2008, at 10:39 AM, Kevin Kargel wrote:
> 
> > By "space" do you mean IP space or geo-space?
> >
> IP Space.
> 
> > In either case I still think the best solution is just to forward 
> > requests from outside of "ARIN space" to the appropriate registry..
> >
> The problem comes when you have an ORG that is within the 
> ARIN service Region trying to transfer ARIN registered space 
> to an ORG that is outside of the ARIN service region or vice versa.
> 
> The best thing is, IMHO, to clarify that ARIN policy only 
> covers transfers of IP Resources administered by ARIN between 
> two parties within the ARIN service region.
> 
> Owen
> 
> >> -----Original Message-----
> >> From: Owen DeLong [mailto:owen at delong.com]
> >> Sent: Thursday, September 18, 2008 11:37 AM
> >> To: Kevin Kargel
> >> Cc: arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
> Transfer Policy 
> >> Proposal -Revised
> >>
> >> Not so much.  The different registries have different transfer 
> >> policies (if they have any at all).  I think the best thing is to 
> >> make sure that ARIN policy applies to space which is 
> administered by 
> >> ARIN and leave it at that.
> >>
> >> Owen
> >>
> >> On Sep 18, 2008, at 7:58 AM, Kevin Kargel wrote:
> >>
> >>> I think this is more of an operational issue than a policy issue.
> >>> Wouldn't it be better to work out a referral agreement with
> >> the other
> >>> registries where you refer requests to the proper registrar
> >> and they
> >>> refer requests to ARIN?  I don't know how you would do this
> >> other than
> >>> based on registration address, and there would be nothing
> >> preventing
> >>> the Tanzania hosting company from registering their 
> network with a 
> >>> Canadian address..
> >>>
> >>> Much the same situation exists with maritime ship
> >> registrations..  I
> >>> don't really see how to avoid or manage the issue.
> >>>
> >>> To restate my earlier posit..  Let's not make rules we
> >> can't enforce.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Scott Leibrand [mailto:sleibrand at internap.com]
> >>>> Sent: Thursday, September 18, 2008 9:15 AM
> >>>> To: Kevin Kargel
> >>>> Cc: arin-ppml at arin.net
> >>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> >> Transfer Policy
> >>>> Proposal -Revised
> >>>>
> >>>> It doesn't say it must be used in North America.  It says
> >> it must be
> >>>> *registered* for use there.  That means it must be 
> registered with 
> >>>> ARIN.
> >>>>
> >>>> This is not (intended to be) a new restriction: we're just
> >> trying to
> >>>> avoid having people come to us with LACNIC, AFRINIC, RIPE,
> >> or APNIC
> >>>> space and asking ARIN to transfer it.
> >>>>
> >>>> As I mentioned before, suggestions for improved wording
> >> are welcome.
> >>>>
> >>>> -Scott
> >>>>
> >>>> Kevin Kargel wrote:
> >>>>> I did not know that there was any way to control geographic
> >>>> use area..
> >>>>> So far as I know there is no way I can tell my router to
> >>>> deny from Tanzania..
> >>>>> (sorry Tanzania, I don't hate you, I just had to pick 
> somebody)..
> >>>>>
> >>>>> Is there some BGP trick I don't know about that 
> prevents me from 
> >>>>> advertising an out of area network?
> >>>>>
> >>>>> If it cannot be policed then it shouldn't be in the
> >>>> verbage.  Nothing
> >>>>> will erode authority quicker than making rules you 
> cannot enforce.
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: arin-ppml-bounces at arin.net
> >>>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> >>>>>> Sent: Thursday, September 18, 2008 8:55 AM
> >>>>>> To: michael.dillon at bt.com
> >>>>>> Cc: arin-ppml at arin.net
> >>>>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> >>>> Transfer Policy
> >>>>>> Proposal -Revised
> >>>>>>
> >>>>>> michael.dillon at bt.com wrote:
> >>>>>>>> * The IPv4 block must currently be registered for use
> >>>>>> within the ARIN
> >>>>>>>> service area.
> >>>>>>> What does this mean?
> >>>>>> The intent there is that it simply has to be ARIN space.
> >>>>>> We're open to suggestions for improved wording.
> >>>>>>
> >>>>>>> Since when does ARIN restrict the use of IP address blocks
> >>>>>> to specific
> >>>>>>> geographical regions? Does the ARIN restriction apply only
> >>>>>> to use as a
> >>>>>>> source address, or also in the destination address field?
> >>>>>>>
> >>>>>>> To which organization should one apply if one want to
> >> receive IP
> >>>>>>> address blocks which can be used globally without geographic 
> >>>>>>> restrictions?
> >>>>>> I don't believe IANA has any intent to distribute
> >> address space to
> >>>>>> ISPs or end users that can be used globally without geographic 
> >>>>>> restrictions.  In the current system, addresses are
> >> allocated from
> >>>>>> the registry in the region in which they are primarily
> >> to be used,
> >>>>>> and we aren't trying to upset that apple cart just yet.
> >>>>>>
> >>>>>> -Scott
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> PPML
> >>>>>> You are receiving this message because you are subscribed
> >>>> to the ARIN
> >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>>>> Unsubscribe or manage your mailing list subscription at:
> >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>>>> Please contact info at arin.net if you experience any issues.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >> 
> ---------------------------------------------------------------------
> >>>>>> ---
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> PPML
> >>>>>> You are receiving this message because you are subscribed
> >>>> to the ARIN
> >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>>>> Unsubscribe or manage your mailing list subscription at:
> >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>>>> Please contact info at arin.net if you experience any issues.
> >>>>
> >>> _______________________________________________
> >>> PPML
> >>> You are receiving this message because you are subscribed
> >> to the ARIN
> >>> Public Policy Mailing List (ARIN-PPML at arin.net).
> >>> Unsubscribe or manage your mailing list subscription at:
> >>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>> Please contact info at arin.net if you experience any issues.
> >>
> >>
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080918/19b0efa5/attachment.bin>

From Lee.Howard at stanleyassociates.com  Thu Sep 18 14:19:09 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Thu, 18 Sep 2008 14:19:09 -0400
Subject: [arin-ppml] Policy Proposal 2008-2:
	IPv4Transfer	Policy	Proposal -Revised
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B14@mail>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B5A1EDF@CL-S-EX-1.stanleyassociates.com>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Thursday, September 18, 2008 2:01 PM
> To: PPML PPML
> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4Transfer 
> Policy Proposal -Revised
> 
> Ah, so if Mitsuyama Corp in Japan wants an ARIN IP block they 
> just need to get a mailing address in the US for the transfer 
> process, give the US corporation a bunch of money, get 
> posession of the IP's, and abandon the CONUS mailing 
> address..  Then they are operating within the policy and 
> everything is ok..  

Yes.  This is the current situation.  It doesn't come up,
because the integers in North American taste just the same
as the integers in the Asia Pacific region.

However, ARIN should not facilitate transfers from
extra-regional organizations, because ARIN doesn't have
authority over those numbers.

> It doesn't look like we are solving anything..  Just making 
> another red tape loop..  

The fact that a barrier is imperfect does not mean it should
not be built.  

First decide if a barrier is desirable.  The build the
appropriate barrier.  In this case, ARIN serves the ARIN 
region, so except where desired, policy should not provide
for allocations outside the region.

Not a Board product.  IMHO, YMMV, IANAL, PEBCAK, TANSTAAFL, 
floss regularly, tip your waitstaff, wear sunscreen, void
where prohibited.

Lee



> > -----Original Message-----
> > From: Owen DeLong [mailto:owen at delong.com]
> > Sent: Thursday, September 18, 2008 12:50 PM
> > To: Kevin Kargel
> > Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 
> Transfer Policy 
> > Proposal -Revised
> > 
> > 
> > On Sep 18, 2008, at 10:39 AM, Kevin Kargel wrote:
> > 
> > > By "space" do you mean IP space or geo-space?
> > >
> > IP Space.
> > 
> > > In either case I still think the best solution is just to forward 
> > > requests from outside of "ARIN space" to the appropriate 
> registry..
> > >
> > The problem comes when you have an ORG that is within the 
> ARIN service 
> > Region trying to transfer ARIN registered space to an ORG that is 
> > outside of the ARIN service region or vice versa.
> > 
> > The best thing is, IMHO, to clarify that ARIN policy only covers 
> > transfers of IP Resources administered by ARIN between two parties 
> > within the ARIN service region.
> > 
> > Owen
> > 
> > >> -----Original Message-----
> > >> From: Owen DeLong [mailto:owen at delong.com]
> > >> Sent: Thursday, September 18, 2008 11:37 AM
> > >> To: Kevin Kargel
> > >> Cc: arin-ppml at arin.net
> > >> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > Transfer Policy
> > >> Proposal -Revised
> > >>
> > >> Not so much.  The different registries have different transfer 
> > >> policies (if they have any at all).  I think the best 
> thing is to 
> > >> make sure that ARIN policy applies to space which is
> > administered by
> > >> ARIN and leave it at that.
> > >>
> > >> Owen
> > >>
> > >> On Sep 18, 2008, at 7:58 AM, Kevin Kargel wrote:
> > >>
> > >>> I think this is more of an operational issue than a 
> policy issue.
> > >>> Wouldn't it be better to work out a referral agreement with
> > >> the other
> > >>> registries where you refer requests to the proper registrar
> > >> and they
> > >>> refer requests to ARIN?  I don't know how you would do this
> > >> other than
> > >>> based on registration address, and there would be nothing
> > >> preventing
> > >>> the Tanzania hosting company from registering their
> > network with a
> > >>> Canadian address..
> > >>>
> > >>> Much the same situation exists with maritime ship
> > >> registrations..  I
> > >>> don't really see how to avoid or manage the issue.
> > >>>
> > >>> To restate my earlier posit..  Let's not make rules we
> > >> can't enforce.
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Scott Leibrand [mailto:sleibrand at internap.com]
> > >>>> Sent: Thursday, September 18, 2008 9:15 AM
> > >>>> To: Kevin Kargel
> > >>>> Cc: arin-ppml at arin.net
> > >>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > >> Transfer Policy
> > >>>> Proposal -Revised
> > >>>>
> > >>>> It doesn't say it must be used in North America.  It says
> > >> it must be
> > >>>> *registered* for use there.  That means it must be
> > registered with
> > >>>> ARIN.
> > >>>>
> > >>>> This is not (intended to be) a new restriction: we're just
> > >> trying to
> > >>>> avoid having people come to us with LACNIC, AFRINIC, RIPE,
> > >> or APNIC
> > >>>> space and asking ARIN to transfer it.
> > >>>>
> > >>>> As I mentioned before, suggestions for improved wording
> > >> are welcome.
> > >>>>
> > >>>> -Scott
> > >>>>
> > >>>> Kevin Kargel wrote:
> > >>>>> I did not know that there was any way to control geographic
> > >>>> use area..
> > >>>>> So far as I know there is no way I can tell my router to
> > >>>> deny from Tanzania..
> > >>>>> (sorry Tanzania, I don't hate you, I just had to pick
> > somebody)..
> > >>>>>
> > >>>>> Is there some BGP trick I don't know about that
> > prevents me from
> > >>>>> advertising an out of area network?
> > >>>>>
> > >>>>> If it cannot be policed then it shouldn't be in the
> > >>>> verbage.  Nothing
> > >>>>> will erode authority quicker than making rules you
> > cannot enforce.
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: arin-ppml-bounces at arin.net 
> > >>>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of 
> Scott Leibrand
> > >>>>>> Sent: Thursday, September 18, 2008 8:55 AM
> > >>>>>> To: michael.dillon at bt.com
> > >>>>>> Cc: arin-ppml at arin.net
> > >>>>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > >>>> Transfer Policy
> > >>>>>> Proposal -Revised
> > >>>>>>
> > >>>>>> michael.dillon at bt.com wrote:
> > >>>>>>>> * The IPv4 block must currently be registered for use
> > >>>>>> within the ARIN
> > >>>>>>>> service area.
> > >>>>>>> What does this mean?
> > >>>>>> The intent there is that it simply has to be ARIN space.
> > >>>>>> We're open to suggestions for improved wording.
> > >>>>>>
> > >>>>>>> Since when does ARIN restrict the use of IP address blocks
> > >>>>>> to specific
> > >>>>>>> geographical regions? Does the ARIN restriction apply only
> > >>>>>> to use as a
> > >>>>>>> source address, or also in the destination address field?
> > >>>>>>>
> > >>>>>>> To which organization should one apply if one want to
> > >> receive IP
> > >>>>>>> address blocks which can be used globally without 
> geographic 
> > >>>>>>> restrictions?
> > >>>>>> I don't believe IANA has any intent to distribute
> > >> address space to
> > >>>>>> ISPs or end users that can be used globally without 
> geographic 
> > >>>>>> restrictions.  In the current system, addresses are
> > >> allocated from
> > >>>>>> the registry in the region in which they are primarily
> > >> to be used,
> > >>>>>> and we aren't trying to upset that apple cart just yet.
> > >>>>>>
> > >>>>>> -Scott
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> PPML
> > >>>>>> You are receiving this message because you are subscribed
> > >>>> to the ARIN
> > >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> > >>>>>> Unsubscribe or manage your mailing list subscription at:
> > >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > >>>>>> Please contact info at arin.net if you experience any issues.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >> 
> > 
> ---------------------------------------------------------------------
> > >>>>>> ---
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> PPML
> > >>>>>> You are receiving this message because you are subscribed
> > >>>> to the ARIN
> > >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> > >>>>>> Unsubscribe or manage your mailing list subscription at:
> > >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > >>>>>> Please contact info at arin.net if you experience any issues.
> > >>>>
> > >>> _______________________________________________
> > >>> PPML
> > >>> You are receiving this message because you are subscribed
> > >> to the ARIN
> > >>> Public Policy Mailing List (ARIN-PPML at arin.net).
> > >>> Unsubscribe or manage your mailing list subscription at:
> > >>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > >>> Please contact info at arin.net if you experience any issues.
> > >>
> > >>
> > 
> > 
> 


From owen at delong.com  Thu Sep 18 14:25:50 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 18 Sep 2008 11:25:50 -0700
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer
	PolicyProposal -Revised
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B13@mail>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net><48D25DAF.7030305@internap.com>
	<443de7ad0809180954t58dde884u436d464a0e55042e@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B13@mail>
Message-ID: <306D71D7-58BE-4973-9832-F7C13BB1430C@delong.com>

You are ignoring the context of the verbiage.

This verbiage strictly applies to what IP resources will be processed
in transfer transactions by ARIN if 2008-2 is adopted.

As such, it makes sense to specify that 2008-2 only applies
to resources which are administered by ARIN and where the
transferee would be eligible to receive their resources from
ARIN as a result of residing or operating a network within the
ARIN service region.

That is, I believe, the intent of the verbiage that sparked this
controversy.

Owen

On Sep 18, 2008, at 10:49 AM, Kevin Kargel wrote:

> What actions are we going to take regarding ARIN registered IP space  
> that is
> being used on a host or network geographically located outside of  
> "ARIN
> service area"?
>
> Are you saying that if "International Widgit Import Company" out of
> Winnipeg, Manitoba,Canada gets an IP block that they cannot use a  
> subnet of
> that network at their office in Hong Kong?  If so what are we going  
> to do to
> police that?
>
> The same questions apply to Mitsuyama Ball Bearing Co. who registers a
> network using their Grafton, Iowa, USA address and then implements  
> them at
> their Tokyo, Japan plant..
>
> If the answer to what we are going to do is "Nothing" then the verbage
> itself is superfluous..
>
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann
>> Sent: Thursday, September 18, 2008 11:54 AM
>> To: Scott Leibrand
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
>> Transfer PolicyProposal -Revised
>>
>> On Thu, Sep 18, 2008 at 7:54 AM, Scott Leibrand
>> <sleibrand at internap.com> wrote:
>>> michael.dillon at bt.com wrote:
>>>>> * The IPv4 block must currently be registered for use within the
>>>>> ARIN service area.
>>>>
>>>> What does this mean?
>>>
>>> The intent there is that it simply has to be ARIN space.
>> We're open
>>> to suggestions for improved wording.
>>>
>> A quick stab at it:
>> // The IPv4 block must currently be registered with ARIN or
>> be recognized legacy space within the ARIN service area. //
>> IMHO that wording may avoid misconceptions / perceptions
>> about (new) geographic limitations.
>>
>>
>>
>> --
>> Chris Grundemann
>> www.linkedin.com/in/cgrundemann
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From kkargel at polartel.com  Thu Sep 18 14:26:58 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 18 Sep 2008 13:26:58 -0500
Subject: [arin-ppml] Policy Proposal 2008-2:
	IPv4Transfer	Policy	Proposal -Revised
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B5A1EDF@CL-S-EX-1.stanleyassociates.com>
References: <70DE64CEFD6E9A4EB7FAF3A063141066A10B14@mail>
	<369EB04A0951824ABE7D8BAC67AF9BB40B5A1EDF@CL-S-EX-1.stanleyassociates.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B15@mail>

But....  If we are not going to follow through, if we are not going to
police the rule..  Then what point is there to the rule?  

The answer is just to state that "physical addresses for all registrant
parties for all registrations, requests and/or transfers must be in the
'ARIN Service Area' " then define the ARIN service area..  Then it is
simple..  No policing, no impotent rules.



> -----Original Message-----
> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] 
> Sent: Thursday, September 18, 2008 1:19 PM
> To: Kevin Kargel; PPML PPML
> Subject: RE: [arin-ppml] Policy Proposal 2008-2: IPv4Transfer 
> Policy Proposal -Revised
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> > Sent: Thursday, September 18, 2008 2:01 PM
> > To: PPML PPML
> > Subject: Re: [arin-ppml] Policy Proposal 2008-2: 
> IPv4Transfer Policy 
> > Proposal -Revised
> > 
> > Ah, so if Mitsuyama Corp in Japan wants an ARIN IP block they just 
> > need to get a mailing address in the US for the transfer 
> process, give 
> > the US corporation a bunch of money, get posession of the IP's, and 
> > abandon the CONUS mailing address..  Then they are operating within 
> > the policy and everything is ok..
> 
> Yes.  This is the current situation.  It doesn't come up, 
> because the integers in North American taste just the same as 
> the integers in the Asia Pacific region.
> 
> However, ARIN should not facilitate transfers from 
> extra-regional organizations, because ARIN doesn't have 
> authority over those numbers.
> 
> > It doesn't look like we are solving anything..  Just making another 
> > red tape loop..
> 
> The fact that a barrier is imperfect does not mean it should 
> not be built.  
> 
> First decide if a barrier is desirable.  The build the 
> appropriate barrier.  In this case, ARIN serves the ARIN 
> region, so except where desired, policy should not provide 
> for allocations outside the region.
> 
> Not a Board product.  IMHO, YMMV, IANAL, PEBCAK, TANSTAAFL, 
> floss regularly, tip your waitstaff, wear sunscreen, void 
> where prohibited.
> 
> Lee
> 
> 
> 
> > > -----Original Message-----
> > > From: Owen DeLong [mailto:owen at delong.com]
> > > Sent: Thursday, September 18, 2008 12:50 PM
> > > To: Kevin Kargel
> > > Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > Transfer Policy
> > > Proposal -Revised
> > > 
> > > 
> > > On Sep 18, 2008, at 10:39 AM, Kevin Kargel wrote:
> > > 
> > > > By "space" do you mean IP space or geo-space?
> > > >
> > > IP Space.
> > > 
> > > > In either case I still think the best solution is just 
> to forward 
> > > > requests from outside of "ARIN space" to the appropriate
> > registry..
> > > >
> > > The problem comes when you have an ORG that is within the
> > ARIN service
> > > Region trying to transfer ARIN registered space to an ORG that is 
> > > outside of the ARIN service region or vice versa.
> > > 
> > > The best thing is, IMHO, to clarify that ARIN policy only covers 
> > > transfers of IP Resources administered by ARIN between 
> two parties 
> > > within the ARIN service region.
> > > 
> > > Owen
> > > 
> > > >> -----Original Message-----
> > > >> From: Owen DeLong [mailto:owen at delong.com]
> > > >> Sent: Thursday, September 18, 2008 11:37 AM
> > > >> To: Kevin Kargel
> > > >> Cc: arin-ppml at arin.net
> > > >> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > Transfer Policy
> > > >> Proposal -Revised
> > > >>
> > > >> Not so much.  The different registries have different transfer 
> > > >> policies (if they have any at all).  I think the best
> > thing is to
> > > >> make sure that ARIN policy applies to space which is
> > > administered by
> > > >> ARIN and leave it at that.
> > > >>
> > > >> Owen
> > > >>
> > > >> On Sep 18, 2008, at 7:58 AM, Kevin Kargel wrote:
> > > >>
> > > >>> I think this is more of an operational issue than a
> > policy issue.
> > > >>> Wouldn't it be better to work out a referral agreement with
> > > >> the other
> > > >>> registries where you refer requests to the proper registrar
> > > >> and they
> > > >>> refer requests to ARIN?  I don't know how you would do this
> > > >> other than
> > > >>> based on registration address, and there would be nothing
> > > >> preventing
> > > >>> the Tanzania hosting company from registering their
> > > network with a
> > > >>> Canadian address..
> > > >>>
> > > >>> Much the same situation exists with maritime ship
> > > >> registrations..  I
> > > >>> don't really see how to avoid or manage the issue.
> > > >>>
> > > >>> To restate my earlier posit..  Let's not make rules we
> > > >> can't enforce.
> > > >>>
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Scott Leibrand [mailto:sleibrand at internap.com]
> > > >>>> Sent: Thursday, September 18, 2008 9:15 AM
> > > >>>> To: Kevin Kargel
> > > >>>> Cc: arin-ppml at arin.net
> > > >>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > >> Transfer Policy
> > > >>>> Proposal -Revised
> > > >>>>
> > > >>>> It doesn't say it must be used in North America.  It says
> > > >> it must be
> > > >>>> *registered* for use there.  That means it must be
> > > registered with
> > > >>>> ARIN.
> > > >>>>
> > > >>>> This is not (intended to be) a new restriction: we're just
> > > >> trying to
> > > >>>> avoid having people come to us with LACNIC, AFRINIC, RIPE,
> > > >> or APNIC
> > > >>>> space and asking ARIN to transfer it.
> > > >>>>
> > > >>>> As I mentioned before, suggestions for improved wording
> > > >> are welcome.
> > > >>>>
> > > >>>> -Scott
> > > >>>>
> > > >>>> Kevin Kargel wrote:
> > > >>>>> I did not know that there was any way to control geographic
> > > >>>> use area..
> > > >>>>> So far as I know there is no way I can tell my router to
> > > >>>> deny from Tanzania..
> > > >>>>> (sorry Tanzania, I don't hate you, I just had to pick
> > > somebody)..
> > > >>>>>
> > > >>>>> Is there some BGP trick I don't know about that
> > > prevents me from
> > > >>>>> advertising an out of area network?
> > > >>>>>
> > > >>>>> If it cannot be policed then it shouldn't be in the
> > > >>>> verbage.  Nothing
> > > >>>>> will erode authority quicker than making rules you
> > > cannot enforce.
> > > >>>>>
> > > >>>>>
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: arin-ppml-bounces at arin.net 
> > > >>>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of
> > Scott Leibrand
> > > >>>>>> Sent: Thursday, September 18, 2008 8:55 AM
> > > >>>>>> To: michael.dillon at bt.com
> > > >>>>>> Cc: arin-ppml at arin.net
> > > >>>>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > >>>> Transfer Policy
> > > >>>>>> Proposal -Revised
> > > >>>>>>
> > > >>>>>> michael.dillon at bt.com wrote:
> > > >>>>>>>> * The IPv4 block must currently be registered for use
> > > >>>>>> within the ARIN
> > > >>>>>>>> service area.
> > > >>>>>>> What does this mean?
> > > >>>>>> The intent there is that it simply has to be ARIN space.
> > > >>>>>> We're open to suggestions for improved wording.
> > > >>>>>>
> > > >>>>>>> Since when does ARIN restrict the use of IP address blocks
> > > >>>>>> to specific
> > > >>>>>>> geographical regions? Does the ARIN restriction apply only
> > > >>>>>> to use as a
> > > >>>>>>> source address, or also in the destination address field?
> > > >>>>>>>
> > > >>>>>>> To which organization should one apply if one want to
> > > >> receive IP
> > > >>>>>>> address blocks which can be used globally without
> > geographic
> > > >>>>>>> restrictions?
> > > >>>>>> I don't believe IANA has any intent to distribute
> > > >> address space to
> > > >>>>>> ISPs or end users that can be used globally without
> > geographic
> > > >>>>>> restrictions.  In the current system, addresses are
> > > >> allocated from
> > > >>>>>> the registry in the region in which they are primarily
> > > >> to be used,
> > > >>>>>> and we aren't trying to upset that apple cart just yet.
> > > >>>>>>
> > > >>>>>> -Scott
> > > >>>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> PPML
> > > >>>>>> You are receiving this message because you are subscribed
> > > >>>> to the ARIN
> > > >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> > > >>>>>> Unsubscribe or manage your mailing list subscription at:
> > > >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > > >>>>>> Please contact info at arin.net if you experience any issues.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>
> > > >> 
> > > 
> > 
> ---------------------------------------------------------------------
> > > >>>>>> ---
> > > >>>>>>
> > > >>>>>> _______________________________________________
> > > >>>>>> PPML
> > > >>>>>> You are receiving this message because you are subscribed
> > > >>>> to the ARIN
> > > >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> > > >>>>>> Unsubscribe or manage your mailing list subscription at:
> > > >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > > >>>>>> Please contact info at arin.net if you experience any issues.
> > > >>>>
> > > >>> _______________________________________________
> > > >>> PPML
> > > >>> You are receiving this message because you are subscribed
> > > >> to the ARIN
> > > >>> Public Policy Mailing List (ARIN-PPML at arin.net).
> > > >>> Unsubscribe or manage your mailing list subscription at:
> > > >>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > > >>> Please contact info at arin.net if you experience any issues.
> > > >>
> > > >>
> > > 
> > > 
> > 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080918/68641f60/attachment.bin>

From cgrundemann at gmail.com  Thu Sep 18 14:28:50 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 18 Sep 2008 12:28:50 -0600
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
	Proposal -Revised
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B14@mail>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net>
	<48D25DAF.7030305@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail>
	<48D2626A.8060509@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B0E@mail>
	<A06F0E20-A25B-4E4F-AA2D-E1A127049E93@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B11@mail>
	<218797CE-B4D9-45F9-9130-583DF487E0B6@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B14@mail>
Message-ID: <443de7ad0809181128ya093f34p8313f92ca58056b9@mail.gmail.com>

On Thu, Sep 18, 2008 at 12:01 PM, Kevin Kargel <kkargel at polartel.com> wrote:
> Ah, so if Mitsuyama Corp in Japan wants an ARIN IP block they just need to
> get a mailing address in the US for the transfer process, give the US
> corporation a bunch of money, get posession of the IP's, and abandon the
> CONUS mailing address..  Then they are operating within the policy and
> everything is ok..
>
> It doesn't look like we are solving anything..  Just making another red tape
> loop..
>
AIUI, all this sentence is meant to say is that ARIN will only
participate in the transfer of IP space if that IP space is currently
within their jurisdiction.

Note that it resides in section 8.3.3 "Conditions on the IPv4 address
block to be transferred."  It is not a direct restriction on the
transferor or transferee which is where your focus seems to be.  That
being said, I have to agree with Owen that the policy as a whole
should keep transfers completely within the ARIN region because the
various registries have different policies.  Not only different in
regards to transfers but with regards to many aspects of IP address
assignment and allocation.  Allowing end users and LIRs to transfer IP
space inter-region has the potential to cause many more difficulties
than not allowing it, at this time.

~Chris
>
>
>> -----Original Message-----
>> From: Owen DeLong [mailto:owen at delong.com]
>> Sent: Thursday, September 18, 2008 12:50 PM
>> To: Kevin Kargel
>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
>> Transfer Policy Proposal -Revised
>>
>>
>> On Sep 18, 2008, at 10:39 AM, Kevin Kargel wrote:
>>
>> > By "space" do you mean IP space or geo-space?
>> >
>> IP Space.
>>
>> > In either case I still think the best solution is just to forward
>> > requests from outside of "ARIN space" to the appropriate registry..
>> >
>> The problem comes when you have an ORG that is within the
>> ARIN service Region trying to transfer ARIN registered space
>> to an ORG that is outside of the ARIN service region or vice versa.
>>
>> The best thing is, IMHO, to clarify that ARIN policy only
>> covers transfers of IP Resources administered by ARIN between
>> two parties within the ARIN service region.
>>
>> Owen
>>
>> >> -----Original Message-----
>> >> From: Owen DeLong [mailto:owen at delong.com]
>> >> Sent: Thursday, September 18, 2008 11:37 AM
>> >> To: Kevin Kargel
>> >> Cc: arin-ppml at arin.net
>> >> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
>> Transfer Policy
>> >> Proposal -Revised
>> >>
>> >> Not so much.  The different registries have different transfer
>> >> policies (if they have any at all).  I think the best thing is to
>> >> make sure that ARIN policy applies to space which is
>> administered by
>> >> ARIN and leave it at that.
>> >>
>> >> Owen
>> >>
>> >> On Sep 18, 2008, at 7:58 AM, Kevin Kargel wrote:
>> >>
>> >>> I think this is more of an operational issue than a policy issue.
>> >>> Wouldn't it be better to work out a referral agreement with
>> >> the other
>> >>> registries where you refer requests to the proper registrar
>> >> and they
>> >>> refer requests to ARIN?  I don't know how you would do this
>> >> other than
>> >>> based on registration address, and there would be nothing
>> >> preventing
>> >>> the Tanzania hosting company from registering their
>> network with a
>> >>> Canadian address..
>> >>>
>> >>> Much the same situation exists with maritime ship
>> >> registrations..  I
>> >>> don't really see how to avoid or manage the issue.
>> >>>
>> >>> To restate my earlier posit..  Let's not make rules we
>> >> can't enforce.
>> >>>
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: Scott Leibrand [mailto:sleibrand at internap.com]
>> >>>> Sent: Thursday, September 18, 2008 9:15 AM
>> >>>> To: Kevin Kargel
>> >>>> Cc: arin-ppml at arin.net
>> >>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
>> >> Transfer Policy
>> >>>> Proposal -Revised
>> >>>>
>> >>>> It doesn't say it must be used in North America.  It says
>> >> it must be
>> >>>> *registered* for use there.  That means it must be
>> registered with
>> >>>> ARIN.
>> >>>>
>> >>>> This is not (intended to be) a new restriction: we're just
>> >> trying to
>> >>>> avoid having people come to us with LACNIC, AFRINIC, RIPE,
>> >> or APNIC
>> >>>> space and asking ARIN to transfer it.
>> >>>>
>> >>>> As I mentioned before, suggestions for improved wording
>> >> are welcome.
>> >>>>
>> >>>> -Scott
>> >>>>
>> >>>> Kevin Kargel wrote:
>> >>>>> I did not know that there was any way to control geographic
>> >>>> use area..
>> >>>>> So far as I know there is no way I can tell my router to
>> >>>> deny from Tanzania..
>> >>>>> (sorry Tanzania, I don't hate you, I just had to pick
>> somebody)..
>> >>>>>
>> >>>>> Is there some BGP trick I don't know about that
>> prevents me from
>> >>>>> advertising an out of area network?
>> >>>>>
>> >>>>> If it cannot be policed then it shouldn't be in the
>> >>>> verbage.  Nothing
>> >>>>> will erode authority quicker than making rules you
>> cannot enforce.
>> >>>>>
>> >>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: arin-ppml-bounces at arin.net
>> >>>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
>> >>>>>> Sent: Thursday, September 18, 2008 8:55 AM
>> >>>>>> To: michael.dillon at bt.com
>> >>>>>> Cc: arin-ppml at arin.net
>> >>>>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
>> >>>> Transfer Policy
>> >>>>>> Proposal -Revised
>> >>>>>>
>> >>>>>> michael.dillon at bt.com wrote:
>> >>>>>>>> * The IPv4 block must currently be registered for use
>> >>>>>> within the ARIN
>> >>>>>>>> service area.
>> >>>>>>> What does this mean?
>> >>>>>> The intent there is that it simply has to be ARIN space.
>> >>>>>> We're open to suggestions for improved wording.
>> >>>>>>
>> >>>>>>> Since when does ARIN restrict the use of IP address blocks
>> >>>>>> to specific
>> >>>>>>> geographical regions? Does the ARIN restriction apply only
>> >>>>>> to use as a
>> >>>>>>> source address, or also in the destination address field?
>> >>>>>>>
>> >>>>>>> To which organization should one apply if one want to
>> >> receive IP
>> >>>>>>> address blocks which can be used globally without geographic
>> >>>>>>> restrictions?
>> >>>>>> I don't believe IANA has any intent to distribute
>> >> address space to
>> >>>>>> ISPs or end users that can be used globally without geographic
>> >>>>>> restrictions.  In the current system, addresses are
>> >> allocated from
>> >>>>>> the registry in the region in which they are primarily
>> >> to be used,
>> >>>>>> and we aren't trying to upset that apple cart just yet.
>> >>>>>>
>> >>>>>> -Scott
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> PPML
>> >>>>>> You are receiving this message because you are subscribed
>> >>>> to the ARIN
>> >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> >>>>>> Unsubscribe or manage your mailing list subscription at:
>> >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> >>>>>> Please contact info at arin.net if you experience any issues.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>
>> ---------------------------------------------------------------------
>> >>>>>> ---
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> PPML
>> >>>>>> You are receiving this message because you are subscribed
>> >>>> to the ARIN
>> >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> >>>>>> Unsubscribe or manage your mailing list subscription at:
>> >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> >>>>>> Please contact info at arin.net if you experience any issues.
>> >>>>
>> >>> _______________________________________________
>> >>> PPML
>> >>> You are receiving this message because you are subscribed
>> >> to the ARIN
>> >>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> >>> Unsubscribe or manage your mailing list subscription at:
>> >>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> >>> Please contact info at arin.net if you experience any issues.
>> >>
>> >>
>>
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
Chris Grundemann
www.linkedin.com/in/cgrundemann


From Lee.Howard at stanleyassociates.com  Thu Sep 18 14:42:39 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Thu, 18 Sep 2008 14:42:39 -0400
Subject: [arin-ppml] Policy Proposal 2008-2:IPv4Transfer	Policy	Proposal
	-Revised
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B15@mail>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B5A1F6A@CL-S-EX-1.stanleyassociates.com>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Thursday, September 18, 2008 2:27 PM
> To: PPML PPML
> Subject: Re: [arin-ppml] Policy Proposal 2008-2:IPv4Transfer 
> Policy Proposal -Revised
> 
> But....  If we are not going to follow through, if we are not 
> going to police the rule..  Then what point is there to the rule?  
> 
> The answer is just to state that "physical addresses for all 
> registrant parties for all registrations, requests and/or 
> transfers must be in the 'ARIN Service Area' " then define 
> the ARIN service area..  Then it is simple..  No policing, no 
> impotent rules.

http://www.arin.net/community/ARINcountries.html

I don't understand your point.  The policy is enforced
by staff checking the address of the organizations and
not processing transfers outside of region.  

If you're arguing that people might set up phony offices
just to get ARIN addresses, I respond:
* why would anyone do that?
* is it likely to be so many that the policy is useless?
* so what if they do?
* if the office goes away, they stop receiving invoices and
paying their bill, and ARIN revokes the address space

FWIW, I'm not saying I support this proposal necessarily,
I'm just not convinced that your argument is strong.

Lee
 
> > -----Original Message-----
> > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com]
> > Sent: Thursday, September 18, 2008 1:19 PM
> > To: Kevin Kargel; PPML PPML
> > Subject: RE: [arin-ppml] Policy Proposal 2008-2: 
> IPv4Transfer Policy 
> > Proposal -Revised
> > 
> > 
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net
> > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> > > Sent: Thursday, September 18, 2008 2:01 PM
> > > To: PPML PPML
> > > Subject: Re: [arin-ppml] Policy Proposal 2008-2: 
> > IPv4Transfer Policy
> > > Proposal -Revised
> > > 
> > > Ah, so if Mitsuyama Corp in Japan wants an ARIN IP block 
> they just 
> > > need to get a mailing address in the US for the transfer
> > process, give
> > > the US corporation a bunch of money, get posession of the 
> IP's, and 
> > > abandon the CONUS mailing address..  Then they are 
> operating within 
> > > the policy and everything is ok..
> > 
> > Yes.  This is the current situation.  It doesn't come up, 
> because the 
> > integers in North American taste just the same as the 
> integers in the 
> > Asia Pacific region.
> > 
> > However, ARIN should not facilitate transfers from extra-regional 
> > organizations, because ARIN doesn't have authority over 
> those numbers.
> > 
> > > It doesn't look like we are solving anything..  Just 
> making another 
> > > red tape loop..
> > 
> > The fact that a barrier is imperfect does not mean it should not be 
> > built.
> > 
> > First decide if a barrier is desirable.  The build the appropriate 
> > barrier.  In this case, ARIN serves the ARIN region, so 
> except where 
> > desired, policy should not provide for allocations outside 
> the region.
> > 
> > Not a Board product.  IMHO, YMMV, IANAL, PEBCAK, TANSTAAFL, floss 
> > regularly, tip your waitstaff, wear sunscreen, void where 
> prohibited.
> > 
> > Lee
> > 
> > 
> > 
> > > > -----Original Message-----
> > > > From: Owen DeLong [mailto:owen at delong.com]
> > > > Sent: Thursday, September 18, 2008 12:50 PM
> > > > To: Kevin Kargel
> > > > Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > Transfer Policy
> > > > Proposal -Revised
> > > > 
> > > > 
> > > > On Sep 18, 2008, at 10:39 AM, Kevin Kargel wrote:
> > > > 
> > > > > By "space" do you mean IP space or geo-space?
> > > > >
> > > > IP Space.
> > > > 
> > > > > In either case I still think the best solution is just
> > to forward
> > > > > requests from outside of "ARIN space" to the appropriate
> > > registry..
> > > > >
> > > > The problem comes when you have an ORG that is within the
> > > ARIN service
> > > > Region trying to transfer ARIN registered space to an 
> ORG that is 
> > > > outside of the ARIN service region or vice versa.
> > > > 
> > > > The best thing is, IMHO, to clarify that ARIN policy 
> only covers 
> > > > transfers of IP Resources administered by ARIN between
> > two parties
> > > > within the ARIN service region.
> > > > 
> > > > Owen
> > > > 
> > > > >> -----Original Message-----
> > > > >> From: Owen DeLong [mailto:owen at delong.com]
> > > > >> Sent: Thursday, September 18, 2008 11:37 AM
> > > > >> To: Kevin Kargel
> > > > >> Cc: arin-ppml at arin.net
> > > > >> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > > Transfer Policy
> > > > >> Proposal -Revised
> > > > >>
> > > > >> Not so much.  The different registries have 
> different transfer 
> > > > >> policies (if they have any at all).  I think the best
> > > thing is to
> > > > >> make sure that ARIN policy applies to space which is
> > > > administered by
> > > > >> ARIN and leave it at that.
> > > > >>
> > > > >> Owen
> > > > >>
> > > > >> On Sep 18, 2008, at 7:58 AM, Kevin Kargel wrote:
> > > > >>
> > > > >>> I think this is more of an operational issue than a
> > > policy issue.
> > > > >>> Wouldn't it be better to work out a referral agreement with
> > > > >> the other
> > > > >>> registries where you refer requests to the proper registrar
> > > > >> and they
> > > > >>> refer requests to ARIN?  I don't know how you would do this
> > > > >> other than
> > > > >>> based on registration address, and there would be nothing
> > > > >> preventing
> > > > >>> the Tanzania hosting company from registering their
> > > > network with a
> > > > >>> Canadian address..
> > > > >>>
> > > > >>> Much the same situation exists with maritime ship
> > > > >> registrations..  I
> > > > >>> don't really see how to avoid or manage the issue.
> > > > >>>
> > > > >>> To restate my earlier posit..  Let's not make rules we
> > > > >> can't enforce.
> > > > >>>
> > > > >>>
> > > > >>>> -----Original Message-----
> > > > >>>> From: Scott Leibrand [mailto:sleibrand at internap.com]
> > > > >>>> Sent: Thursday, September 18, 2008 9:15 AM
> > > > >>>> To: Kevin Kargel
> > > > >>>> Cc: arin-ppml at arin.net
> > > > >>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > > >> Transfer Policy
> > > > >>>> Proposal -Revised
> > > > >>>>
> > > > >>>> It doesn't say it must be used in North America.  It says
> > > > >> it must be
> > > > >>>> *registered* for use there.  That means it must be
> > > > registered with
> > > > >>>> ARIN.
> > > > >>>>
> > > > >>>> This is not (intended to be) a new restriction: we're just
> > > > >> trying to
> > > > >>>> avoid having people come to us with LACNIC, AFRINIC, RIPE,
> > > > >> or APNIC
> > > > >>>> space and asking ARIN to transfer it.
> > > > >>>>
> > > > >>>> As I mentioned before, suggestions for improved wording
> > > > >> are welcome.
> > > > >>>>
> > > > >>>> -Scott
> > > > >>>>
> > > > >>>> Kevin Kargel wrote:
> > > > >>>>> I did not know that there was any way to control 
> geographic
> > > > >>>> use area..
> > > > >>>>> So far as I know there is no way I can tell my router to
> > > > >>>> deny from Tanzania..
> > > > >>>>> (sorry Tanzania, I don't hate you, I just had to pick
> > > > somebody)..
> > > > >>>>>
> > > > >>>>> Is there some BGP trick I don't know about that
> > > > prevents me from
> > > > >>>>> advertising an out of area network?
> > > > >>>>>
> > > > >>>>> If it cannot be policed then it shouldn't be in the
> > > > >>>> verbage.  Nothing
> > > > >>>>> will erode authority quicker than making rules you
> > > > cannot enforce.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>> -----Original Message-----
> > > > >>>>>> From: arin-ppml-bounces at arin.net 
> > > > >>>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of
> > > Scott Leibrand
> > > > >>>>>> Sent: Thursday, September 18, 2008 8:55 AM
> > > > >>>>>> To: michael.dillon at bt.com
> > > > >>>>>> Cc: arin-ppml at arin.net
> > > > >>>>>> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4
> > > > >>>> Transfer Policy
> > > > >>>>>> Proposal -Revised
> > > > >>>>>>
> > > > >>>>>> michael.dillon at bt.com wrote:
> > > > >>>>>>>> * The IPv4 block must currently be registered for use
> > > > >>>>>> within the ARIN
> > > > >>>>>>>> service area.
> > > > >>>>>>> What does this mean?
> > > > >>>>>> The intent there is that it simply has to be ARIN space.
> > > > >>>>>> We're open to suggestions for improved wording.
> > > > >>>>>>
> > > > >>>>>>> Since when does ARIN restrict the use of IP 
> address blocks
> > > > >>>>>> to specific
> > > > >>>>>>> geographical regions? Does the ARIN restriction 
> apply only
> > > > >>>>>> to use as a
> > > > >>>>>>> source address, or also in the destination 
> address field?
> > > > >>>>>>>
> > > > >>>>>>> To which organization should one apply if one want to
> > > > >> receive IP
> > > > >>>>>>> address blocks which can be used globally without
> > > geographic
> > > > >>>>>>> restrictions?
> > > > >>>>>> I don't believe IANA has any intent to distribute
> > > > >> address space to
> > > > >>>>>> ISPs or end users that can be used globally without
> > > geographic
> > > > >>>>>> restrictions.  In the current system, addresses are
> > > > >> allocated from
> > > > >>>>>> the registry in the region in which they are primarily
> > > > >> to be used,
> > > > >>>>>> and we aren't trying to upset that apple cart just yet.
> > > > >>>>>>
> > > > >>>>>> -Scott
> > > > >>>>>>
> > > > >>>>>> _______________________________________________
> > > > >>>>>> PPML
> > > > >>>>>> You are receiving this message because you are subscribed
> > > > >>>> to the ARIN
> > > > >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > >>>>>> Unsubscribe or manage your mailing list subscription at:
> > > > >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > >>>>>> Please contact info at arin.net if you experience 
> any issues.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >> 
> > > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > > >>>>>> ---
> > > > >>>>>>
> > > > >>>>>> _______________________________________________
> > > > >>>>>> PPML
> > > > >>>>>> You are receiving this message because you are subscribed
> > > > >>>> to the ARIN
> > > > >>>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > >>>>>> Unsubscribe or manage your mailing list subscription at:
> > > > >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > >>>>>> Please contact info at arin.net if you experience 
> any issues.
> > > > >>>>
> > > > >>> _______________________________________________
> > > > >>> PPML
> > > > >>> You are receiving this message because you are subscribed
> > > > >> to the ARIN
> > > > >>> Public Policy Mailing List (ARIN-PPML at arin.net).
> > > > >>> Unsubscribe or manage your mailing list subscription at:
> > > > >>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > > > >>> Please contact info at arin.net if you experience any issues.
> > > > >>
> > > > >>
> > > > 
> > > > 
> > > 
> > 
> 


From mueller at syr.edu  Thu Sep 18 16:39:21 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 18 Sep 2008 16:39:21 -0400
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
	Proposal -Revised
In-Reply-To: <48D2561D.2040205@arin.net>
References: <48D2561D.2040205@arin.net>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E917@SUEXCL-02.ad.syr.edu>

You ACs have been working hard. It is improved! A few comments based on
an unfortunately (but necessarily) hasty review

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Author: ARIN Advisory Council
> 
> [Renumber existing 8.3 to 8.2.1 and retitle to "Documentation
> Requirements for Transfers as an Artifact of Change in Resource Holder
> Ownership"]
> 
> [Add the following new section:]
> 
> 8.3. Simple Transfer of IPv4 Addresses

Doesn't conform to my definition of "simple" but I understand the
constraints... ;-)

> * If the transferor elects to retain a portion of a block pursuant to
> 8.3.6, rather than transferring an entire block, the transferor must
> sign (or have previously signed) a RSA or LRSA covering the retained
> portion.

Clever! Seems a good way to handle one aspect of this vexed question,
Bear in mind however that some prospective sellers might opt out of
transferring when faced with this choice.

> * The IPv4 block must currently be registered for use within the ARIN
> service area.

I think you mean, "The IPv4 block must currently be within the range of
address blocks allocated to ARIN." Who cares _where_ they use it? 

> * An interested transferee must seek pre-qualification from ARIN to
> confirm its eligibility to receive a transfer (including satisfaction
of
> need according to current ARIN policies) before making any
solicitation
> for transfer. Upon pre-qualification, ARIN will provide the transferee
> with documentation of the pre-qualification, including the size (CIDR
> prefix length) of the largest IPv4 address block the transferee is
> eligible to receive, and the expiration date of the pre-qualification.

How quickly can ARIN issue this?

> * An interested transferor may seek pre-qualification from ARIN to
> confirm its eligibility to offer a transfer before offering IPv4
address
> resources for transfer. 

I would reword as "...may seek pre-qualification from ARIN to
authenticate its prior assignment or allocation of the address resources
offered for transfer."

> 8.3.7. Safe Harbor
> 
> The fact that an IPv4 address holder is making IPv4 addresses
available
> for transfer, pursuant to this policy, does not, in and of itself,
> indicate that the address holder lacks the need required for an
> allocation under ARIN policy.

Good!

> 8.3.8. Organizations under Common Ownership or Control
> 
> If an IPv4 transferor or transferee is under common ownership or
control
> with any other organization that holds one or more IPv4 blocks, the
IPv4
> transfer request must report all such organizations under common
> ownership or control. When evaluating compliance with IPv4 Simple
> Transfer conditions, ARIN may consider a transfer request in light of
> requests from other organizations under common ownership or control.

I see why you might want to apply this provision to recipients (i.e.,
buyers - still afraid of that word, eh?) I don't think it makes any
sense to apply it to transferororors (sellers). 

Do organizations currently have the right to freely transfer IPv4 blocks
among their subsidiaries without approval or review from ARIN? If so, I
guess I understand what this provision is driving at.  

This provision seems to imply that ARIN may use the possibility of
internal transfers as a criterion in approving transfers. If ARIN is
confronted with more transfererereeeees (buyers) than transferorororors
(sellers), then it might say to a prospective transfererereeeee "get the
addresses from other departments in your company." 

You might want to clarify this.

> 
> 8.3.9. Record-keeping and Publication
> 
> ARIN will develop and operate a listing service to assist interested
> transferors and transferees by providing them a centralized location
to
> post information about IPv4 blocks available from pre-qualified
> transferors and IPv4 blocks needed by pre-qualified transferees.
> 
> Participation in the listing service is voluntary.
> 
> After completion of a transfer, ARIN will update the registration and
> WHOIS records pertaining to the IPv4 block. ARIN will also publish a
log
> of all transfers, including block, transferor, transferee, and date.
> 
> 
> Rationale:
> 

This section of the policy is much improved. 


From mueller at syr.edu  Thu Sep 18 16:46:02 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 18 Sep 2008 16:46:02 -0400
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer
	PolicyProposal -Revised
In-Reply-To: <443de7ad0809181128ya093f34p8313f92ca58056b9@mail.gmail.com>
References: <C0F2465B4F386241A58321C884AC7ECC081E1CC1@E03MVZ2-UKDY.domain1.systemhost.net><48D25DAF.7030305@internap.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B0C@mail><48D2626A.8060509@internap.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B0E@mail><A06F0E20-A25B-4E4F-AA2D-E1A127049E93@delong.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B11@mail><218797CE-B4D9-45F9-9130-583DF487E0B6@delong.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B14@mail>
	<443de7ad0809181128ya093f34p8313f92ca58056b9@mail.gmail.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E918@SUEXCL-02.ad.syr.edu>



> -----Original Message-----
> should keep transfers completely within the ARIN region because the
> various registries have different policies.  Not only different in
> regards to transfers but with regards to many aspects of IP address
> assignment and allocation.  Allowing end users and LIRs to transfer IP
> space inter-region has the potential to cause many more difficulties
> than not allowing it, at this time.
> 

Careful now. One of the key justifications for an RIR address allocation
regime (as opposed to a national government allocation regime) is that
address allocations should be based on network topology, not territorial
boundaries. 



From bonomi at mail.r-bonomi.com  Thu Sep 18 16:58:16 2008
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Thu, 18 Sep 2008 15:58:16 -0500 (CDT)
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
	Proposal -Revised
Message-ID: <200809182058.m8IKwGdb010195@mail.r-bonomi.com>

> From arin-ppml-bounces at arin.net  Thu Sep 18 11:54:48 2008
> Date: Thu, 18 Sep 2008 10:54:28 -0600
> From: "Chris Grundemann" <cgrundemann at gmail.com>
> To: "Scott Leibrand" <sleibrand at internap.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
> 	Proposal -Revised
>
> On Thu, Sep 18, 2008 at 7:54 AM, Scott Leibrand <sleibrand at internap.com> wrote:
> > michael.dillon at bt.com wrote:
> >>> * The IPv4 block must currently be registered for use within
> >>> the ARIN service area.
> >>
> >> What does this mean?
> >
> > The intent there is that it simply has to be ARIN space.  We're open to
> > suggestions for improved wording.
> >
> A quick stab at it:
> // The IPv4 block must currently be registered with ARIN or be
> recognized legacy space within the ARIN service area. //
> IMHO that wording may avoid misconceptions / perceptions about (new)
> geographic limitations.

I will suggest that three things need to be addressed:

  1) that the IPv4 block is covered by a -current- ARIN service agreement
     (either an RSA or LRSA is acceptable).

  2) That the transferee would qualify for a direct assignment/allocation 
     from ARIN of the size of the block that is being transferred.  This 
     specifically _includes_  the 'efficient use of existing addresses'
     requirement.  "Special-case language" is required to cover the situation
     where the existing block is smaller than the current ARIN-issue minimum.

  3) That the transfer be either: 
        a) at least the minimum size that ARIN will presently directly 
           assign/allocate
       -or-
        b) the entire block shown in ARIN records, if smaller than the 
           current assignment/allocation minimum.

Rationale:

(1) prevents anybody from trying do an "ARIN-transfer" of "other RIR" space.
(2) requires that the _transferee_ be in 'ARIN space' -- if they're not, they
    should be getting space under another RIR's  policies.
(3) puts a limit on the amount of 'fragmentation' that can/will occur, 
    insuring that things, in that respect, get 'no worse' than if the space
    was returned to ARIN and re-allocated.

Actual verbage is easily derivable from the above 'specification', with the 
exception of the 'special case' situation in (2).  What kind of a minimum is
needed on the 'planned utilization' (within a 6 mo. time-frame) of a /24 to 
justify it?

Comments, suggestions ?




From sleibrand at internap.com  Thu Sep 18 17:06:24 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 18 Sep 2008 14:06:24 -0700
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
 Proposal -Revised
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E917@SUEXCL-02.ad.syr.edu>
References: <48D2561D.2040205@arin.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E917@SUEXCL-02.ad.syr.edu>
Message-ID: <48D2C2D0.90109@internap.com>

Milton L Mueller wrote:
> You ACs have been working hard. It is improved! A few comments based on
> an unfortunately (but necessarily) hasty review

Thanks.

>> * The IPv4 block must currently be registered for use within the ARIN
>> service area.
> 
> I think you mean, "The IPv4 block must currently be within the range of
> address blocks allocated to ARIN." Who cares _where_ they use it? 

Based on the results of the PPML poll, we also want to make sure the 
language covers legacy blocks, not just blocks allocated to/by ARIN.  How 
about this?  I think it would satisfy your concerns as well as the others 
raised this morning:

"The IPv4 block must be administered by ARIN, for example as part of an 
address block assigned by IANA to ARIN, or as part of a legacy address 
block allocated within the ARIN service area."

>> * An interested transferee must seek pre-qualification from ARIN to
>> confirm its eligibility to receive a transfer (including satisfaction
> of
>> need according to current ARIN policies) before making any
> solicitation
>> for transfer. Upon pre-qualification, ARIN will provide the transferee
>> with documentation of the pre-qualification, including the size (CIDR
>> prefix length) of the largest IPv4 address block the transferee is
>> eligible to receive, and the expiration date of the pre-qualification.
> 
> How quickly can ARIN issue this?

Current need justification can be very quick, when a requester provides 
all the necessary documentation in their initial request, or can take a 
little bit of back-and-forth if the requester has to go dig up 
documentation on current usage.  I'd guess that the same sort of 
timeframes would apply to a pre-qualification request, as the same 
eligibility checks would apply.

>> * An interested transferor may seek pre-qualification from ARIN to
>> confirm its eligibility to offer a transfer before offering IPv4
> address
>> resources for transfer. 
> 
> I would reword as "...may seek pre-qualification from ARIN to
> authenticate its prior assignment or allocation of the address resources
> offered for transfer."

There is also the question of whether the 12-month clock has elapsed such 
that the space is eligible for transfer.

>> 8.3.8. Organizations under Common Ownership or Control
>>
>> If an IPv4 transferor or transferee is under common ownership or
> control
>> with any other organization that holds one or more IPv4 blocks, the
> IPv4
>> transfer request must report all such organizations under common
>> ownership or control. When evaluating compliance with IPv4 Simple
>> Transfer conditions, ARIN may consider a transfer request in light of
>> requests from other organizations under common ownership or control.
> 
> I see why you might want to apply this provision to recipients (i.e.,
> buyers - still afraid of that word, eh?) I don't think it makes any
> sense to apply it to transferororors (sellers). 

LOL.  (/me imagines people talking about transferororors and 
transfererereeeees at the L.A. meeting)  :)  The problem with the terms 
buyer and seller is the question of what's being bought and sold.  I don't 
really want to start talking about the "buyer of a set of contractual 
rights to unique registration records and associated registration 
services", or whatever the proper legal terminology would be, since you 
can't buy the numbers themselves.  :)

> Do organizations currently have the right to freely transfer IPv4 blocks
> among their subsidiaries without approval or review from ARIN? If so, I
> guess I understand what this provision is driving at.  
> 
> This provision seems to imply that ARIN may use the possibility of
> internal transfers as a criterion in approving transfers. If ARIN is
> confronted with more transfererereeeees (buyers) than transferorororors
> (sellers), then it might say to a prospective transfererereeeee "get the
> addresses from other departments in your company." 
> 
> You might want to clarify this.

That's part of it.  Imagine a large company with multiple subsidiaries, 
one of which requests and receives a large block of addresses just before 
ARIN runs out.  If the other subsidiary then turns around 6 months later 
and wants to offer (different) addresses for transfer, this clause would 
require that they tell ARIN about the other subsidiaries, so that ARIN can 
consider whether their behavior, in aggregate, complies with the policy. 
In this case, it would be the transferor under 2008-2 who'd be out of line 
with the policy, hence the need for common-control disclosure there as well.

Thanks for your comments,
Scott


From mueller at syr.edu  Thu Sep 18 17:19:31 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 18 Sep 2008 17:19:31 -0400
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
	Proposal -Revised
In-Reply-To: <48D2C2D0.90109@internap.com>
References: <48D2561D.2040205@arin.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E917@SUEXCL-02.ad.syr.edu>
	<48D2C2D0.90109@internap.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E91B@SUEXCL-02.ad.syr.edu>


> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com]
> "The IPv4 block must be administered by ARIN, for example as part of
an
> address block assigned by IANA to ARIN, or as part of a legacy address
> block allocated within the ARIN service area."

Close, I would say that: 

"The IPv4 block transferred must be one administered by ARIN, either as
part of an address block assigned by IANA to ARIN, or as part of a
legacy address block allocated within the ARIN service area." 

> > I would reword as "...may seek pre-qualification from ARIN to
> > authenticate its prior assignment or allocation of the address
resources
> > offered for transfer."
> 
> There is also the question of whether the 12-month clock has elapsed
such
> that the space is eligible for transfer.

OK, so it's:

"...may seek pre-qualification from ARIN to authenticate its prior
assignment or allocation of the address resources offered for transfer
and its compliance with transfer time limits."

The idea is just to avoid purely discretionary blockages of transfers.
But if I'm getting to be too much like a lawyer, shoot me.

> That's part of it.  Imagine a large company with multiple
subsidiaries,
> one of which requests and receives a large block of addresses just
before
> ARIN runs out.  If the other subsidiary then turns around 6 months
later
> and wants to offer (different) addresses for transfer, this clause
would
> require that they tell ARIN about the other subsidiaries, so that ARIN
can
> consider whether their behavior, in aggregate, complies with the
policy.
> In this case, it would be the transferor under 2008-2 who'd be out of
line
> with the policy, hence the need for common-control disclosure there as
> well.

Sure, it's another speculation check, understood. Does ARIN have the
resources to check compliance with the reporting requirements? 

> Thanks for your comments,

welcome



From sleibrand at internap.com  Thu Sep 18 17:27:36 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 18 Sep 2008 14:27:36 -0700
Subject: [arin-ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
 Proposal -Revised
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E91B@SUEXCL-02.ad.syr.edu>
References: <48D2561D.2040205@arin.net>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E917@SUEXCL-02.ad.syr.edu>
	<48D2C2D0.90109@internap.com>
	<7663C7E01D8E094989CA62F0B0D21CD901E0E91B@SUEXCL-02.ad.syr.edu>
Message-ID: <48D2C7C8.8070702@internap.com>

Milton L Mueller wrote:
>> -----Original Message-----
>> From: Scott Leibrand [mailto:sleibrand at internap.com]
>> "The IPv4 block must be administered by ARIN, for example as part of an
>> address block assigned by IANA to ARIN, or as part of a legacy address
>> block allocated within the ARIN service area."
> 
> Close, I would say that: 
> 
> "The IPv4 block transferred must be one administered by ARIN, either as
> part of an address block assigned by IANA to ARIN, or as part of a
> legacy address block allocated within the ARIN service area." 

Ok, works for me.  We're almost back to the language from 2008-2 version 
1.0.  :)

>>> I would reword as "...may seek pre-qualification from ARIN to
>>> authenticate its prior assignment or allocation of the address
>> resources offered for transfer."
>> There is also the question of whether the 12-month clock has elapsed
>> such that the space is eligible for transfer.
> 
> OK, so it's:
> 
> "...may seek pre-qualification from ARIN to authenticate its prior
> assignment or allocation of the address resources offered for transfer
> and its compliance with transfer time limits."
> 
> The idea is just to avoid purely discretionary blockages of transfers.
> But if I'm getting to be too much like a lawyer, shoot me.

I don't think that's a concern, because 8.3.5 says that "interested 
transferor *may* seek pre-qualification".  Since it's optional, it can't 
really hold anything up.

> Sure, it's another speculation check, understood. Does ARIN have the
> resources to check compliance with the reporting requirements? 

Generally ARIN is aware when a company has more than one Org ID (and 
usually for good reason).  So most of the time this wouldn't require any 
extra resources on ARIN's part.  ARIN's fraud-detection sensors have 
gotten pretty good (I hear), so I have no doubt they'd have resources to 
check up on things when there's reason for suspicion.  I don't think 
they'd be routinely checking through SEC filings on every request that 
comes in, though.  :)

-Scott


From carlton.samuels at uwimona.edu.jm  Thu Sep 18 17:34:17 2008
From: carlton.samuels at uwimona.edu.jm (Carlton Samuels)
Date: Thu, 18 Sep 2008 16:34:17 -0500
Subject: [arin-ppml] ARIN Policy Proposal 2008:4 Minimum Allocation in the
	Caribbean Region
Message-ID: <005501c919d6$4e95b6a0$ebc123e0$@samuels@uwimona.edu.jm>

This policy proposal posits a minimum allocation of IPv4 for Caribbean ISPs
in the ARIN region to be /22. We wish to record our emphatic support for
this policy as written.   More details may be seen at
http://www.arin.net/policy/proposals/2008_4.html .

 

The facts as we know them are not controversial: Caribbean ISPs and
enterprises are smaller scale than the typical North American entities.  And
while most number resources are indirectly assigned, there are even a few
enterprise operations with number resources directly assigned from ARIN.
This policy levels the playing field and lower the barrier to Caribbean
entities receiving the services that ARIN has to offer. 

 

Even though ARIN has been engaged in outreach work in the region, the role
of the Regional Internet Registry (RIR) in [IP] number resource management
remains largely unknown. So policies that impact us directly do not get as
wide a participation and/or acclamation that they deserve. I am especially
encouraging our IEEE colleagues to participate in the ARIN Public Policy
discussions by joining the public policy list.  I also commend their
endorsement of this policy.

 

Carlton A Samuels

The University of the West Indies at Mona

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080918/98fb383e/attachment.htm>

From Fred.Wettling at Bechtel.com  Fri Sep 19 07:04:12 2008
From: Fred.Wettling at Bechtel.com (Wettling, Fred)
Date: Fri, 19 Sep 2008 07:04:12 -0400
Subject: [arin-ppml] "IPv6 and the Business-Case Skeptics" (slashdot)
In-Reply-To: <42672.1221690782@nsa.vix.com>
References: <42672.1221690782@nsa.vix.com>
Message-ID: <ECA7FFB78E3F5B4DAF449A82CAE3896D0145EC07@fres0099.amers.ibechtel.com>

Suggest that you take a take look at the source Network World chat that
prompted the Slashdot article.

Title: Experts make a solid business case for IPv6

Link:
http://www.networkworld.com/chat/archive/2008/091108-ipv6-strategies-chat.ht
ml

 

Regards - Fred 

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Paul Vixie
Sent: Thursday, September 18, 2008 11:03 AM
To: mcr at simtone.net



>   "satisfied with all of its Internet services"  <--this might be empty.
:-).

>   I guess that also means, "has no plans for expansion"

 

it's the wrong rubrik.  folks happy with ipv4 will need to run dual stack in
order to reach the people who will come later on and not be able to get
enough ipv4 or won't want to pay for it or are, for whatever reason, not
satisfied with THEIR ipv4-only internet services.

 

so expansion is a barbell.  you can run out of ipv4, or other people can,
and either way you've got to run dual-stack as soon as economically
possible, and the economics are actually quite favourable (i.e., it's kinda
cheap.) _______________________________________________

 

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Paul Vixie
Sent: Wednesday, September 17, 2008 6:33 PM
To: ppml at arin.net
Subject: [arin-ppml] "IPv6 and the Business-Case Skeptics" (slashdot)

 

"Experts keep screaming that the IPv4 sky is falling. Three such experts
were recently asked point-blank to state an irrefutable business case for
moving to IPv6 now, and their answer was more plausible than the old refrain
(the lack of addresses and a yet-to-be-seen killer IPv6 app). They said that
there isn't a business case. No company that is satisfied with all of its
Internet services will need to move, even in the next few years. They also
pointed out that Microsoft is a unique position in the industry both causing
and hindering adoption IPv6 causing through its IPv6 support in its OSes,
and hindering by not extending IPv6 support into very many of its apps."

 

http://tech.slashdot.org/article.pl?sid=08/09/16/1828231

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080919/7f06055d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6040 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080919/7f06055d/attachment.bin>

From michael.dillon at bt.com  Fri Sep 19 08:49:04 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 19 Sep 2008 13:49:04 +0100
Subject: [arin-ppml] Policy Proposal 2008-2:IPv4Transfer	Policy	Proposal
	-Revised
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B15@mail>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC082332D2@E03MVZ2-UKDY.domain1.systemhost.net>

> The answer is just to state that "physical addresses for all 
> registrant parties for all registrations, requests and/or 
> transfers must be in the 'ARIN Service Area' " then define 
> the ARIN service area..  

That is not the intent.

The intent is for the policy to only enable transfer of blocks
for which ARIN is RESPONSIBLE, i.e. blocks which the IANA allocated
to ARIN or which were transferred to ARIN under the ERX process.
This has nothing to do with where the addresses are used or where
the organization is located.

Some global networks get all their addresses from one registry.
Other global networks get addresses from all 5 registries depending
on which continent their network infrastructure is located. Both
kinds of networks are doing the right thing.

--Michael Dillon




From owen at delong.com  Fri Sep 19 12:23:41 2008
From: owen at delong.com (Owen DeLong)
Date: Fri, 19 Sep 2008 09:23:41 -0700
Subject: [arin-ppml] Policy Proposal 2008-2:IPv4Transfer	Policy	Proposal
	-Revised
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC082332D2@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC082332D2@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <13A9E96C-BA8A-4922-887D-C3E5F2A8C6D2@delong.com>


On Sep 19, 2008, at 5:49 AM, <michael.dillon at bt.com> wrote:

>> The answer is just to state that "physical addresses for all
>> registrant parties for all registrations, requests and/or
>> transfers must be in the 'ARIN Service Area' " then define
>> the ARIN service area..
>
> That is not the intent.
>
> The intent is for the policy to only enable transfer of blocks
> for which ARIN is RESPONSIBLE, i.e. blocks which the IANA allocated
> to ARIN or which were transferred to ARIN under the ERX process.
> This has nothing to do with where the addresses are used or where
> the organization is located.
>
> Some global networks get all their addresses from one registry.
> Other global networks get addresses from all 5 registries depending
> on which continent their network infrastructure is located. Both
> kinds of networks are doing the right thing.

The intent does, however, include the desire to exclude organizations
which have no operations within the ARIN service region from being
transferees just as they are ineligible to receive resources from ARIN
today.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080919/fb789695/attachment.p7s>

From info at arin.net  Fri Sep 19 13:59:09 2008
From: info at arin.net (Member Services)
Date: Fri, 19 Sep 2008 13:59:09 -0400
Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup - Revised
Message-ID: <48D3E86D.1020003@arin.net>

The author submitted a revised version of their proposal.

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

      1. Accept the proposal as written. If the AC accepts the proposal,
it will be posted as a formal policy proposal to PPML and it will be
presented at a Public Policy Meeting.

      2. Postpone their decision regarding the proposal until the next
regularly scheduled AC meeting in order to work with the author. The AC
will work with the author to clarify, combine or divide the proposal. At
their following meeting the AC will accept or not accept the proposal.

      3. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision via the PPML. If a proposal is not
accepted, then the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

In the meantime, the AC invites everyone to comment on this proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: whois POC e-mail cleanup

Author: Ted Mittelstaedt

Proposal Version: 2

Submission Date: 9/19/2008

Proposal type: new

Policy term: permanent

Policy statement:

Under Directory Services in the NRPM

add section 3.6 titled "Reliability of Whois information"

3.6.1  ARIN will use an automated system that once a year will attempt
to e-mail all separate e-mail  addresses in the directory. (including
abuse addresses)  At it's discretion, ARIN will attempt to  contact by
regular mail or phone any POC entries that have invalid e-mail addresses
(i.e. e-mail  addresses that bounce mail sent to them) and give them a 3
month deadline for correction of their mail  address.  The automated
system will not use a mail cluster or other mail transmission software
that is incompatible with commonly available anti-spam technologies,
such as greylisting.

ALL POC's that fail to respond to paper mails or telephone calls after
the deadline will have their e-mail address replaced with "FAILED TO
RESPOND, PRIOR ADDRESS: <previous e-mail address>" in the directory.

The automated e-mails will have a text string titled "ARIN Automated POC
e-mail test" identifying them  so that automated trouble ticket systems
can be programmed to automatically delete the mail messages  instead of
replying to them.

3.6.2  ARIN will supply a report to the community, updated monthly, that
lists the percentage of  "FAILED TO RESPOND" POCs, the percentage of
POCs that accept e-mails, and the percentage of POC  addresses that have
a response pending.

Rationale:

As the entire Internet community gets closer to the date that IPv4 will
be exhausted, more attention is being focused on the possibility that
there is significant amounts of allocated IPv4 that is abandoned.  There
are also concerns that as the amount of usable IPv4 space gets more and
more crowded, that Internet criminals are turning to abandoned IPv4
space that is still listed as allocated  in the whois directories to use
to make attacks on hosts on the Internet.  Because of these reasons,  it
is becoming more important that users of ARIN's whois data have a
reasonable expectation that it is  accurate. The current NRPM has a
mechanism for adding, modifying, and deleting POCs. However it also
carries an assumption that POCs belonging to defunct companies will be
removed when the bills for allocated IP addressing cease being paid, and
the address resources are then returned to the ARIN pool  as a result.
The problem is that this assumption does not hold true for so-called
"Legacy" IP address holders since they do not pay a yearly fee.
Furthermore, billing for the IP addressing allocations is done through
paper mail, thus it is possible for a POC to have a valid street
address, but an invalid E-mail address, and not be caught because they
are current on their account.  This is becoming a serious issue because
contacting a POC via a street address is too slow for victims of an
attack from a hijacked IP block to be able to complain to the block
owners and the block owners to be able to catch the perpetrators.

This proposal is a "first step" proposal to attack the problem of
invalid e-mail addresses in the WHOIS database.  It is specifically
intended to be an automated mechanism.  It is understood that IP address
hijackers could hijack a legacy block and setup a mailserver to respond
to a POC address on the block and thus dodge this system. (assuming the
domain name used in the defunct POC e-mail address was available, which
is not likely)  Detecting such a setup is going to require more advanced
mechanisms than are appropriate to be spelled out in a policy manual,
and this proposal in no way precludes such mechanisms from being
employed.  Fundamentally, ARIN cannot guarantee the validity of WHOIS
entries in the directory that belong to legacy holders who have not
signed an LRSA, there's some legal challenges to proving that a legacy
holder who is masquerading as a defunct organization is in fact a hijacker.

This proposal SPECIFICALLY DOES NOT require a POC to make a response.
All that is needed is for the POC e-mail address to be accepting mail.
The difficulties in dealing with the large number of responses back,
plus the fact that it's likely that many responses back will be sent
from e-mail addresses other than what is listed in the POC, would make
requiring ARIN to get a response back to determine legitimacy to greatly
increase the complexity of this proposal and make it likely to be
unworkable.

The report of FAILED TO RESPOND POCS needs to be monthly because there
is NO REQUIREMENT that ARIN contact ALL POCS in the database ON THE SAME
DATE.  It is assumed that ARIN would e-mail only 1/12'th of all POC's in
the database at the beginning of every month to spread out the workload.

There is a mechanism already defined in the NRPM to get a bulk dump of
the whois database, which would of course contain the FAILED TO RESPOND
entries.

Timetable for implementation: Immediate




From nigel.cassimire at ctu.int  Fri Sep 19 14:42:32 2008
From: nigel.cassimire at ctu.int (Nigel Cassimire)
Date: Fri, 19 Sep 2008 14:42:32 -0400
Subject: [arin-ppml] ARIN Policy Proposal 2008:4 Minimum Allocation in
	theCaribbean Region
In-Reply-To: <005501c919d6$4e95b6a0$ebc123e0$@samuels@uwimona.edu.jm>
Message-ID: <20080919190503.230CCA69C3@smtp2.arin.net>

I support policy proposal 2008-4 since it lowers the barrier to entry for
the small Caribbean markets and would tend to facilitate the achievement of
effective competition.

 

Nigel Cassimire

Telecommunications Specialist (Consultant)

 

Caribbean Telecommunications Union (CTU)

  _____  

From: Carlton Samuels [mailto:carlton.samuels at uwimona.edu.jm] 
Sent: Thursday, September 18, 2008 5:34 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] ARIN Policy Proposal 2008:4 Minimum Allocation in
theCaribbean Region

 

This policy proposal posits a minimum allocation of IPv4 for Caribbean ISPs
in the ARIN region to be /22. We wish to record our emphatic support for
this policy as written.   More details may be seen at
http://www.arin.net/policy/proposals/2008_4.html .

 

The facts as we know them are not controversial: Caribbean ISPs and
enterprises are smaller scale than the typical North American entities.  And
while most number resources are indirectly assigned, there are even a few
enterprise operations with number resources directly assigned from ARIN.
This policy levels the playing field and lower the barrier to Caribbean
entities receiving the services that ARIN has to offer. 

 

Even though ARIN has been engaged in outreach work in the region, the role
of the Regional Internet Registry (RIR) in [IP] number resource management
remains largely unknown. So policies that impact us directly do not get as
wide a participation and/or acclamation that they deserve. I am especially
encouraging our IEEE colleagues to participate in the ARIN Public Policy
discussions by joining the public policy list.  I also commend their
endorsement of this policy.

 

Carlton A Samuels

The University of the West Indies at Mona

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080919/7fe11ac0/attachment.htm>

From cliffb at cjbsys.bdb.com  Wed Sep 24 10:40:03 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Wed, 24 Sep 2008 10:40:03 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
Message-ID: <48DA5143.7080702@cjbsys.bdb.com>

I haven't seen this discussed in a while and I still see the "no fall 
back to status quo" as a problem.  I think if ARIN would change the 
"terminate for convenience" by the legacy holder so that the address 
space would revert back whatever the status is at that time for those 
who didn't sign the LRSA.

My thinking is as follows.  ARIN is trying to get Legacy address holders 
to sign an LRSA.  Many have indicated a willingness to do so under 
certain conditions.  It appears that one of the major stumbling blocks 
for many Legacy holders is being able to "drop out" at a later time for 
unspecified reasons.

Let's look at what happens if that were allowed.  Far more legacies 
appear to be willing to sign and ARIN would have accomplished what it 
wanted to do.  Assume at some time in the future, some of the legacy 
holders wanted to terminate "for convenience". If at that time, they are 
allowed to drop back to whatever services ARIN provides to non-signing 
legacy holders, it would be as if they never signed. If ARIN has at that 
time stopped providing any services to non-signers, they are in deep 
doo-doo and they will probably not terminate for convenience.  If ARIN 
is providing at that time what they provide now in terms of services, 
ARIN will have had at least some time of membership and updated 
records.  Better than having never signed.

If fewer legacy holders sign up because of the more restrictive clauses, 
ARIN will have lost funds and better contact information and they will 
be in a worse position than the scernario above.
 
If in the first scenario, ARIN does a good job of stewardship, I can't 
believe any who signed the LRSA would want to drop out and ARIN is in a 
better position to recover truly abandoned IPv4.
 
I think most legacy people feel they should not end up worse off than 
the non-signers if they do sign and I think that one clause makes them 
feel that way.  If you want, think of it as a "no fault divorce" where 
each party leaves with what they came in with.
 
Cliff


From tedm at ipinc.net  Wed Sep 24 12:51:48 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 24 Sep 2008 09:51:48 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48DA5143.7080702@cjbsys.bdb.com>
Message-ID: <D516F33C8C9C425AB083802B05222015@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Cliff Bedore
> Sent: Wednesday, September 24, 2008 7:40 AM
> To: PPML
> Subject: Re: [arin-ppml] ARIN releases new version of the 
> Legacy Registration
> 
> 
> I haven't seen this discussed in a while and I still see the "no fall 
> back to status quo" as a problem.  I think if ARIN would change the 
> "terminate for convenience" by the legacy holder so that the address 
> space would revert back whatever the status is at that time for those 
> who didn't sign the LRSA.
> 

The problem is that the legacy space HAS NO STATUS at the current time.

You are essentially asking for a LSRA that would change the status of
the legacy space, even if later on the agreement was terminated.

Right now it's "undefined"  You want a terminated agreement to change
it to "officially assigned"

> My thinking is as follows.  ARIN is trying to get Legacy 
> address holders 
> to sign an LRSA.  Many have indicated a willingness to do so under 
> certain conditions.  It appears that one of the major 
> stumbling blocks 
> for many Legacy holders is being able to "drop out" at a 
> later time for 
> unspecified reasons.
> 
> Let's look at what happens if that were allowed.  Far more legacies 
> appear to be willing to sign and ARIN would have accomplished what it 
> wanted to do.  Assume at some time in the future, some of the legacy 
> holders wanted to terminate "for convenience". If at that 
> time, they are 
> allowed to drop back to whatever services ARIN provides to 
> non-signing 
> legacy holders, it would be as if they never signed. If ARIN 
> has at that 
> time stopped providing any services to non-signers, they are in deep 
> doo-doo and they will probably not terminate for convenience. 

No, they would just complain that the agreement's "reversion clause"
implied that "things would go back to the way they were" and thus
ARIN would be obligated to continue providing services to them.

>  If ARIN 
> is providing at that time what they provide now in terms of services, 
> ARIN will have had at least some time of membership and updated 
> records.  Better than having never signed.
> 
> If fewer legacy holders sign up because of the more 
> restrictive clauses, 
> ARIN will have lost funds and better contact information and 
> they will 
> be in a worse position than the scernario above.
>  

ARIN gets hardly any funds at all if a LSRA is signed.

> If in the first scenario, ARIN does a good job of 
> stewardship, I can't 
> believe any who signed the LRSA would want to drop out and 
> ARIN is in a 
> better position to recover truly abandoned IPv4.
>  
> I think most legacy people feel they should not end up worse off than 
> the non-signers if they do sign

I agree.  However, MANY people who HAVE signed the LSRA do NOT feel that
they are worse off - yet they were once legacy people.

How do you reconcile that Joe Blow who signed feels better off than
Sally Schmoe who didn't sign the same document because she
feels it makes her worse off?  It's the same dang document!!!

It's a matter of interpretation.  When people like you make statements
like:

"...legacy people feel they should not end up worse off than 
 the non-signers if they do sign..."

you are simply perpetuating a falsehood that somehow, signing the LSRA
makes a legacy holder worse off than they are now.

> and I think that one clause 
> makes them 
> feel that way.  If you want, think of it as a "no fault 
> divorce" where 
> each party leaves with what they came in with.
>

This is a false analogy.  An accurate analogy would be is if right now,
ARIN were to STOP providing whois for legacy holders who hadn't signed,
and give them to option of getting something - continued whois services -
by signing.

The legacy holders would then be "getting" something - whois - out of the
agreement, just as 2 single people are "getting" something - financial
and social security - out of the marriage agreement.

If a divorce happens then the married couple are "losing" something - the
marriage, just as an opt-out clause in a LSRA would have the legacy holder
"lose" something - whois.

But right now the legacy holders are ALREADY getting whois.  Just as 2 
unmarried singles are "getting something" when they live together.
Thus, the difficulty of getting legacy holders to sign the LSRA is no
different than the difficulty of getting unmarried singles living together
to sign the marriage document.

Both of them are already getting what they want out of the relationship,
- so why sign?  Sex or whois - it's the same thing in this analogy. ;-)

Ted



From info at arin.net  Wed Sep 24 13:38:00 2008
From: info at arin.net (Member Services)
Date: Wed, 24 Sep 2008 13:38:00 -0400
Subject: [arin-ppml] NRPM version 2008.4 - New Policy Implementation
Message-ID: <48DA7AF8.1080301@arin.net>

On 11 August 2008 the ARIN Board of Trustees, acting on the
recommendation of the Advisory Council and noting that the Internet
Resource  Policy Evaluation Process had been followed, adopted the
following policy  proposal:

    * Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation

On 31 July 2008 the ICANN Board ratified the following global policy
proposal:

    * Policy Proposal 2007-19: IANA Policy for Allocation of ASN Blocks
      to RIRs

These policies have been incorporated into version 2008.4 of the ARIN
Number Resource Policy Manual (NRPM). NRPM version 2008.4 is effective
24 September 2008 and supersedes previous versions. See Appendix A of
the NRPM for information regarding changes to the manual.

The NRPM can be found at:

  http://www.arin.net/policy/nrpm.html

Appendix A can be found at:

  http://www.arin.net/policy/nrpm_changelog.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From cliffb at cjbsys.bdb.com  Wed Sep 24 14:05:21 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Wed, 24 Sep 2008 14:05:21 -0400 (EDT)
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <D516F33C8C9C425AB083802B05222015@tedsdesk> from "Ted
	Mittelstaedt" at Sep 24, 2008 09:51:48 AM
Message-ID: <200809241805.m8OI5LNm019306@cjbsys.bdb.com>

> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Cliff Bedore
> > Sent: Wednesday, September 24, 2008 7:40 AM
> > To: PPML
> > Subject: Re: [arin-ppml] ARIN releases new version of the 
> > Legacy Registration
> > 
> > 
> > I haven't seen this discussed in a while and I still see the "no fall 
> > back to status quo" as a problem.  I think if ARIN would change the 
> > "terminate for convenience" by the legacy holder so that the address 
> > space would revert back whatever the status is at that time for those 
> > who didn't sign the LRSA.
> > 
> 
> The problem is that the legacy space HAS NO STATUS at the current time.
> 
> You are essentially asking for a LSRA that would change the status of
> the legacy space, even if later on the agreement was terminated.
> 
> Right now it's "undefined"  You want a terminated agreement to change
> it to "officially assigned"

Actually what I said was it would go back to the status of the non-signers of
the LRSA.  If that is considered undefined, that's what it would go back to.
I tend to think the status is maybe "special circumstances"  Those who use
their space and have up to date info are being served by ARIN.  You can lookup
192.68.145.0 and I'm in the database and ARIN says as of now they don't plan
to change that if I don't sign. As per the LRSA page at ARIN

"Note that ARIN will not reclaim unutilized address space from legacy holders
who sign this RSA, nor will ARIN attempt to take away legacy resources from
organizations who choose not to sign it. However, signing the Legacy RSA
contractually locks in a set of rights, and thus reduces the risk of future
change to a minimum."

Cliff

> 
> > My thinking is as follows.  ARIN is trying to get Legacy 
> > address holders 
> > to sign an LRSA.  Many have indicated a willingness to do so under 
> > certain conditions.  It appears that one of the major 
> > stumbling blocks 
> > for many Legacy holders is being able to "drop out" at a 
> > later time for 
> > unspecified reasons.
> > 
> > Let's look at what happens if that were allowed.  Far more legacies 
> > appear to be willing to sign and ARIN would have accomplished what it 
> > wanted to do.  Assume at some time in the future, some of the legacy 
> > holders wanted to terminate "for convenience". If at that 
> > time, they are 
> > allowed to drop back to whatever services ARIN provides to 
> > non-signing 
> > legacy holders, it would be as if they never signed. If ARIN 
> > has at that 
> > time stopped providing any services to non-signers, they are in deep 
> > doo-doo and they will probably not terminate for convenience. 
> 
> No, they would just complain that the agreement's "reversion clause"
> implied that "things would go back to the way they were" and thus
> ARIN would be obligated to continue providing services to them.
> 
> >  If ARIN 
> > is providing at that time what they provide now in terms of services, 
> > ARIN will have had at least some time of membership and updated 
> > records.  Better than having never signed.
> > 
> > If fewer legacy holders sign up because of the more 
> > restrictive clauses, 
> > ARIN will have lost funds and better contact information and 
> > they will 
> > be in a worse position than the scernario above.
> >  
> 
> ARIN gets hardly any funds at all if a LSRA is signed.
> 
> > If in the first scenario, ARIN does a good job of 
> > stewardship, I can't 
> > believe any who signed the LRSA would want to drop out and 
> > ARIN is in a 
> > better position to recover truly abandoned IPv4.
> >  
> > I think most legacy people feel they should not end up worse off than 
> > the non-signers if they do sign
> 
> I agree.  However, MANY people who HAVE signed the LSRA do NOT feel that
> they are worse off - yet they were once legacy people.
> 
> How do you reconcile that Joe Blow who signed feels better off than
> Sally Schmoe who didn't sign the same document because she
> feels it makes her worse off?  It's the same dang document!!!
> 
> It's a matter of interpretation.  When people like you make statements
> like:
> 
> "...legacy people feel they should not end up worse off than 
>  the non-signers if they do sign..."
> 
> you are simply perpetuating a falsehood that somehow, signing the LSRA
> makes a legacy holder worse off than they are now.
> 
> > and I think that one clause 
> > makes them 
> > feel that way.  If you want, think of it as a "no fault 
> > divorce" where 
> > each party leaves with what they came in with.
> >
> 
> This is a false analogy.  An accurate analogy would be is if right now,
> ARIN were to STOP providing whois for legacy holders who hadn't signed,
> and give them to option of getting something - continued whois services -
> by signing.
> 
> The legacy holders would then be "getting" something - whois - out of the
> agreement, just as 2 single people are "getting" something - financial
> and social security - out of the marriage agreement.
> 
> If a divorce happens then the married couple are "losing" something - the
> marriage, just as an opt-out clause in a LSRA would have the legacy holder
> "lose" something - whois.
> 
> But right now the legacy holders are ALREADY getting whois.  Just as 2 
> unmarried singles are "getting something" when they live together.
> Thus, the difficulty of getting legacy holders to sign the LSRA is no
> different than the difficulty of getting unmarried singles living together
> to sign the marriage document.
> 
> Both of them are already getting what they want out of the relationship,
> - so why sign?  Sex or whois - it's the same thing in this analogy. ;-)
> 
> Ted
> 


-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20740
cliffb at cjbsys.bdb.com http://www.bdb.com
Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/


From owen at delong.com  Wed Sep 24 14:23:44 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 24 Sep 2008 11:23:44 -0700
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <200809241805.m8OI5LNm019306@cjbsys.bdb.com>
References: <200809241805.m8OI5LNm019306@cjbsys.bdb.com>
Message-ID: <12D8B573-D405-446C-A0C6-0D913F5DBF4E@delong.com>

> Actually what I said was it would go back to the status of the non- 
> signers of
> the LRSA.  If that is considered undefined, that's what it would go  
> back to.
> I tend to think the status is maybe "special circumstances"  Those  
> who use
> their space and have up to date info are being served by ARIN.  You  
> can lookup
> 192.68.145.0 and I'm in the database and ARIN says as of now they  
> don't plan
> to change that if I don't sign. As per the LRSA page at ARIN
>
That status is undefined.  While ARIN currently (and likely will  
continue) provides
these services to legacy holders for free, it is unclear if ARIN has  
any continuing
obligation to do so. It is my understanding that a valid contract must  
contain
defined provisions for what happens at termination.  A return to an  
undefined
state does not appear to be plausible in a valid contract.

How would you define the "special status" without turning it into a  
continuing
single-sided obligation on ARIN?  Once services are covered by a  
contract,
termination of the contract generally is expected to lead to  
termination of
the services.  In the meantime, you happen to be getting services  
without
a contract, but, nothing guarantees that those services will be  
continued
without a contract. Nothing says they won't.

The question is, would you like to have a defined contract for  
services or would
you prefer to continue gambling on continuing to receive services  
without
a contract.

As of now, ARIN doesn't plan to change that. If it's up to me, it  
won't change.
That doesn't mean it CAN'T change.  The LRSA means it can't change so
long as you continue to maintain your obligations under the contract.

> "Note that ARIN will not reclaim unutilized address space from  
> legacy holders
> who sign this RSA, nor will ARIN attempt to take away legacy  
> resources from
> organizations who choose not to sign it. However, signing the Legacy  
> RSA
> contractually locks in a set of rights, and thus reduces the risk of  
> future
> change to a minimum."
>
Right... There is no current ARIN policy or intent to take legacy  
resources
from organizations who choose not to sign it. There's also nothing which
guarantees that status in perpetuity. I wouldn't support such a  
change, but,
the reality is that if a sufficient portion of the membership does, it  
would
be virtually impossible to prevent such a change.

Owen

> Cliff
>
>>
>>> My thinking is as follows.  ARIN is trying to get Legacy
>>> address holders
>>> to sign an LRSA.  Many have indicated a willingness to do so under
>>> certain conditions.  It appears that one of the major
>>> stumbling blocks
>>> for many Legacy holders is being able to "drop out" at a
>>> later time for
>>> unspecified reasons.
>>>
>>> Let's look at what happens if that were allowed.  Far more legacies
>>> appear to be willing to sign and ARIN would have accomplished what  
>>> it
>>> wanted to do.  Assume at some time in the future, some of the legacy
>>> holders wanted to terminate "for convenience". If at that
>>> time, they are
>>> allowed to drop back to whatever services ARIN provides to
>>> non-signing
>>> legacy holders, it would be as if they never signed. If ARIN
>>> has at that
>>> time stopped providing any services to non-signers, they are in deep
>>> doo-doo and they will probably not terminate for convenience.
>>
>> No, they would just complain that the agreement's "reversion clause"
>> implied that "things would go back to the way they were" and thus
>> ARIN would be obligated to continue providing services to them.
>>
>>> If ARIN
>>> is providing at that time what they provide now in terms of  
>>> services,
>>> ARIN will have had at least some time of membership and updated
>>> records.  Better than having never signed.
>>>
>>> If fewer legacy holders sign up because of the more
>>> restrictive clauses,
>>> ARIN will have lost funds and better contact information and
>>> they will
>>> be in a worse position than the scernario above.
>>>
>>
>> ARIN gets hardly any funds at all if a LSRA is signed.
>>
>>> If in the first scenario, ARIN does a good job of
>>> stewardship, I can't
>>> believe any who signed the LRSA would want to drop out and
>>> ARIN is in a
>>> better position to recover truly abandoned IPv4.
>>>
>>> I think most legacy people feel they should not end up worse off  
>>> than
>>> the non-signers if they do sign
>>
>> I agree.  However, MANY people who HAVE signed the LSRA do NOT feel  
>> that
>> they are worse off - yet they were once legacy people.
>>
>> How do you reconcile that Joe Blow who signed feels better off than
>> Sally Schmoe who didn't sign the same document because she
>> feels it makes her worse off?  It's the same dang document!!!
>>
>> It's a matter of interpretation.  When people like you make  
>> statements
>> like:
>>
>> "...legacy people feel they should not end up worse off than
>> the non-signers if they do sign..."
>>
>> you are simply perpetuating a falsehood that somehow, signing the  
>> LSRA
>> makes a legacy holder worse off than they are now.
>>
>>> and I think that one clause
>>> makes them
>>> feel that way.  If you want, think of it as a "no fault
>>> divorce" where
>>> each party leaves with what they came in with.
>>>
>>
>> This is a false analogy.  An accurate analogy would be is if right  
>> now,
>> ARIN were to STOP providing whois for legacy holders who hadn't  
>> signed,
>> and give them to option of getting something - continued whois  
>> services -
>> by signing.
>>
>> The legacy holders would then be "getting" something - whois - out  
>> of the
>> agreement, just as 2 single people are "getting" something -  
>> financial
>> and social security - out of the marriage agreement.
>>
>> If a divorce happens then the married couple are "losing" something  
>> - the
>> marriage, just as an opt-out clause in a LSRA would have the legacy  
>> holder
>> "lose" something - whois.
>>
>> But right now the legacy holders are ALREADY getting whois.  Just  
>> as 2
>> unmarried singles are "getting something" when they live together.
>> Thus, the difficulty of getting legacy holders to sign the LSRA is no
>> different than the difficulty of getting unmarried singles living  
>> together
>> to sign the marriage document.
>>
>> Both of them are already getting what they want out of the  
>> relationship,
>> - so why sign?  Sex or whois - it's the same thing in this  
>> analogy. ;-)
>>
>> Ted
>>
>
>
> -- 
> Cliff Bedore
> 7403 Radcliffe Dr. College Park MD 20740
> cliffb at cjbsys.bdb.com http://www.bdb.com
> Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080924/e0cfe822/attachment.p7s>

From stephen at sprunk.org  Wed Sep 24 19:23:37 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 24 Sep 2008 18:23:37 -0500
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <12D8B573-D405-446C-A0C6-0D913F5DBF4E@delong.com>
References: <200809241805.m8OI5LNm019306@cjbsys.bdb.com>
	<12D8B573-D405-446C-A0C6-0D913F5DBF4E@delong.com>
Message-ID: <48DACBF9.8030509@sprunk.org>

Owen DeLong wrote:
>> Actually what I said was it would go back to the status of the 
>> non-signers of the LRSA.  If that is considered undefined, that's 
>> what it would go back to.  I tend to think the status is maybe 
>> "special circumstances"  Those who use their space and have up to 
>> date info are being served by ARIN.  You can lookup 192.68.145.0 and 
>> I'm in the database and ARIN says as of now they don't plan to change 
>> that if I don't sign. As per the LRSA page at ARIN
>>
> That status is undefined.  While ARIN currently (and likely will 
> continue) provides these services to legacy holders for free, it is 
> unclear if ARIN has any continuing obligation to do so. It is my 
> understanding that a valid contract must contain defined provisions 
> for what happens at termination.  A return to an undefined state does 
> not appear to be plausible in a valid contract.
>
> How would you define the "special status" without turning it into a 
> continuing single-sided obligation on ARIN?  Once services are covered 
> by a contract, termination of the contract generally is expected to 
> lead to termination of the services.  In the meantime, you happen to 
> be getting services without a contract, but, nothing guarantees that 
> those services will be continued without a contract. Nothing says they 
> won't.

I think LRSA 14(c) covers this with "the Legacy Agreement will be 
terminated and the Included Number Resources will resume the status they 
had prior to the Legacy Agreement."  I think what folks are asking for 
is that the same would apply for _any_ termination, not just a subset of 
them.  If that's what it takes for folks to sign it, fine.

However, I want to reiterate that, unless someone on the AC or BoT tells 
me otherwise, modifications to the LRSA are a matter for individuals to 
take up with ARIN's counsel and not on PPML.  PPML is for debating 
policy, not contracts.

S


From Lee.Howard at stanleyassociates.com  Thu Sep 25 10:32:08 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Thu, 25 Sep 2008 10:32:08 -0400
Subject: [arin-ppml] ARIN releases new version of the Legacy Registration
In-Reply-To: <48DACBF9.8030509@sprunk.org>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B6C4C2E@CL-S-EX-1.stanleyassociates.com>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stephen Sprunk
> Sent: Wednesday, September 24, 2008 7:24 PM
> To: Owen DeLong
> Cc: 'PPML'
> Subject: Re: [arin-ppml] ARIN releases new version of the 
> Legacy Registration
> 
> Owen DeLong wrote:
> >> Actually what I said was it would go back to the status of the 
> >> non-signers of the LRSA.  If that is considered undefined, that's 
> >> what it would go back to.  I tend to think the status is maybe 
> >> "special circumstances"  Those who use their space and have up to 
> >> date info are being served by ARIN.  You can lookup 
> 192.68.145.0 and 
> >> I'm in the database and ARIN says as of now they don't 
> plan to change 
> >> that if I don't sign. As per the LRSA page at ARIN
> >>
> > That status is undefined.  While ARIN currently (and likely will
> > continue) provides these services to legacy holders for free, it is 
> > unclear if ARIN has any continuing obligation to do so. It is my 
> > understanding that a valid contract must contain defined provisions 
> > for what happens at termination.  A return to an undefined 
> state does 
> > not appear to be plausible in a valid contract.
> >
> > How would you define the "special status" without turning it into a 
> > continuing single-sided obligation on ARIN?  Once services 
> are covered 
> > by a contract, termination of the contract generally is expected to 
> > lead to termination of the services.  In the meantime, you 
> happen to 
> > be getting services without a contract, but, nothing 
> guarantees that 
> > those services will be continued without a contract. 
> Nothing says they 
> > won't.
> 
> I think LRSA 14(c) covers this with "the Legacy Agreement 
> will be terminated and the Included Number Resources will 
> resume the status they had prior to the Legacy Agreement."  I 
> think what folks are asking for is that the same would apply 
> for _any_ termination, not just a subset of them.  If that's 
> what it takes for folks to sign it, fine.
> 
> However, I want to reiterate that, unless someone on the AC 
> or BoT tells me otherwise, modifications to the LRSA are a 
> matter for individuals to take up with ARIN's counsel and not 
> on PPML.  PPML is for debating policy, not contracts.

What follows are my own opinions, which may not necessarily
reflect how I vote as a community representative or a 
fiduciary of ARIN, and certainly couldn't reflect the opinion 
of ARIN staff, Board, AC, or counsel, since they haven't made 
their opinions known to me.

In general, I agree with you.
However, there is a policy area around, "What are the
rights of legacy assignees, and what are ARIN's obligations
to them?"  Debating the contract terms in specific should be
out of scope, but debating the general framework is well
within the public policy arena.  IMHO.

Cliff makes an excellent argument, that if a legacy signer 
later drops out, both parties are no worse off than they 
are now.  However, since that may not always be the case 
(for either ARIN, or the legacy signer, or both), and the 
whole point of the LRSA is to "normalize" the relationship, 
I still believe that once an organization is committed to
participating, their commitment should be binding, except
where they are compelled (for "cause" as defined in the
contract) to withdraw.  

People on this list made excellent, clear, and fair
suggestions about how to rework the LRSA, and ARIN listened
and modified it significantly.  The only suggestion that
was not accepted, from what I've seen, is that Legacy 
holders-signers be able to take their football and
go home in a snit.  If ARIN does something wrong ("cause")
you can justifiably have a snit and go home.  Otherwise, I
think everyone should be in the same boat.  Playing football.
It's a big boat.

Get on board!

Lee


PS: It doesn't matter whether the "football" is American or
what the rest of the world plays, the metaphor works 
equally poorly.



From info at arin.net  Thu Sep 25 11:57:41 2008
From: info at arin.net (Member Services)
Date: Thu, 25 Sep 2008 11:57:41 -0400
Subject: [arin-ppml] ARIN XXII Open Policy Hour
Message-ID: <48DBB4F5.4010005@arin.net>

Sign up today to present your ideas at the ARIN XXII Open Policy Hour, 
Tuesday, 14 October, from 6:00-7:00 PM (PDT).

The Open Policy Hour (OPH) is a showcase for your policy ideas. If you 
have a policy proposal you'd like to debut, prior to formally submitting 
it, here is your opportunity. Sign up by Friday, 10 October to ensure 
your chance to take the microphone. Send an e-mail to policy at arin.net 
with your name, organization, and a general description of the policy 
subject you wish to present. Everyone is invited to attend the session 
and raise ideas and suggestions. You do not need to have a formal 
presentation in order to participate. Signing up in advance allows us to 
confirm your turn to present your policy idea.

Information on this and other sessions is available at:
http://www.arin.net/ARIN-XXII/agenda.html

We are in the process of upgrading our remote participation options.  
These new features will be available during the Open Policy Hour.  Be on 
the lookout for more details on how you can join in the discussion even 
if you can't be with us in Los Angeles.

We look forward to your participation in ARIN XXII. Meeting details are 
available at http://www.arin.net/ARIN-XXII/.

Please contact Member Services at info at arin.net if you have any questions.

Regards,

Member Services Department
American Registry for Internet Numbers (ARIN)





From chris.misztur at yahoo.com  Sat Sep 27 19:52:47 2008
From: chris.misztur at yahoo.com (chris mr)
Date: Sat, 27 Sep 2008 16:52:47 -0700 (PDT)
Subject: [arin-ppml] Policy Manual : Customer Privacy
Message-ID: <287016.79102.qm@web63702.mail.re1.yahoo.com>

Hello,

Reference: http://www.arin.net/policy/nrpm.html#four2376

I have recently noticed that ISPs such as ATT(SIS-80) and Comcast(CBCI) publish their customers' personal information in /29 reassignments.  For my residential DSL service I was told to contact ipadmin at att.com to hide my personal information, which they did.

What are your thoughts as to why ISPs do not protect their residential customers' privacy by default? 

My thought on this subject is that ISPs still have the belief that Internet service with static IP blocks is only required by businesses, therefore ISPs fail to make the distinction between personal and business Internet accounts.

Chris


      


From dogwallah at gmail.com  Sun Sep 28 00:18:22 2008
From: dogwallah at gmail.com (McTim)
Date: Sun, 28 Sep 2008 07:18:22 +0300
Subject: [arin-ppml] Policy Manual : Customer Privacy
In-Reply-To: <287016.79102.qm@web63702.mail.re1.yahoo.com>
References: <287016.79102.qm@web63702.mail.re1.yahoo.com>
Message-ID: <f65fb55e0809272118y2417e121t41928c0e1a5c7e74@mail.gmail.com>

Hi Chris,

On Sun, Sep 28, 2008 at 2:52 AM, chris mr <chris.misztur at yahoo.com> wrote:
> Hello,
>
> Reference: http://www.arin.net/policy/nrpm.html#four2376
>
> I have recently noticed that ISPs such as ATT(SIS-80) and Comcast(CBCI) publish their customers' personal information in /29 reassignments.  For my residential DSL service I was told to contact ipadmin at att.com to hide my personal information, which they did.
>
> What are your thoughts as to why ISPs do not protect their residential customers' privacy by default?

The operative word in the document you cite is "may", as in "an
organization with downstream residential customers may substitute that
organization's name for the customer's name"

In other words, they are not required to do this, but they can.

The IPv6 section of the same doc says:

"Internet address space must be registered in a registry database
accessible to appropriate members of the Internet community. This is
necessary to ensure the uniqueness of each Internet address and to
provide reference information for Internet troubleshooting at all
levels, ranging from all RIRs and IRs to end users.

The goal of registration should be applied within the context of
reasonable privacy considerations and applicable laws."

This applies to IPv4 addresses as well.

So it's a balance between providing POC info for IP space and privacy.

ISPs may find it easier to handle all the abuse/trouble tickets for
their customers, or they may prefer to pass on these duties to the
actual users of the space.  PPML allows them to do either.  This
flexibility is useful IMHO.

-- 
Cheers,

McTim
mctim.blogspot.com


From lear at cisco.com  Mon Sep 29 04:12:37 2008
From: lear at cisco.com (Eliot Lear)
Date: Mon, 29 Sep 2008 10:12:37 +0200
Subject: [arin-ppml] suggested change for ARIN 2008_2:
Message-ID: <48E08DF5.7060008@cisco.com>

Dear all,

The comments below stem from the analysis that Bill Lehr, Tom Vest, and 
I performed on ARIN 2008_2.  These comments, however, are my own.  Scott 
has requested of me that discussion occur on the PPML list.

Section 8.3.5 specifies that transferees must pre-qualify in order to 
receive an IP address block.  This includes satisfaction of need.  The 
rationale behind this requirement is to reduce speculation and provide 
for more immediate use on the Internet.  Section 8.3.6 specifies that 
ARIN may allow transferors to deaggregate blocks.  The inverse is more 
the intent, which is to keep routing tables from exploding.

The Problem:

1.  Section 8.3.6 is perhaps intentionally vague, so has to provide 
flexibility over the management of the market by ARIN staff.  However, 
the Rationale section of the proposal is more clear:  "To discourage 
unnecessarily rapid growth of routing tables, an allocation or 
assignment may not be arbitrarily deaggregated."  However, this 
proscription is not actually stated in the proposal.  This lack of 
clarity may lead to unnecessary litigation.

2.  Ignoring (1), the impact of Section 8.3.6 in combination with 
Section 8.3.5 is to avoid the circumstance where there is an excess of 
supply for large blocks, while demand for smaller blocks goes unmet.  
The intent is clearly good as it off sets a concentrative force.  
However, there are side effects to this policy as well.  Those holders 
of large blocks may be tempted to keep them off the market until supply 
for smaller blocks has dried up.  The only reason this would not occur 
is that the sellers may not have visibility to demand.  If sales remain 
private, visibility will be poor.  If sales end up on eBay, visibility 
will be high.

In fact it is unclear what visibility ARIN staff will have.  ARIN will 
see unsatisfied demand through the number of pre-qualified blocks 
outstanding.  But that's not the same as pricing information.  If blocks 
are moving but price skyrockets because the resource is viewed as 
essential, ARIN will not know to allow disaggregation.

3.  ARIN may have no visibility as to who is holding back blocks in 
order to disaggregate them.

4.  Similarly large block holders have no understanding as to when and 
how they can disaggregate their blocks.  As such, a buyers market will 
still exist for larger blocks.

Recommendations

ARIN having price visibility may provide a solution to both (2) and (3) 
above.  If buyers and sellers report purchase prices, then ARIN can see 
when the price per address of large blocks drops below that of small 
blocks, and act accordingly.

Dealing with (4) is more difficult, and goes to seller expectations.  A 
policy that allows for some disaggregation at a controlled rate may 
alleviate problems, but this is sheer conjecture on my part.

Whatever is decided, 8.3.6 should be clarified to reflect that decision.

Other concerns

Please keep in mind that all of these recommendations presume that ARIN 
has sufficient regulatory authority and capability to manage such 
controls.  A reasonable question to ask is whether all of these controls 
contravene a more important goal of knowing who is actually using the 
block, by encouraging people to skirt the rules.  APNIC's prop-50 
clearly is written with this concern in mind.

Eliot Lear








From BillD at cait.wustl.edu  Mon Sep 29 11:00:47 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 29 Sep 2008 10:00:47 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030877ADB27@ex1.cait.wustl.edu>

As the Oct 15 ARIN Public Policy Meeting comes closer, I would like to
again ask anyone who has not commented (or sufficiently) on this policy
proposal to do so.  Especially, I am interested in what you think are
the positive or negative aspects of this proposal in contrast to 2008-2
the more elaborate and detailed proposal.

2008-6 was promulgated as an alternative to 2008-6 for those who believe
that 1./ a more liberal transfer policy is in the best interest of the
industry and, 2./ feel that it would be easier to pass it and then
modify it as needed in the future, should 2008-2 fail to gain consensus
across all of its nuance.

As always, I thank you for your involvement and insight into the policy
evaluation process of ARIN.  Your participation makes the role of the AC
much easier and the overall process more rigorous.

Bill Darte
ARIN Advisory Council



From kkargel at polartel.com  Mon Sep 29 11:17:48 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 29 Sep 2008 10:17:48 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877ADB27@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D030877ADB27@ex1.cait.wustl.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5A@mail>

I still believe that a transfer policy at all is a bad idea and do not
support any form. 


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte
> Sent: Monday, September 29, 2008 10:01 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for 
> IPv4 Addresses
> 
> As the Oct 15 ARIN Public Policy Meeting comes closer, I 
> would like to again ask anyone who has not commented (or 
> sufficiently) on this policy proposal to do so.  Especially, 
> I am interested in what you think are the positive or 
> negative aspects of this proposal in contrast to 2008-2 the 
> more elaborate and detailed proposal.
> 
> 2008-6 was promulgated as an alternative to 2008-6 for those 
> who believe that 1./ a more liberal transfer policy is in the 
> best interest of the industry and, 2./ feel that it would be 
> easier to pass it and then modify it as needed in the future, 
> should 2008-2 fail to gain consensus across all of its nuance.
> 
> As always, I thank you for your involvement and insight into 
> the policy evaluation process of ARIN.  Your participation 
> makes the role of the AC much easier and the overall process 
> more rigorous.
> 
> Bill Darte
> ARIN Advisory Council
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/7cc12c9f/attachment.bin>

From michael.dillon at bt.com  Mon Sep 29 12:00:20 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 29 Sep 2008 17:00:20 +0100
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5A@mail>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net>

> I still believe that a transfer policy at all is a bad idea 
> and do not support any form. 

And given the current problems with the world's financial markets,
I believe that this is the WRONG TIME for any RIRs to be considering
liberalization of address block transfers.

Market mechanisms are no longer trusted. It is becoming clear
that the complex derivatives being traded were a cover for massive
fraud. Since IP addresses are not property/assets, the only way
they can be traded is via derivatives.

Nobody on the BoT or the AC is qualified to make decisions regarding
markets, therefore ARIN should simply steer entirely clear of the
whole mess. Stick with what we know and what works. People who made
bad strategic decisions about deploying IPv6 in their networks may
be hurt, and they may complain loudly about this, but ARIN has no
duty to rescue such organizations from their bad decisionmaking.

IPv6 is there and ARIN has made sure that the registry is not a barrier
to deploying IPv6. That is sufficient.

--Michael Dillon


From tvest at pch.net  Mon Sep 29 12:23:25 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 29 Sep 2008 12:23:25 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <AABA16A9-257D-4F4A-A3F7-DE05E29F0D90@pch.net>


On Sep 29, 2008, at 12:00 PM, <michael.dillon at bt.com> wrote:

>> I still believe that a transfer policy at all is a bad idea
>> and do not support any form.
>
> And given the current problems with the world's financial markets,
> I believe that this is the WRONG TIME for any RIRs to be considering
> liberalization of address block transfers.
>
> Market mechanisms are no longer trusted. It is becoming clear
> that the complex derivatives being traded were a cover for massive
> fraud. Since IP addresses are not property/assets, the only way
> they can be traded is via derivatives.
>
> Nobody on the BoT or the AC is qualified to make decisions regarding
> markets, therefore ARIN should simply steer entirely clear of the
> whole mess. Stick with what we know and what works. People who made
> bad strategic decisions about deploying IPv6 in their networks may
> be hurt, and they may complain loudly about this, but ARIN has no
> duty to rescue such organizations from their bad decisionmaking.
>
> IPv6 is there and ARIN has made sure that the registry is not a  
> barrier
> to deploying IPv6. That is sufficient.


2008-5 will assure that ARIN does not, through commission *or*  
omission, create a barrier to deploying IPv6.

TV





From mueller at syr.edu  Mon Sep 29 12:31:40 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 29 Sep 2008 12:31:40 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net>
References: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5A@mail>
	<C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>



> It is becoming clear
> that the complex derivatives being traded were a cover for massive
> fraud. Since IP addresses are not property/assets, the only way
> they can be traded is via derivatives.

This is nonsense. Literally. IP address transfer markets are not
derivative markets, and anyone who asserts this is either ignorant of
the issue or attempting to exploit financial panic to achieve a
predetermined policy objective. Derivatives markets are based on options
and futures. IP address transfers as proposed by various RIR policy
changes directly transfer a valuable but intangible asset from one party
to another. There is no redistribution of risk. 

Let's keep in mind that transfers of IP addresses already happen. Are
you suggesting that they all be stopped? The only difference of a policy
change would be that we now allow money to be a consideration for the
addresses directly, rather than for the corporation as a whole. 



From dlw+arin at tellme.com  Mon Sep 29 12:39:03 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Mon, 29 Sep 2008 09:39:03 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net>
References: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5A@mail>
	<C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20080929163903.GW1271@shell02.cell.sv2.tellme.com>

On Mon, Sep 29, 2008 at 05:00:20PM +0100, michael.dillon at bt.com wrote:
> > I still believe that a transfer policy at all is a bad idea 
> > and do not support any form. 
> 
> And given the current problems with the world's financial markets,
> I believe that this is the WRONG TIME for any RIRs to be considering
> liberalization of address block transfers.

Do you really think this?  I don't see any connection between the
incredibly complex problem of the current financial market and a
trivially simple market to redistribute integers.  The time to make any
changes is now, given that we're almost out of this resource.  I don't
think we're in danger of running out of mortgages that can be bundled
and turned into securities anytime soon.

The differences in the two situations are gigantic.  I've deleted the
rest of your text to avoid the temptation to be even more incredulous.

For myself, I'm not sure that a transfer market run by ARIN is
necessarily a great idea.  If we want one, though, I think we need to take
steps to set it up now.

-David


From kkargel at polartel.com  Mon Sep 29 12:46:53 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 29 Sep 2008 11:46:53 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>
References: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5A@mail><C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net>
	<7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5D@mail>

Sales of heroin to schoolchildren already happen and there are rules against
it..  Are you saying that because it happens it should be legalized or
deregulated? 

"They are doing it anyway" is a sad old saw and doesn't justify the end..
If it did then we should legalize and regulate copyright piracy,
prostitution, slavery and any number of other things that are prohibited or
regulated for good reason but still happen.

There are policies and procedures in place to manage the allocation of IP
addresses.  Abandoning those policies to the end user is foolhardy.  

ARIN already does a great job of transferring address space from registrant
user to another when appropriate, and they work well with the registrant
users.  Adding a transfer policy will just muck up the works.

> Let's keep in mind that transfers of IP addresses already 
> happen. Are you suggesting that they all be stopped? The only 
> difference of a policy change would be that we now allow 
> money to be a consideration for the addresses directly, 
> rather than for the corporation as a whole. 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/4a21f8da/attachment.bin>

From pschopis at oar.net  Mon Sep 29 13:18:49 2008
From: pschopis at oar.net (Paul Schopis)
Date: Mon, 29 Sep 2008 13:18:49 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5D@mail>
References: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5A@mail><C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net>
	<7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B5D@mail>
Message-ID: <10BBA93B-E82F-406E-BBB8-D0F4A083FA4B@oar.net>

I agree with the views expressed by Kevin. I believe there could be  
unforeseen consequences if the policy is adopted. "If ain't broke  
don't fix it."

As to the opinion there is no correlation between the current  
financial mess and the proposal, while I agree it may not impact the  
economy in a major way, we are talking about relative value here, and  
that is precisely what the current mortgage crisis is about,. So I  
guess I get the analogy. We are always promised that it will "take  
care of itself" due to market forces. We were told that by Enron, The  
Savings and Loans, and now investment bankers.

ARIN has done a great job to date. Just my 2 cents worth.....


On Sep 29, 2008, at 12:46 PM, Kevin Kargel wrote:

> Sales of heroin to schoolchildren already happen and there are rules  
> against
> it..  Are you saying that because it happens it should be legalized or
> deregulated?
>
> "They are doing it anyway" is a sad old saw and doesn't justify the  
> end..
> If it did then we should legalize and regulate copyright piracy,
> prostitution, slavery and any number of other things that are  
> prohibited or
> regulated for good reason but still happen.
>
> There are policies and procedures in place to manage the allocation  
> of IP
> addresses.  Abandoning those policies to the end user is foolhardy.
>
> ARIN already does a great job of transferring address space from  
> registrant
> user to another when appropriate, and they work well with the  
> registrant
> users.  Adding a transfer policy will just muck up the works.
>
>> Let's keep in mind that transfers of IP addresses already
>> happen. Are you suggesting that they all be stopped? The only
>> difference of a policy change would be that we now allow
>> money to be a consideration for the addresses directly,
>> rather than for the corporation as a whole.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From BillD at cait.wustl.edu  Mon Sep 29 13:27:02 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 29 Sep 2008 12:27:02 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877ADB27@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D030877ADB27@ex1.cait.wustl.edu>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030877ADB51@ex1.cait.wustl.edu>

Based upon an inquiry, I would like to clarify my statements below.

I do NOT intend to say that 2008-6 is a more 'liberal' policy proposal
than 2008-2....but rather that 2008-6 was intended for those (like
2008-2) who want a more liberal transfer policy than exists now within
the Number Resource Policy Manual (NRPM).

And of course, I also intended to say that "2008-6 was promulgated as an
alternative to 2008-2....."

Sorry for the confusion.... 

bd 


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte
> Sent: Monday, September 29, 2008 10:01 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for 
> IPv4 Addresses
> 
> As the Oct 15 ARIN Public Policy Meeting comes closer, I 
> would like to again ask anyone who has not commented (or 
> sufficiently) on this policy proposal to do so.  Especially, 
> I am interested in what you think are the positive or 
> negative aspects of this proposal in contrast to 2008-2 the 
> more elaborate and detailed proposal.
> 
> 2008-6 was promulgated as an alternative to 2008-6 for those 
> who believe that 1./ a more liberal transfer policy is in the 
> best interest of the industry and, 2./ feel that it would be 
> easier to pass it and then modify it as needed in the future, 
> should 2008-2 fail to gain consensus across all of its nuance.
> 
> As always, I thank you for your involvement and insight into 
> the policy evaluation process of ARIN.  Your participation 
> makes the role of the AC much easier and the overall process 
> more rigorous.
> 
> Bill Darte
> ARIN Advisory Council
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From mueller at syr.edu  Mon Sep 29 13:28:41 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 29 Sep 2008 13:28:41 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5D@mail>
References: <70DE64CEFD6E9A4EB7FAF3A063141066A10B5A@mail><C0F2465B4F386241A58321C884AC7ECC08543F76@E03MVZ2-UKDY.domain1.systemhost.net><7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B5D@mail>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD902215188@SUEXCL-02.ad.syr.edu>

> Sales of heroin to schoolchildren already happen and there 
> are rules against
> it..  Are you saying that because it happens it should be legalized or
> deregulated? 
> 

My point was that IP address transfers among organizations are not
"derivative" markets and are not that big a deal; they already happen
and are legitimate. The only difference is allowing people to pay or get
paid for transfers. You compare them to sales of heroin to
schoolchildren. A real advance in the dialogue, thanks. I am deeply
impressed and will totally reconsider my position.

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 


From michael.dillon at bt.com  Mon Sep 29 15:25:20 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 29 Sep 2008 20:25:20 +0100
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08544072@E03MVZ2-UKDY.domain1.systemhost.net>

> This is nonsense. Literally. IP address transfer markets are 
> not derivative markets,

A derivative is essentially a contract. It is used to buy or
sell something, that normally cannot be bought or sold. Yes,
it is true that the most common types of derivative contracts
are options and futures, but there are many others.

> IP 
> address transfers as proposed by various RIR policy changes 
> directly transfer a valuable but intangible asset from one 
> party to another. There is no redistribution of risk. 

Given that the RIR policies and registration agreements(contracts)
all state clearly that IP addresses are not property, I don't
see how you can buy or sell the right to use them other than 
through a derivative contract. So far, I have seen no policy
proposals to change IP addresses into property, and if they
are not property, then they cannot be an asset and cannot be
bought or sold.

As for redistribution of risk, that is insurance (or reinsurance)
and is not an essential component of a derivative contract.

> Let's keep in mind that transfers of IP addresses already 
> happen. Are you suggesting that they all be stopped?

Yes, they should all be stopped. The only legitimate way to 
acquire the right to use an IP adress block is to show technical
justification to an RIR. The only legitimate transfer of right to
use an address is one that transfers network assets, or one that
has an RIR as one of the two parties.

--Michael Dillon



From cliffb at cjbsys.bdb.com  Mon Sep 29 15:51:51 2008
From: cliffb at cjbsys.bdb.com (Cliff Bedore)
Date: Mon, 29 Sep 2008 15:51:51 -0400 (EDT)
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08544072@E03MVZ2-UKDY.domain1.systemhost.net>
	from "michael.dillon@bt.com" at Sep 29, 2008 08:25:20 PM
Message-ID: <200809291951.m8TJpqe9023491@cjbsys.bdb.com>

> 
> > This is nonsense. Literally. IP address transfer markets are 
> > not derivative markets,
> 
> A derivative is essentially a contract. It is used to buy or
> sell something, that normally cannot be bought or sold. Yes,
> it is true that the most common types of derivative contracts
> are options and futures, but there are many others.
> 
> > IP 
> > address transfers as proposed by various RIR policy changes 
> > directly transfer a valuable but intangible asset from one 
> > party to another. There is no redistribution of risk. 
> 
> Given that the RIR policies and registration agreements(contracts)
> all state clearly that IP addresses are not property, I don't
> see how you can buy or sell the right to use them other than 
> through a derivative contract. So far, I have seen no policy
> proposals to change IP addresses into property, and if they
> are not property, then they cannot be an asset and cannot be
> bought or sold.

The idea of this is that it is a new transfer method to complement those that
exist.  It is not the buying and selling of anything.  All financial 
transactions (if any) are between the transferer and transferee.  ARIN simply
registers the transfer when it meets the conditions ARIN set.

I went through this example a while ago but I guess it's worth repeating.  In
Maryland, when you as a private owner sell a car to another private owner, the
state has some control over the transfer but has nothing to do with the price.
It has to pass an inspection (think prequalification) and you have to pay
sales tax (think ARIN fees)  The state requires and controls the transfer but
has nothing to do with the price.  The state issues the title but has no real
control or say in ownership.

Cliff

between 
> 
> As for redistribution of risk, that is insurance (or reinsurance)
> and is not an essential component of a derivative contract.
> 
> > Let's keep in mind that transfers of IP addresses already 
> > happen. Are you suggesting that they all be stopped?
> 
> Yes, they should all be stopped. The only legitimate way to 
> acquire the right to use an IP adress block is to show technical
> justification to an RIR. The only legitimate transfer of right to
> use an address is one that transfers network assets, or one that
> has an RIR as one of the two parties.
> 
> --Michael Dillon
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


-- 
Cliff Bedore
7403 Radcliffe Dr. College Park MD 20740
cliffb at cjbsys.bdb.com http://www.bdb.com
Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/


From kkargel at polartel.com  Mon Sep 29 15:51:12 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 29 Sep 2008 14:51:12 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08544072@E03MVZ2-UKDY.domain1.systemhost.net>
References: <7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>
	<C0F2465B4F386241A58321C884AC7ECC08544072@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B61@mail>

 
Thank you Micheal for your common sense explanations.  I certainly agree
that the only legitimate way to transfer IP addresses is through the
services of the RIR.  Anything else would breed chaos.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
> Sent: Monday, September 29, 2008 2:25 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> for IPv4 Addresses
> 
> > This is nonsense. Literally. IP address transfer markets are not 
> > derivative markets,
> 
> A derivative is essentially a contract. It is used to buy or 
> sell something, that normally cannot be bought or sold. Yes, 
> it is true that the most common types of derivative contracts 
> are options and futures, but there are many others.
> 
> > IP
> > address transfers as proposed by various RIR policy changes 
> directly 
> > transfer a valuable but intangible asset from one party to another. 
> > There is no redistribution of risk.
> 
> Given that the RIR policies and registration 
> agreements(contracts) all state clearly that IP addresses are 
> not property, I don't see how you can buy or sell the right 
> to use them other than through a derivative contract. So far, 
> I have seen no policy proposals to change IP addresses into 
> property, and if they are not property, then they cannot be 
> an asset and cannot be bought or sold.
> 
> As for redistribution of risk, that is insurance (or 
> reinsurance) and is not an essential component of a 
> derivative contract.
> 
> > Let's keep in mind that transfers of IP addresses already 
> happen. Are 
> > you suggesting that they all be stopped?
> 
> Yes, they should all be stopped. The only legitimate way to 
> acquire the right to use an IP adress block is to show 
> technical justification to an RIR. The only legitimate 
> transfer of right to use an address is one that transfers 
> network assets, or one that has an RIR as one of the two parties.
> 
> --Michael Dillon
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/16f313a4/attachment.bin>

From sleibrand at internap.com  Mon Sep 29 15:56:16 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 29 Sep 2008 12:56:16 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B61@mail>
References: <7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>	<C0F2465B4F386241A58321C884AC7ECC08544072@E03MVZ2-UKDY.domain1.systemhost.net>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B61@mail>
Message-ID: <48E132E0.1080109@internap.com>

Kevin,

Can you outline a proposal of how you think ARIN should effectuate such 
transfers?

Thanks,
Scott

Kevin Kargel wrote:
>  
> Thank you Micheal for your common sense explanations.  I certainly agree
> that the only legitimate way to transfer IP addresses is through the
> services of the RIR.  Anything else would breed chaos.
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
>> Sent: Monday, September 29, 2008 2:25 PM
>> To: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
>> for IPv4 Addresses
>>
>>> This is nonsense. Literally. IP address transfer markets are not 
>>> derivative markets,
>> A derivative is essentially a contract. It is used to buy or 
>> sell something, that normally cannot be bought or sold. Yes, 
>> it is true that the most common types of derivative contracts 
>> are options and futures, but there are many others.
>>
>>> IP
>>> address transfers as proposed by various RIR policy changes 
>> directly 
>>> transfer a valuable but intangible asset from one party to another. 
>>> There is no redistribution of risk.
>> Given that the RIR policies and registration 
>> agreements(contracts) all state clearly that IP addresses are 
>> not property, I don't see how you can buy or sell the right 
>> to use them other than through a derivative contract. So far, 
>> I have seen no policy proposals to change IP addresses into 
>> property, and if they are not property, then they cannot be 
>> an asset and cannot be bought or sold.
>>
>> As for redistribution of risk, that is insurance (or 
>> reinsurance) and is not an essential component of a 
>> derivative contract.
>>
>>> Let's keep in mind that transfers of IP addresses already 
>> happen. Are 
>>> you suggesting that they all be stopped?
>> Yes, they should all be stopped. The only legitimate way to 
>> acquire the right to use an IP adress block is to show 
>> technical justification to an RIR. The only legitimate 
>> transfer of right to use an address is one that transfers 
>> network assets, or one that has an RIR as one of the two parties.
>>
>> --Michael Dillon
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to 
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.


From kkargel at polartel.com  Mon Sep 29 16:01:45 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 29 Sep 2008 15:01:45 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <48E132E0.1080109@internap.com>
References: <7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>	<C0F2465B4F386241A58321C884AC7ECC08544072@E03MVZ2-UKDY.domain1.systemhost.net>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B61@mail>
	<48E132E0.1080109@internap.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B62@mail>

I can easily outline a proposal, I don't think ARIN needs to do it.  ARIN is
already doing the job and doing a darned fine job at that.  

Things are great the way they are.  We don't need to change it.

So my outline of a proposal is simple, leave things the way they are,
dismiss all of the "Emergency" transfer policy proposals.  

"Effectuating" such transfers is wrong.  There are already ample policies
and procedures in place to handle the situation. 

> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com] 
> Sent: Monday, September 29, 2008 2:56 PM
> To: Kevin Kargel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> for IPv4 Addresses
> 
> Kevin,
> 
> Can you outline a proposal of how you think ARIN should 
> effectuate such transfers?
> 
> Thanks,
> Scott
> 
> Kevin Kargel wrote:
> >  
> > Thank you Micheal for your common sense explanations.  I certainly 
> > agree that the only legitimate way to transfer IP addresses 
> is through 
> > the services of the RIR.  Anything else would breed chaos.
> > 
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net
> >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of 
> >> michael.dillon at bt.com
> >> Sent: Monday, September 29, 2008 2:25 PM
> >> To: arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> for IPv4 
> >> Addresses
> >>
> >>> This is nonsense. Literally. IP address transfer markets are not 
> >>> derivative markets,
> >> A derivative is essentially a contract. It is used to buy or sell 
> >> something, that normally cannot be bought or sold. Yes, it is true 
> >> that the most common types of derivative contracts are options and 
> >> futures, but there are many others.
> >>
> >>> IP
> >>> address transfers as proposed by various RIR policy changes
> >> directly
> >>> transfer a valuable but intangible asset from one party 
> to another. 
> >>> There is no redistribution of risk.
> >> Given that the RIR policies and registration
> >> agreements(contracts) all state clearly that IP addresses are not 
> >> property, I don't see how you can buy or sell the right to 
> use them 
> >> other than through a derivative contract. So far, I have seen no 
> >> policy proposals to change IP addresses into property, and if they 
> >> are not property, then they cannot be an asset and cannot 
> be bought 
> >> or sold.
> >>
> >> As for redistribution of risk, that is insurance (or
> >> reinsurance) and is not an essential component of a derivative 
> >> contract.
> >>
> >>> Let's keep in mind that transfers of IP addresses already
> >> happen. Are
> >>> you suggesting that they all be stopped?
> >> Yes, they should all be stopped. The only legitimate way 
> to acquire 
> >> the right to use an IP adress block is to show technical 
> >> justification to an RIR. The only legitimate transfer of 
> right to use 
> >> an address is one that transfers network assets, or one 
> that has an 
> >> RIR as one of the two parties.
> >>
> >> --Michael Dillon
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >>
> >>
> >> 
> ---------------------------------------------------------------------
> >> ---
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed 
> to the ARIN 
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/1f92e77f/attachment.bin>

From schnizlein at isoc.org  Mon Sep 29 16:20:50 2008
From: schnizlein at isoc.org (John Schnizlein)
Date: Mon, 29 Sep 2008 16:20:50 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <48E132E0.1080109@internap.com>
References: <7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>	<C0F2465B4F386241A58321C884AC7ECC08544072@E03MVZ2-UKDY.domain1.systemhost.net>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B61@mail>
	<48E132E0.1080109@internap.com>
Message-ID: <4AA2075A-5326-4948-AA59-BEBC50645995@isoc.org>


On 2008Sep29, at 3:56 PM, Scott Leibrand wrote:
>
> Can you outline a proposal of how you think ARIN should effectuate  
> such
> transfers?

I thing the existing proposal would work: the party to whom an address  
block is assigned informs the RIR of its desire to transfer that block  
to the new party, preferably wrapped in cryptographic saran-wrap to  
avoid fraud.  The RIR performs whatever validation is specified by its  
policy at that time.

I don't think this is any different for the "emergency" or the other  
transfer proposal.

John


From tvest at pch.net  Mon Sep 29 16:24:56 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 29 Sep 2008 16:24:56 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <48E132E0.1080109@internap.com>
References: <7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>	<C0F2465B4F386241A58321C884AC7ECC08544072@E03MVZ2-UKDY.domain1.systemhost.net>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B61@mail>
	<48E132E0.1080109@internap.com>
Message-ID: <8ABB0EC6-C847-4010-9C44-80E508C915DE@pch.net>

On Sep 29, 2008, at 3:56 PM, Scott Leibrand wrote:

> Kevin,
>
> Can you outline a proposal of how you think ARIN should effectuate  
> such
> transfers?
>
> Thanks,
> Scott

I can. In fact I did on September 4. Summarizing again below:


> ...Imagine that at the end of the free pool, annual renewal fees  
> start incrementing per /32, but that ARIN offers a "bounty" equal to  
> 100% of the new fees to any signatory that agrees to voluntarily  
> return some scale-sensitive quantity of IPv4.* For the sake of  
> "simplicity" I'll illustrate using $1 per IP, rounded up to the  
> nearest classful bit boundary for the renewal fee, and define the  
> address return required to earn the "bounty" as equal to the next  
> smallest classful address block, but many numbers/ratios would  
> probably work equally well.
>
> So, for example, the mechanism I'm imagining would oblige a /8  
> holder to return one /16 per year in order to qualify for the  
> bounty, which would also effectively make this approach revenue  
> neutral. ARIN would never have to handle one penny more than it does  
> today. To make the effects consistent across the smaller end of the  
> address distribution spectrum, maybe additional fees and bounties  
> are phased out for members that retain a /20 or less, until all  
> members are down to roughly equivalent sized IPv4 endowments.
>
> *less any added administrative costs, which should be modest.
>
> What would this approach accomplish?
>
> 1. Incremental, inevitable, but (more) predictable effects: No  
> matter what, everyone is facing the same reality of doing more with  
> less IPv4, or much much more expensive IPv4, and/or perhaps with  
> some IPv6. No one should be imagining that making a windfall on the  
> transition, or pushing most or all of the costs of transition onto  
> future new entrants are sustainable options; they aren't. By the  
> same logic, no one should be significantly harmed by parting with  
> 1/256 of their existing IPv4 reserves every year, especially if  
> everyone is facing the exact same constraint. Given the mechanism's  
> scale-sensitive uniform effects, even operators who grudgingly  
> support the idea while still hoping/expecting to NEVER make a full  
> transition to IPv6 could find comfort in the knowledge that they  
> might have hundreds of years to be proven right.
>
> 2. Recover liquid legacy IPv4 address space: Nothing in this  
> approach requires or assumes that ARIN members will return address  
> space that they received directly from ARIN, and everyone is already  
> assuming the emergence of some kind of gray market (at least) under  
> any/all future scenarios. If quietly purchasing IPv4 in a gray  
> market looks like a better deal than returning RSA-covered addresses  
> and perhaps adopting some IPv6 on the margin, then nothing would  
> explicitly prevent people from doing that. Thus legacy/surplus  
> address space holders are not absolutely precluded from capitalizing  
> on their early efforts / good fortune, but sales do not have to be  
> formally condoned, and the whole system does not have to be  
> jeopardized in order for that option to be preserved.
>
> 3. Minimize speculative pricing: Nothing short of militarization of  
> the process is likely to eliminate all speculation/profiteering, but  
> this approach would define an implicit "official price" for IPv4  
> that could help to establish a firm ceiling on speculative pricing.
>
> 4. Avoid wholesale privatization: By leaving ARIN in place as the  
> sole official mediator for IPv4 "recirculation" -- not transfers --  
> the risk of full privatization (intentional or unintentional) is  
> reduced to zero.
>
> 5. Back out IPv4 now, or later, or never: IPv4 recovered by ARIN  
> could be warehoused permanently, e.g., to assure an eventual return  
> to address space homogeneity somewhere down the line, and to send a  
> signal to non-participants that IPv4 *will* be obsolete sooner or  
> later (reinforcing 3, above). Alternately, the address space could  
> be put to other uses (e.g., made available for subsequent  
> allocations to those willing to pay the same $1 per acquisition and  
> renewal fees, with the proceeds returned as dividends to the entire  
> community, or selectively and proportionately, e.g., for accelerated  
> IPv4 returns).
>
> 6. Preserve of industry openness: Regardless of how the majority of  
> recovered IPv4 is disposed of, enough will always remain available  
> -- ideally through 2008-5 style transitional allocations -- to  
> clearly demonstrate to all internal and external stakeholders that  
> all segments of the industry will remain open to new entry in  
> perpetuity.
>
> 7. Mitigate antitrust risks: In the absence of (6, above) large IPv4- 
> based service providers will be perpetually at some risk of  
> antitrust action. The proposed policy might conceivable redirect  
> some of that risk in the RIR's direction, but it seems to me that  
> given the pro-open access orientation, a community consensus- 
> supported approach like this would probably provide the strongest  
> possible defense against any/all antitrust concerns.
>
> 8. Enable IPv6 integration/migration: This approach should help to  
> squelch any bets/competitive strategies that an IPv6 transition will  
> never happen. Once people get over the psychological hurdle that  
> IPv6 really *is* coming, and understand that the transition is not  
> going to be complicated by radical uncertainties,  high risk second  
> guessing, or any other new competitive traps, expectations about the  
> future will be aligned in ways that might accelerate the pace and  
> reduce everyone's pain of migration.
>
> 9. Minimize routing table expansion: This approach would assure that  
> at, over time, progressively more growth will be accommodated by  
> IPv6 rather than through de-aggregation. Doesn't solve the IPv6  
> routing scalability issue, but it does preserve the RIR as a  
> potentially self-sustaining administrator for any ongoing/future  
> number resource-related needs verification, as maintainer of the  
> registration database, provider of whois, and a potential anchor for  
> resource certification, et al. -- and as a viable mechanism for  
> continuing policy deliberation in the event that future routing  
> scalability requirements require the same kind of coordinated action  
> that helped to mitigate the last such crisis.
>
> 10. Clean, easiest possible reversability: Unlike the 2008-2 and  
> 2008-6, if this approach turns out to have perverse unanticipated  
> consequences, it could be terminated or even reversed with a  
> (relative) minimum of disruption.
>
> Potential Downside: if IPv4 is permanently warehoused, then any  
> potential revenue arising from IPv4 sales would be foregone. If IPv4  
> prices are expected to be modest (e.g., modest enough to avoid  
> antitrust scrutiny), then perhaps any loss would be equally modest.  
> Alternately, the foregone one-time sales revenues could be thought  
> of as investments toward a better, NAT free (or NAT-vonlutary-only)  
> future. If those future payoffs are deemed to be insufficient,  
> returned address space along with cash proceeds from ongoing IPv4  
> "recirculation" could be redistributed to community members, but  
> this would probably impose substantial new administrative burdens  
> and risks on ARIN. However, the second option is neither required  
> nor recommended.


TV


> Kevin Kargel wrote:
>>
>> Thank you Micheal for your common sense explanations.  I certainly  
>> agree
>> that the only legitimate way to transfer IP addresses is through the
>> services of the RIR.  Anything else would breed chaos.
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net
>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
>>> Sent: Monday, September 29, 2008 2:25 PM
>>> To: arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy
>>> for IPv4 Addresses
>>>
>>>> This is nonsense. Literally. IP address transfer markets are not
>>>> derivative markets,
>>> A derivative is essentially a contract. It is used to buy or
>>> sell something, that normally cannot be bought or sold. Yes,
>>> it is true that the most common types of derivative contracts
>>> are options and futures, but there are many others.
>>>
>>>> IP
>>>> address transfers as proposed by various RIR policy changes
>>> directly
>>>> transfer a valuable but intangible asset from one party to another.
>>>> There is no redistribution of risk.
>>> Given that the RIR policies and registration
>>> agreements(contracts) all state clearly that IP addresses are
>>> not property, I don't see how you can buy or sell the right
>>> to use them other than through a derivative contract. So far,
>>> I have seen no policy proposals to change IP addresses into
>>> property, and if they are not property, then they cannot be
>>> an asset and cannot be bought or sold.
>>>
>>> As for redistribution of risk, that is insurance (or
>>> reinsurance) and is not an essential component of a
>>> derivative contract.
>>>
>>>> Let's keep in mind that transfers of IP addresses already
>>> happen. Are
>>>> you suggesting that they all be stopped?
>>> Yes, they should all be stopped. The only legitimate way to
>>> acquire the right to use an IP adress block is to show
>>> technical justification to an RIR. The only legitimate
>>> transfer of right to use an address is one that transfers
>>> network assets, or one that has an RIR as one of the two parties.
>>>
>>> --Michael Dillon
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From sleibrand at internap.com  Mon Sep 29 16:41:04 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 29 Sep 2008 13:41:04 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B62@mail>
References: <7663C7E01D8E094989CA62F0B0D21CD902215185@SUEXCL-02.ad.syr.edu>	<C0F2465B4F386241A58321C884AC7ECC08544072@E03MVZ2-UKDY.domain1.systemhost.net>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B61@mail>	<48E132E0.1080109@internap.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B62@mail>
Message-ID: <48E13D60.9030407@internap.com>

I can understand your "leave policy alone" position, but I'm not sure I 
understand how you think current policies and procedures will allow 
legitimate transfers of IP addresses after the IPv4 free pool is 
exhausted, or will otherwise allow ARIN to continue meeting IPv4 demand.

Remember, keeping things the way they are is not an option.  The free pool 
will run out, and we have to decide whether ARIN should continue to make 
IPv4 addresses available after that happens.  If not, no policy change is 
needed.  If so, some new policy will be required.  That could be a 
rationing policy (such as APNIC's "last /8 policy", prop-062, ARIN policy 
proposal 2008-5, which reserves a /10 for allocation as /28-/24's for IPv6 
transition purposes), a transfer policy (such as 2008-2 or 2008-6), and/or 
some other type of reclamation incentive policy (such as Tom Vest has 
proposed).

-Scott

Kevin Kargel wrote:
> I can easily outline a proposal, I don't think ARIN needs to do it.  ARIN is
> already doing the job and doing a darned fine job at that.  
> 
> Things are great the way they are.  We don't need to change it.
> 
> So my outline of a proposal is simple, leave things the way they are,
> dismiss all of the "Emergency" transfer policy proposals.  
> 
> "Effectuating" such transfers is wrong.  There are already ample policies
> and procedures in place to handle the situation. 
> 
>> -----Original Message-----
>> From: Scott Leibrand [mailto:sleibrand at internap.com] 
>> Sent: Monday, September 29, 2008 2:56 PM
>> To: Kevin Kargel
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
>> for IPv4 Addresses
>>
>> Kevin,
>>
>> Can you outline a proposal of how you think ARIN should 
>> effectuate such transfers?
>>
>> Thanks,
>> Scott
>>
>> Kevin Kargel wrote:
>>>  
>>> Thank you Micheal for your common sense explanations.  I certainly 
>>> agree that the only legitimate way to transfer IP addresses 
>> is through 
>>> the services of the RIR.  Anything else would breed chaos.
>>>
>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net
>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of 
>>>> michael.dillon at bt.com
>>>> Sent: Monday, September 29, 2008 2:25 PM
>>>> To: arin-ppml at arin.net
>>>> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
>> for IPv4 
>>>> Addresses
>>>>
>>>>> This is nonsense. Literally. IP address transfer markets are not 
>>>>> derivative markets,
>>>> A derivative is essentially a contract. It is used to buy or sell 
>>>> something, that normally cannot be bought or sold. Yes, it is true 
>>>> that the most common types of derivative contracts are options and 
>>>> futures, but there are many others.
>>>>
>>>>> IP
>>>>> address transfers as proposed by various RIR policy changes
>>>> directly
>>>>> transfer a valuable but intangible asset from one party 
>> to another. 
>>>>> There is no redistribution of risk.
>>>> Given that the RIR policies and registration
>>>> agreements(contracts) all state clearly that IP addresses are not 
>>>> property, I don't see how you can buy or sell the right to 
>> use them 
>>>> other than through a derivative contract. So far, I have seen no 
>>>> policy proposals to change IP addresses into property, and if they 
>>>> are not property, then they cannot be an asset and cannot 
>> be bought 
>>>> or sold.
>>>>
>>>> As for redistribution of risk, that is insurance (or
>>>> reinsurance) and is not an essential component of a derivative 
>>>> contract.
>>>>
>>>>> Let's keep in mind that transfers of IP addresses already
>>>> happen. Are
>>>>> you suggesting that they all be stopped?
>>>> Yes, they should all be stopped. The only legitimate way 
>> to acquire 
>>>> the right to use an IP adress block is to show technical 
>>>> justification to an RIR. The only legitimate transfer of 
>> right to use 
>>>> an address is one that transfers network assets, or one 
>> that has an 
>>>> RIR as one of the two parties.
>>>>
>>>> --Michael Dillon
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed 
>> to the ARIN 
>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> ---
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed 
>> to the ARIN 
>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.


From michael.dillon at bt.com  Mon Sep 29 16:50:03 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 29 Sep 2008 21:50:03 +0100
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B62@mail>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08544096@E03MVZ2-UKDY.domain1.systemhost.net>

> I can easily outline a proposal, I don't think ARIN needs to 
> do it.  ARIN is already doing the job and doing a darned fine 
> job at that.  
> 
> Things are great the way they are.  We don't need to change it.

In other words, there is already a system in place for transfering
address blocks which has been exercised numerous times. Any organization
which no longer needs addresses, returns them to ARIN. Any organization
that needs addresses, applies to ARIN and gets some, which may
have earlier been allocated to a different organization.

No new policy is needed.

--Michael Dillon


From michael.dillon at bt.com  Mon Sep 29 17:02:56 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 29 Sep 2008 22:02:56 +0100
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <48E13D60.9030407@internap.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC0854409D@E03MVZ2-UKDY.domain1.systemhost.net>

> I can understand your "leave policy alone" position, but I'm 
> not sure I understand how you think current policies and 
> procedures will allow legitimate transfers of IP addresses 
> after the IPv4 free pool is exhausted, or will otherwise 
> allow ARIN to continue meeting IPv4 demand.

First of all, nobody will be able to meet demand after
the free pool is exhausted unless some organizations are
able to free up address space. In order for this to happen,
some organizations need to make a big move to IPv6, not
using dual-stack which happens to be the favoured technique
at present. Assuming such organizations exist, current
policy allows them to return the addresses to ARIN for
redistribution. If there are more requesters than addresses
current policy already functions under a first-some first-
served model that could continue.

No changes to the method of transfering right-of-use will 
be able to increase the supply of IPv4 addresses in any
meaningful way. The only way for the supply to increase
is for organizations to migrate to pure IPv6 networks and
thereby release the IPv4 addresses that were formerly in
use on those networks. 

ARIN has no duty to maintain a supply of IPv4 addresses.
ARIN has no duty to meet the demand for IPv4 addresses forever.
Everybody has known for years that the supply is fixed
and limited. It is not ARIN's responsibility to rescue
organizations from bad business decisions nor is it ARIN's
responsibility to alleviate the negative effects of those
bad business decisions.

By the way, it is not too late for everyone to start working
with their vendors today, to make sure that their IPv6
devices and software fully support all the features that
are needed for full production in two years from now.

> Remember, keeping things the way they are is not an option.

Yes, keeping things the way they are now *IS* an option and
many of us believe that it is the BEST option as well.
  
> The free pool will run out, and we have to decide whether 
> ARIN should continue to make
> IPv4 addresses available after that happens.

No decision is necessary. ARIN always allocates from its 
own free pool, and accepts returned blocks into its own
free pool.

No rationing is necessary. First come, first served, works
now and will work even if there is a queue of 100 organizations
waiting for a free block. No new policy is needed here.
Eventually the queue and the demand will go away when people
realize how dumb it is to use IPv4 for most applications.
There will be a steady stream of returns which should keep
be able to supply IPv4 users for the next 20 years or so, when
I expect ISPs to start dropping support for gateway technologies.

--Michael Dillon


From dlw+arin at tellme.com  Mon Sep 29 17:04:36 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Mon, 29 Sep 2008 14:04:36 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08544096@E03MVZ2-UKDY.domain1.systemhost.net>
References: <70DE64CEFD6E9A4EB7FAF3A063141066A10B62@mail>
	<C0F2465B4F386241A58321C884AC7ECC08544096@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20080929210436.GG1271@shell02.cell.sv2.tellme.com>

On Mon, Sep 29, 2008 at 09:50:03PM +0100, michael.dillon at bt.com wrote:
> Any organization
> which no longer needs addresses, returns them to ARIN. 

Given a scarcity of a resource, all network operators are suddenly
going to become altruistic and return unused space for the general
good?

What you outline is much the same as what is being proposed.  You
identify two transactions: one where space is returned, and one where
it is handed out.  Most of the proposals have the same overall impact,
except that there's just a single transaction moderated by ARIN as a
middleman verifying the transaction, and money changes hands.

Outside of the cash part, I don't see a substantial difference.  The
money serves as motivation for the first party to let go of unneeded
space.  That incentive seems important, since I don't think most
network operators are prone to gratuitous altruism.

Are people really so worried about introducing money to the transaction?

-David


From heather.skanks at gmail.com  Mon Sep 29 17:05:50 2008
From: heather.skanks at gmail.com (heather skanks)
Date: Mon, 29 Sep 2008 17:05:50 -0400
Subject: [arin-ppml] Policy Manual : Customer Privacy
In-Reply-To: <287016.79102.qm@web63702.mail.re1.yahoo.com>
References: <287016.79102.qm@web63702.mail.re1.yahoo.com>
Message-ID: <616812070809291405s10f9209bo204b2e4b5dc16735@mail.gmail.com>

Automated provisioning systems ... did you think that someone generates all
those millions of templates by hand?  :)

 --heather

On Sat, Sep 27, 2008 at 7:52 PM, chris mr <chris.misztur at yahoo.com> wrote:

> Hello,
>
> Reference: http://www.arin.net/policy/nrpm.html#four2376
>
> I have recently noticed that ISPs such as ATT(SIS-80) and Comcast(CBCI)
> publish their customers' personal information in /29 reassignments.  For my
> residential DSL service I was told to contact ipadmin at att.com to hide my
> personal information, which they did.
>
> What are your thoughts as to why ISPs do not protect their residential
> customers' privacy by default?
>
> My thought on this subject is that ISPs still have the belief that Internet
> service with static IP blocks is only required by businesses, therefore ISPs
> fail to make the distinction between personal and business Internet
> accounts.
>
> Chris
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/19d8d5fb/attachment.htm>

From kkargel at polartel.com  Mon Sep 29 17:14:34 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 29 Sep 2008 16:14:34 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <20080929210436.GG1271@shell02.cell.sv2.tellme.com>
References: <70DE64CEFD6E9A4EB7FAF3A063141066A10B62@mail><C0F2465B4F386241A58321C884AC7ECC08544096@E03MVZ2-UKDY.domain1.systemhost.net>
	<20080929210436.GG1271@shell02.cell.sv2.tellme.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail>

 
YES!  People really are so worried about introducing money to the
transaction.

I do not want to end up going to eBay for address space.

We have a great system in place now that many great people have spent
thousands of hours developing.


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Williamson
> Sent: Monday, September 29, 2008 4:05 PM
> To: michael.dillon at bt.com
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> for IPv4 Addresses
> 
> On Mon, Sep 29, 2008 at 09:50:03PM +0100, michael.dillon at bt.com wrote:
> > Any organization
> > which no longer needs addresses, returns them to ARIN. 
> 
> Given a scarcity of a resource, all network operators are 
> suddenly going to become altruistic and return unused space 
> for the general good?
> 
> What you outline is much the same as what is being proposed.  
> You identify two transactions: one where space is returned, 
> and one where it is handed out.  Most of the proposals have 
> the same overall impact, except that there's just a single 
> transaction moderated by ARIN as a middleman verifying the 
> transaction, and money changes hands.
> 
> Outside of the cash part, I don't see a substantial 
> difference.  The money serves as motivation for the first 
> party to let go of unneeded space.  That incentive seems 
> important, since I don't think most network operators are 
> prone to gratuitous altruism.
> 
> Are people really so worried about introducing money to the 
> transaction?
> 
> -David
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/7fd028e3/attachment.bin>

From dlw+arin at tellme.com  Mon Sep 29 17:23:13 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Mon, 29 Sep 2008 14:23:13 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail>
Message-ID: <20080929212313.GJ1271@shell02.cell.sv2.tellme.com>

On Mon, Sep 29, 2008 at 04:14:34PM -0500, Kevin Kargel wrote:
> YES!  People really are so worried about introducing money to the
> transaction.
> 
> I do not want to end up going to eBay for address space.

I'm not either, but as we run out of space, the choices seem, to me, to
be either eBay, or you just can't get it.  Given "pay" or "no", I
choose the former...especially if the requests are getting properly
examined by a third-party with an interest in efficientcy and validity
of the transfer, and not the money involved, i.e., ARIN.

I'm also pretty certain the transfers for money will take place whether
we all like it or not.  I'd rather have it legitimized by ARIN, rather
than a complete black market.

I really don't like it, but I don't see a practical alternative.
Depending on the good will of those who have space and don't need it
has never worked to well, in my opinion.

-David




From bonomi at mail.r-bonomi.com  Mon Sep 29 17:24:31 2008
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Mon, 29 Sep 2008 16:24:31 -0500 (CDT)
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
Message-ID: <200809292124.m8TLOVOp014756@mail.r-bonomi.com>

> From arin-ppml-bounces at arin.net  Mon Sep 29 14:25:57 2008
> Date: Mon, 29 Sep 2008 20:25:20 +0100
> From: <michael.dillon at bt.com>
> To: <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
>
[[..  sneck  ..]

> Given that the RIR policies and registration agreements(contracts)
> all state clearly that IP addresses are not property, I don't
> see how you can buy or sell the right to use them other than 
> through a derivative contract. 

It is really quite simple.  

What is granted in a block assignment from a RIR  (or the original DARPA 
address-coordinatior) is not 'ownership' of the addresses, but just a 
"right to use" license for those integers in a particular context.

The *license* is, itself, "property", and  can bought and sold. 

This is, functionally, no different from the title to a condominium, or a 
deeded 'skybox' at the sports emporium of ones choice.

It is a straight purchase/sale of an asset.

It is, arguably a 'derivative object', because it's existance is derived
from another thing.

It is not a "derivative instrument", because those things are a 'contract
to enter into a contract'.

>                                So far, I have seen no policy
> proposals to change IP addresses into property, and if they
> are not property, then they cannot be an asset and cannot be
> bought or sold.

FALSE TO FACT.

The right-to-use license _is_ an asset and -- like *any*other* asset -- can
be bought or sold, subject to the restrictions on the title thereunto imposed 
by the original license issuer.

The current proposal is simply a change of terms of the previously-granted
licenses, from "non-transferrable" to "transferrable, under specified 
conditions".




From kkargel at polartel.com  Mon Sep 29 17:30:11 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 29 Sep 2008 16:30:11 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail>
	<20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>

 Again with the "It's gonna happen anyway" argument..  

Again I say then should we legitimize selling heroin to schoolchildren?
Child prostitution? Sales of pirated coyrighted material?




> -----Original Message-----
> From: David Williamson [mailto:dlw+arin at tellme.com] 
> Sent: Monday, September 29, 2008 4:23 PM
> To: Kevin Kargel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> for IPv4 Addresses
> 
> On Mon, Sep 29, 2008 at 04:14:34PM -0500, Kevin Kargel wrote:
> > YES!  People really are so worried about introducing money to the 
> > transaction.
> > 
> > I do not want to end up going to eBay for address space.
> 
> I'm not either, but as we run out of space, the choices seem, 
> to me, to be either eBay, or you just can't get it.  Given 
> "pay" or "no", I choose the former...especially if the 
> requests are getting properly examined by a third-party with 
> an interest in efficientcy and validity of the transfer, and 
> not the money involved, i.e., ARIN.
> 
> I'm also pretty certain the transfers for money will take 
> place whether we all like it or not.  I'd rather have it 
> legitimized by ARIN, rather than a complete black market.
> 
> I really don't like it, but I don't see a practical alternative.
> Depending on the good will of those who have space and don't 
> need it has never worked to well, in my opinion.
> 
> -David
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/fdc6fc70/attachment.bin>

From dlw+arin at tellme.com  Mon Sep 29 17:36:31 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Mon, 29 Sep 2008 14:36:31 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail>
	<20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>
Message-ID: <20080929213630.GK1271@shell02.cell.sv2.tellme.com>

On Mon, Sep 29, 2008 at 04:30:11PM -0500, Kevin Kargel wrote:
>  Again with the "It's gonna happen anyway" argument..  
> 
> Again I say then should we legitimize selling heroin to schoolchildren?
> Child prostitution? Sales of pirated coyrighted material?

Your examples are poor.  Those are all illegal activities.  Purchasing
the rights to use a set of integers isn't illegal, it's just in breach
of an agreement with ARIN.  You might get sued, but you won't go to
jail.

I think the examples you are looking for are more along the lines of
enforcing sales tax at garage sales or flea markets.

I do think transfers are going to happen anyway.  THat's not a
sufficient reason on its own to create a market, but it's not a bad
reason to try to regulate it.

At one point, there was a marijuana possesion tax in Minnesota (I think
that was the correct state.)  If you didn't have enough pot on you for
a drug conviction, they'd get you for tax evasion since, surprise, no
one paid the tax.

-David


From stephen at sprunk.org  Mon Sep 29 17:46:28 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 29 Sep 2008 16:46:28 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08544096@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC08544096@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <48E14CB4.2010703@sprunk.org>

michael.dillon at bt.com wrote:
>> I can easily outline a proposal, I don't think ARIN needs to do it.  ARIN is already doing the job and doing a darned fine job at that.  
>>
>> Things are great the way they are.  We don't need to change it.
>>     
>
> In other words, there is already a system in place for transfering address blocks which has been exercised numerous times. Any organization which no longer needs addresses, returns them to ARIN.

Why would they?  After all, they might need them at some point in the 
future, there is a zero or near-zero holding cost, and there's always 
the potential for selling them via a shell corporation (as some folks 
are already doing).

(Shameless plug: 2007-14 may partially solve this problem, if it ever 
gets adopted.)

> Any organization that needs addresses, applies to ARIN and gets some, which may have earlier been allocated to a different organization.
>   

What happens when ARIN has no more address space to give out in 3-4 years?

> No new policy is needed.
>   

On that, we disagree.  IMHO, we certainly need to do _something_; 
however, I'm not willing to subscribe to the Politician's Fallacy and 
support either of the current transfer proposals simply because they 
would constitute "doing something".

S


From tedm at ipinc.net  Mon Sep 29 17:54:08 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 29 Sep 2008 14:54:08 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
Message-ID: <DF58D34D614E45859EAD0AFF15706514@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Williamson
> Sent: Monday, September 29, 2008 2:23 PM
> To: Kevin Kargel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> for IPv4 Addresses
> 
> 
> On Mon, Sep 29, 2008 at 04:14:34PM -0500, Kevin Kargel wrote:
> > YES!  People really are so worried about introducing money to the 
> > transaction.
> > 
> > I do not want to end up going to eBay for address space.
> 
> I'm not either, but as we run out of space, the choices seem, 
> to me, to be either eBay, or you just can't get it.  Given 
> "pay" or "no", I choose the former...especially if the 
> requests are getting properly examined by a third-party with 
> an interest in efficientcy and validity of the transfer, and 
> not the money involved, i.e., ARIN.
> 
> I'm also pretty certain the transfers for money will take 
> place whether we all like it or not.  I'd rather have it 
> legitimized by ARIN, rather than a complete black market.
> 
> I really don't like it, but I don't see a practical 
> alternative. Depending on the good will of those who have 
> space and don't need it has never worked to well, in my opinion.
> 

David and Bill Darte,

  I agree with Kevin and Michael, I am against paying for numbering
transfers.
However I will make the observation that I think David is correct that this
will
happen even if we don't want it to, and it will be black market.  HOWEVER
the point that seems to be missed is that if it does go black market, that
it WON'T HAPPEN until IPv4 runout actually occurs.

  Now is not the time to implement legalized transfers based on money
because if we do allow them or put language into the NPRM at this time
to permit them in the future, we are instantly creating business
justification
for investment in holding companies that do nothing other than lie, cheat
and
steal as much IPv4 as they can get BEFORE runout.  Meaning you will see a
flood
of ficticious requests for IPv4 numbering go into the RIR's pre-runout,
causing
runout to happen that much faster.

  I would prefer to wait until AFTER IPv4 runout, when there is actual
evidence
of black-market IPv4 transfers, THEN implement legalization.  Discuss it all
you want, but DON'T IMPLEMENT ANYTHING OF THE SORT AT THIS TIME.

  This policy is basically ASSUMING that unauthorized transfers are going to
happen and we need to regulate them now.  While we can suspect that they
will happen, and have a very STRONG guess that they will happen, suspicions
and strong guesses are NOT GROUNDS for policy.  With the upcoming POC
cleanup
proposals, we have PROOF that we have stale data in there due to the
number of Bitnet mail addresses discovered, thus policy is called for.  What
PROOF is there that money for IPv4 transfers at this time will help
anything?

  Has anyone ever bothered SURVEYING the existing
IPv4 holders to find out what percentage would even CONSIDER renumbering
should an IPv4 market appear?  And at what price point?

  The ONLY USE that liberalized transfer RIGHT NOW are for people who
are PLANNING on hoarding and going into business as IPv4 brokers.  They
are of no use to anyone else when ARIN still has IPv4 to hand out.

  We have enough work with making policy for things that we KNOW ARE
HAPPENING
RIGHT NOW.  For example, in the past some have asserted in this forum that
some of Dean Anderson's IP addresses are hijacked.  Has anything
been done to even investigate this?  And if it was investigated and
discovered
to be true, what mechanism exists to get them back?  Nothing!  THERE is
where
the policy blanks are that need filling in.

  We also have assertions that a number of IPv4 legacy blocks are
abandonded.  And
we have 2 proposals (mine one) that are tentative steps to discovering which
one of those blocks ARE abandonded.  We will need more policy and more
discussion
to work out a mechanism for ARIN to define abandonded legacy blocks and take
them
back.  Yet ANOTHER policy blank.

  I think it would be more fruitful to worry about making policy for
something
that is a problem right now, than for a problem we think we might possibly
have
a few years down the road.  It might be that in the process of cleaning up
messes like abandonded IPv4 that we will find that we have a lot more IPv4
than
anyone thought.

Ted



From BillD at cait.wustl.edu  Mon Sep 29 18:58:56 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 29 Sep 2008 17:58:56 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
References: <DF58D34D614E45859EAD0AFF15706514@tedsdesk>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531C5F@ex1.cait.wustl.edu>

I would like to remind everyone that 2008-6 has as rationale....
Rationale:

In order for ARIN to fulfill its mission and to facilitate a continuing supply of IPv4 address resources to its service community when ARIN resources are no longer adequate, and to preserve the integrity of documentation and ARIN services for those resources, this policy may be implemented. Its intent is to preserve the current tradition of
need-based allocation/assignments for those still needing IPv4 resources during a transition period as the industry adopts IPv6. This policy is not intended to create a 'market' for such transfers and does not introduce or condone the monetization of address resources or a view of addresses as property. It does recognize that organizations making available unused or no longer needed address resources may incur certain costs that might be compensated by those acquiring the resources. This policy is intended to be transient and light-weight and does not encourage a sustained or continuing role for IPv4, but rather helps to mitigate a transitional crisis that may emerge while the industry adopts IPv6 in accordance with the recommendation of ARIN's Board of Trustees.

.....Creating a liberalized transfer policy is not the same as encouraging the buying and selling of IP address resources.




-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Ted Mittelstaedt
Sent: Mon 9/29/2008 4:54 PM
To: 'David Williamson'; 'Kevin Kargel'
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
 


David and Bill Darte,

  I agree with Kevin and Michael, I am against paying for numbering
transfers.
However I will make the observation that I think David is correct that this
will
happen even if we don't want it to, and it will be black market.  HOWEVER
the point that seems to be missed is that if it does go black market, that
it WON'T HAPPEN until IPv4 runout actually occurs.

  Now is not the time to implement legalized transfers based on money
because if we do allow them or put language into the NPRM at this time
to permit them in the future, we are instantly creating business
justification
for investment in holding companies that do nothing other than lie, cheat
and
steal as much IPv4 as they can get BEFORE runout.  Meaning you will see a
flood
of ficticious requests for IPv4 numbering go into the RIR's pre-runout,
causing
runout to happen that much faster.

  I would prefer to wait until AFTER IPv4 runout, when there is actual
evidence
of black-market IPv4 transfers, THEN implement legalization.  Discuss it all
you want, but DON'T IMPLEMENT ANYTHING OF THE SORT AT THIS TIME.

  This policy is basically ASSUMING that unauthorized transfers are going to
happen and we need to regulate them now.  While we can suspect that they
will happen, and have a very STRONG guess that they will happen, suspicions
and strong guesses are NOT GROUNDS for policy.  With the upcoming POC
cleanup
proposals, we have PROOF that we have stale data in there due to the
number of Bitnet mail addresses discovered, thus policy is called for.  What
PROOF is there that money for IPv4 transfers at this time will help
anything?

  Has anyone ever bothered SURVEYING the existing
IPv4 holders to find out what percentage would even CONSIDER renumbering
should an IPv4 market appear?  And at what price point?

  The ONLY USE that liberalized transfer RIGHT NOW are for people who
are PLANNING on hoarding and going into business as IPv4 brokers.  They
are of no use to anyone else when ARIN still has IPv4 to hand out.

  We have enough work with making policy for things that we KNOW ARE
HAPPENING
RIGHT NOW.  For example, in the past some have asserted in this forum that
some of Dean Anderson's IP addresses are hijacked.  Has anything
been done to even investigate this?  And if it was investigated and
discovered
to be true, what mechanism exists to get them back?  Nothing!  THERE is
where
the policy blanks are that need filling in.

  We also have assertions that a number of IPv4 legacy blocks are
abandonded.  And
we have 2 proposals (mine one) that are tentative steps to discovering which
one of those blocks ARE abandonded.  We will need more policy and more
discussion
to work out a mechanism for ARIN to define abandonded legacy blocks and take
them
back.  Yet ANOTHER policy blank.

  I think it would be more fruitful to worry about making policy for
something
that is a problem right now, than for a problem we think we might possibly
have
a few years down the road.  It might be that in the process of cleaning up
messes like abandonded IPv4 that we will find that we have a lot more IPv4
than
anyone thought.

Ted

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/e48d8066/attachment.htm>

From tedm at ipinc.net  Mon Sep 29 19:41:08 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 29 Sep 2008 16:41:08 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087531C5F@ex1.cait.wustl.edu>
Message-ID: <0F1BDEC6418A435A9E9763AFAEFB73A8@tedsdesk>

Bill,
 
The URL would be helpful:
 
http://www.arin.net/policy/proposals/2008_6.html
 
The problem is the line:  "transfer of ARIN IPv4 addresses between two
entities in the ARIN region, without the active involvement of ARIN as an
intermediary, will be considered legitimate"
 
  Have you ever stood in line for movie tickets?  I'm sure you have.
 
  When your standing there and there's 50 people in front of you, and
someone walks up and wants
to "take cuts" in front of the 3rd guy in line, the 3rd guy in line is not
going to let him unless he
gets paid.
 
  And everyone else waiting in line behind the 3rd guy ISN'T going to be
paid by the guy
taking "cuts" in front of the 3rd guy.  Naturally they are going to be a
little hot under the
collar.
 
This is a market.  You can play all the semantic games you want in the
policy proposal,
it's still a market.
 
After the very last IPV4 block is assigned from ARIN, the next day there may
be someone who
stops paying their bill, and their block goes back to ARIN.  ARIN will then
reassign it to the next
person who had put in a request for IPv4 numbers. 
 
IPv4 runout is more correctly defined as the day that the demand for IPv4
exceeds the supply.
But there will still be IPv4 handed out after that day.
 
This transfer proposal allows deep pockets to "cut" in front of that line,
post-runout.  Is that
fair to everyone else who is trying to wait patiently in line for numbering?
 
Imagine that movie ticket line if everyone was paying everyone else for a
chance to be the 3rd
guy in line.
 
It would resemble your typical line for something in Italy since the
Italians have no concept of
a queue, any time that tickets or anything restricted goes on sale there,
there's a mad rush
and everyone piles on, shoving to get to the front.
 
 
Ted
 
-----Original Message-----
From: Bill Darte [mailto:BillD at cait.wustl.edu] 
Sent: Monday, September 29, 2008 3:59 PM
To: Ted Mittelstaedt; David Williamson; Kevin Kargel
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



I would like to remind everyone that 2008-6 has as rationale....
Rationale:

In order for ARIN to fulfill its mission and to facilitate a continuing
supply of IPv4 address resources to its service community when ARIN
resources are no longer adequate, and to preserve the integrity of
documentation and ARIN services for those resources, this policy may be
implemented. Its intent is to preserve the current tradition of
need-based allocation/assignments for those still needing IPv4 resources
during a transition period as the industry adopts IPv6. This policy is not
intended to create a 'market' for such transfers and does not introduce or
condone the monetization of address resources or a view of addresses as
property. It does recognize that organizations making available unused or no
longer needed address resources may incur certain costs that might be
compensated by those acquiring the resources. This policy is intended to be
transient and light-weight and does not encourage a sustained or continuing
role for IPv4, but rather helps to mitigate a transitional crisis that may
emerge while the industry adopts IPv6 in accordance with the recommendation
of ARIN's Board of Trustees.

.....Creating a liberalized transfer policy is not the same as encouraging
the buying and selling of IP address resources.




-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Ted Mittelstaedt
Sent: Mon 9/29/2008 4:54 PM
To: 'David Williamson'; 'Kevin Kargel'
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



David and Bill Darte,

  I agree with Kevin and Michael, I am against paying for numbering
transfers.
However I will make the observation that I think David is correct that this
will
happen even if we don't want it to, and it will be black market.  HOWEVER
the point that seems to be missed is that if it does go black market, that
it WON'T HAPPEN until IPv4 runout actually occurs.

  Now is not the time to implement legalized transfers based on money
because if we do allow them or put language into the NPRM at this time
to permit them in the future, we are instantly creating business
justification
for investment in holding companies that do nothing other than lie, cheat
and
steal as much IPv4 as they can get BEFORE runout.  Meaning you will see a
flood
of ficticious requests for IPv4 numbering go into the RIR's pre-runout,
causing
runout to happen that much faster.

  I would prefer to wait until AFTER IPv4 runout, when there is actual
evidence
of black-market IPv4 transfers, THEN implement legalization.  Discuss it all
you want, but DON'T IMPLEMENT ANYTHING OF THE SORT AT THIS TIME.

  This policy is basically ASSUMING that unauthorized transfers are going to
happen and we need to regulate them now.  While we can suspect that they
will happen, and have a very STRONG guess that they will happen, suspicions
and strong guesses are NOT GROUNDS for policy.  With the upcoming POC
cleanup
proposals, we have PROOF that we have stale data in there due to the
number of Bitnet mail addresses discovered, thus policy is called for.  What
PROOF is there that money for IPv4 transfers at this time will help
anything?

  Has anyone ever bothered SURVEYING the existing
IPv4 holders to find out what percentage would even CONSIDER renumbering
should an IPv4 market appear?  And at what price point?

  The ONLY USE that liberalized transfer RIGHT NOW are for people who
are PLANNING on hoarding and going into business as IPv4 brokers.  They
are of no use to anyone else when ARIN still has IPv4 to hand out.

  We have enough work with making policy for things that we KNOW ARE
HAPPENING
RIGHT NOW.  For example, in the past some have asserted in this forum that
some of Dean Anderson's IP addresses are hijacked.  Has anything
been done to even investigate this?  And if it was investigated and
discovered
to be true, what mechanism exists to get them back?  Nothing!  THERE is
where
the policy blanks are that need filling in.

  We also have assertions that a number of IPv4 legacy blocks are
abandonded.  And
we have 2 proposals (mine one) that are tentative steps to discovering which
one of those blocks ARE abandonded.  We will need more policy and more
discussion
to work out a mechanism for ARIN to define abandonded legacy blocks and take
them
back.  Yet ANOTHER policy blank.

  I think it would be more fruitful to worry about making policy for
something
that is a problem right now, than for a problem we think we might possibly
have
a few years down the road.  It might be that in the process of cleaning up
messes like abandonded IPv4 that we will find that we have a lot more IPv4
than
anyone thought.

Ted

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/319bdf76/attachment.htm>

From BillD at cait.wustl.edu  Mon Sep 29 19:56:37 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 29 Sep 2008 18:56:37 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
References: <0F1BDEC6418A435A9E9763AFAEFB73A8@tedsdesk>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531C60@ex1.cait.wustl.edu>

"for a period of 3 years" is also found at that URL....

It seeks to serve notice (once again) that these would be extraordinary times...as determined by the BoT...and that such transfers will cease to be 'legitimate' thereafter.  Hopefully this signals folks and motivates them toward v6.  But who knows?

2008-6 provides those who think something is necessary in transition a mechanism to move in that direction.  It does announce its motivation and what and its consistency with past tradition....helping others to swallow a bitter pill perhaps.

To those like yourself who think there is no value in these efforts, it affords nothing.  

Trying to convince 'me' doesn't afford much either, because the proposal is not 'my' proposal, but one for the industry to consider.

Bill Darte
ARIN AC





-----Original Message-----
From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
Sent: Mon 9/29/2008 6:41 PM
To: Bill Darte; 'David Williamson'; 'Kevin Kargel'
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
 
Bill,
 
The URL would be helpful:
 
http://www.arin.net/policy/proposals/2008_6.html
 
The problem is the line:  "transfer of ARIN IPv4 addresses between two
entities in the ARIN region, without the active involvement of ARIN as an
intermediary, will be considered legitimate"
 
  Have you ever stood in line for movie tickets?  I'm sure you have.
 
  When your standing there and there's 50 people in front of you, and
someone walks up and wants
to "take cuts" in front of the 3rd guy in line, the 3rd guy in line is not
going to let him unless he
gets paid.
 
  And everyone else waiting in line behind the 3rd guy ISN'T going to be
paid by the guy
taking "cuts" in front of the 3rd guy.  Naturally they are going to be a
little hot under the
collar.
 
This is a market.  You can play all the semantic games you want in the
policy proposal,
it's still a market.
 
After the very last IPV4 block is assigned from ARIN, the next day there may
be someone who
stops paying their bill, and their block goes back to ARIN.  ARIN will then
reassign it to the next
person who had put in a request for IPv4 numbers. 
 
IPv4 runout is more correctly defined as the day that the demand for IPv4
exceeds the supply.
But there will still be IPv4 handed out after that day.
 
This transfer proposal allows deep pockets to "cut" in front of that line,
post-runout.  Is that
fair to everyone else who is trying to wait patiently in line for numbering?
 
Imagine that movie ticket line if everyone was paying everyone else for a
chance to be the 3rd
guy in line.
 
It would resemble your typical line for something in Italy since the
Italians have no concept of
a queue, any time that tickets or anything restricted goes on sale there,
there's a mad rush
and everyone piles on, shoving to get to the front.
 
 
Ted
 
-----Original Message-----
From: Bill Darte [mailto:BillD at cait.wustl.edu] 
Sent: Monday, September 29, 2008 3:59 PM
To: Ted Mittelstaedt; David Williamson; Kevin Kargel
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



I would like to remind everyone that 2008-6 has as rationale....
Rationale:

In order for ARIN to fulfill its mission and to facilitate a continuing
supply of IPv4 address resources to its service community when ARIN
resources are no longer adequate, and to preserve the integrity of
documentation and ARIN services for those resources, this policy may be
implemented. Its intent is to preserve the current tradition of
need-based allocation/assignments for those still needing IPv4 resources
during a transition period as the industry adopts IPv6. This policy is not
intended to create a 'market' for such transfers and does not introduce or
condone the monetization of address resources or a view of addresses as
property. It does recognize that organizations making available unused or no
longer needed address resources may incur certain costs that might be
compensated by those acquiring the resources. This policy is intended to be
transient and light-weight and does not encourage a sustained or continuing
role for IPv4, but rather helps to mitigate a transitional crisis that may
emerge while the industry adopts IPv6 in accordance with the recommendation
of ARIN's Board of Trustees.

.....Creating a liberalized transfer policy is not the same as encouraging
the buying and selling of IP address resources.




-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Ted Mittelstaedt
Sent: Mon 9/29/2008 4:54 PM
To: 'David Williamson'; 'Kevin Kargel'
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



David and Bill Darte,

  I agree with Kevin and Michael, I am against paying for numbering
transfers.
However I will make the observation that I think David is correct that this
will
happen even if we don't want it to, and it will be black market.  HOWEVER
the point that seems to be missed is that if it does go black market, that
it WON'T HAPPEN until IPv4 runout actually occurs.

  Now is not the time to implement legalized transfers based on money
because if we do allow them or put language into the NPRM at this time
to permit them in the future, we are instantly creating business
justification
for investment in holding companies that do nothing other than lie, cheat
and
steal as much IPv4 as they can get BEFORE runout.  Meaning you will see a
flood
of ficticious requests for IPv4 numbering go into the RIR's pre-runout,
causing
runout to happen that much faster.

  I would prefer to wait until AFTER IPv4 runout, when there is actual
evidence
of black-market IPv4 transfers, THEN implement legalization.  Discuss it all
you want, but DON'T IMPLEMENT ANYTHING OF THE SORT AT THIS TIME.

  This policy is basically ASSUMING that unauthorized transfers are going to
happen and we need to regulate them now.  While we can suspect that they
will happen, and have a very STRONG guess that they will happen, suspicions
and strong guesses are NOT GROUNDS for policy.  With the upcoming POC
cleanup
proposals, we have PROOF that we have stale data in there due to the
number of Bitnet mail addresses discovered, thus policy is called for.  What
PROOF is there that money for IPv4 transfers at this time will help
anything?

  Has anyone ever bothered SURVEYING the existing
IPv4 holders to find out what percentage would even CONSIDER renumbering
should an IPv4 market appear?  And at what price point?

  The ONLY USE that liberalized transfer RIGHT NOW are for people who
are PLANNING on hoarding and going into business as IPv4 brokers.  They
are of no use to anyone else when ARIN still has IPv4 to hand out.

  We have enough work with making policy for things that we KNOW ARE
HAPPENING
RIGHT NOW.  For example, in the past some have asserted in this forum that
some of Dean Anderson's IP addresses are hijacked.  Has anything
been done to even investigate this?  And if it was investigated and
discovered
to be true, what mechanism exists to get them back?  Nothing!  THERE is
where
the policy blanks are that need filling in.

  We also have assertions that a number of IPv4 legacy blocks are
abandonded.  And
we have 2 proposals (mine one) that are tentative steps to discovering which
one of those blocks ARE abandonded.  We will need more policy and more
discussion
to work out a mechanism for ARIN to define abandonded legacy blocks and take
them
back.  Yet ANOTHER policy blank.

  I think it would be more fruitful to worry about making policy for
something
that is a problem right now, than for a problem we think we might possibly
have
a few years down the road.  It might be that in the process of cleaning up
messes like abandonded IPv4 that we will find that we have a lot more IPv4
than
anyone thought.

Ted

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/e1163d21/attachment.htm>

From scott.beuker at sjrb.ca  Mon Sep 29 18:53:04 2008
From: scott.beuker at sjrb.ca (Scott Beuker)
Date: Mon, 29 Sep 2008 16:53:04 -0600
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail>
	<20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
Message-ID: <46A2DD1223D7BF47B61799AFFBA8AD8902B0E55D@PRDCG4EXVW01-1.OSS.PRD>

Hi David,

I'm curious; when you envision a world with a transfer policy like
2008-6
in place, and total exhaustion from ARIN's standpoint, what do envision
the
ratio of buyers to sellers to be? 1:1? 10:1? Perhaps worse?

The problem I have with the idea that a liberal transfer policy is going
to
make address space available to my company, is I envision a world were
only
10% of the demand or less can be met. That's a pretty crazy sellers
market.
I doubt we'd be willing to pay through the nose to get it under such
circumstances in order to get such a scarce resource, and that means we
and another 90% would have accomplished nothing.

Taking that a step further, the question then becomes a little more
philosophical for me: If we're not going to be able to acquire any
address
space anyway, do we want to see those who were holding address space
they
didn't need this entire time financially rewarded for doing so?

Don't get me wrong, I'm still on the fence on this issue! But what I'm
trying to point out here is that while doing nothing is fairly obviously
not a solution, I think you'd have to be extremely optimistic about all
the address space that would come to market to think a liberal transfer
policy like 2008-6 does anything for the vast majority of us either.

Thanks,
Scott Beuker

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of David Williamson
> Sent: Monday, September 29, 2008 3:23 PM
> To: Kevin Kargel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
> Addresses
> 
> On Mon, Sep 29, 2008 at 04:14:34PM -0500, Kevin Kargel wrote:
> > YES!  People really are so worried about introducing money to the
> > transaction.
> >
> > I do not want to end up going to eBay for address space.
> 
> I'm not either, but as we run out of space, the choices seem, to me,
to
> be either eBay, or you just can't get it.  Given "pay" or "no", I
> choose the former...especially if the requests are getting properly
> examined by a third-party with an interest in efficientcy and validity
> of the transfer, and not the money involved, i.e., ARIN.
> 
> I'm also pretty certain the transfers for money will take place
whether
> we all like it or not.  I'd rather have it legitimized by ARIN, rather
> than a complete black market.
> 
> I really don't like it, but I don't see a practical alternative.
> Depending on the good will of those who have space and don't need it
> has never worked to well, in my opinion.
> 
> -David
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From bonomi at mail.r-bonomi.com  Mon Sep 29 19:54:57 2008
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Mon, 29 Sep 2008 18:54:57 -0500 (CDT)
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
Message-ID: <200809292354.m8TNsvrk016295@mail.r-bonomi.com>

> Date: Mon, 29 Sep 2008 16:14:34 -0500
> From: "Kevin Kargel" <kkargel at polartel.com>
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
>
>  
> YES!  People really are so worried about introducing money to the
> transaction.
>
> I do not want to end up going to eBay for address space.

What you want, and what you can have, are not necessarily the same thing.
<wry grin>

The buying and selling of IP address blocks has been going on for around
two decades, that _I_ know of.

Back then, such transactions were relatively infrequent, and involved fairly
large block of space.

The _only_ "unresolved" question today, is whether or not the RIRs are going
to be 'in the loop' for those transactions, *when* they occur.

If the RIRs _are_ in the loop, then the address-block assignment records that
the RIRs maintain will be "mostly" accurate, and the world at large will be
able to  tell "who" is using, and responsible for, activity from a particular
address-block.

If the RIRs are *NOT* in the loop, then what happens is that the RIR database
loses touch with reality.  "Name A" is on the books, but the address block
is actually being used by "Name B", "Name C", "Name D", and "Name G".  For
whom there is _no_ information whatsoever in the database.  Good luck 
contacting them when _you_ have a problem.

Things are _going_ to happen.   The question is whether there will be a
semblance of control, or not.






From tedm at ipinc.net  Mon Sep 29 20:20:07 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 29 Sep 2008 17:20:07 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087531C60@ex1.cait.wustl.edu>
Message-ID: <1A3D736692514D479DDA4CC1F61F6E62@tedsdesk>

The road to Hell is paved with good intentions, as well as "limited time
offers"
that were extended.
 
How many times was the "temporary IPv6 fee deferral" at ARIN extended until
they
finally decided to quit pretending it was temporary and normalized fees to
make
it one fee for IPv4/IPv6?  (effectively making IPv6 free)
 
The 3 year period is just getting the camels nose under the tent.  At the
end of
the 3 years the argument will be "nothing really bad happened so why are you
bitching about extending it" and everyone supporting this will conveniently
forget
the promises they implied that they would make sure it dies at the end of 3
years, and push to extend it for another 3 years.  Then 6 years from now the
argument will be that we extended it for 3 years and no problems, and the
push
will be to extend it again.  Eventually the argument will be, we have been
doing it
for so long, let's make it permanent.
 
If it's not good enough to be permanent, it's not good enough to even try
for 3 years.
 
I didn't say there would never be value in these kinds of efforts.  I said
that there
is no value NOW.  I would prefer we wait until value is apparent THEN talk
about
implementing something like this.
 
Ted

-----Original Message-----
From: Bill Darte [mailto:BillD at cait.wustl.edu] 
Sent: Monday, September 29, 2008 4:57 PM
To: Ted Mittelstaedt; David Williamson; Kevin Kargel
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



"for a period of 3 years" is also found at that URL....

It seeks to serve notice (once again) that these would be extraordinary
times...as determined by the BoT...and that such transfers will cease to be
'legitimate' thereafter.  Hopefully this signals folks and motivates them
toward v6.  But who knows?

2008-6 provides those who think something is necessary in transition a
mechanism to move in that direction.  It does announce its motivation and
what and its consistency with past tradition....helping others to swallow a
bitter pill perhaps.

To those like yourself who think there is no value in these efforts, it
affords nothing. 

Trying to convince 'me' doesn't afford much either, because the proposal is
not 'my' proposal, but one for the industry to consider.

Bill Darte
ARIN AC





-----Original Message-----
From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
Sent: Mon 9/29/2008 6:41 PM
To: Bill Darte; 'David Williamson'; 'Kevin Kargel'
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses

Bill,

The URL would be helpful:

http://www.arin.net/policy/proposals/2008_6.html

The problem is the line:  "transfer of ARIN IPv4 addresses between two
entities in the ARIN region, without the active involvement of ARIN as an
intermediary, will be considered legitimate"

  Have you ever stood in line for movie tickets?  I'm sure you have.

  When your standing there and there's 50 people in front of you, and
someone walks up and wants
to "take cuts" in front of the 3rd guy in line, the 3rd guy in line is not
going to let him unless he
gets paid.

  And everyone else waiting in line behind the 3rd guy ISN'T going to be
paid by the guy
taking "cuts" in front of the 3rd guy.  Naturally they are going to be a
little hot under the
collar.

This is a market.  You can play all the semantic games you want in the
policy proposal,
it's still a market.

After the very last IPV4 block is assigned from ARIN, the next day there may
be someone who
stops paying their bill, and their block goes back to ARIN.  ARIN will then
reassign it to the next
person who had put in a request for IPv4 numbers.

IPv4 runout is more correctly defined as the day that the demand for IPv4
exceeds the supply.
But there will still be IPv4 handed out after that day.

This transfer proposal allows deep pockets to "cut" in front of that line,
post-runout.  Is that
fair to everyone else who is trying to wait patiently in line for numbering?

Imagine that movie ticket line if everyone was paying everyone else for a
chance to be the 3rd
guy in line.

It would resemble your typical line for something in Italy since the
Italians have no concept of
a queue, any time that tickets or anything restricted goes on sale there,
there's a mad rush
and everyone piles on, shoving to get to the front.


Ted

-----Original Message-----
From: Bill Darte [mailto:BillD at cait.wustl.edu]
Sent: Monday, September 29, 2008 3:59 PM
To: Ted Mittelstaedt; David Williamson; Kevin Kargel
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



I would like to remind everyone that 2008-6 has as rationale....
Rationale:

In order for ARIN to fulfill its mission and to facilitate a continuing
supply of IPv4 address resources to its service community when ARIN
resources are no longer adequate, and to preserve the integrity of
documentation and ARIN services for those resources, this policy may be
implemented. Its intent is to preserve the current tradition of
need-based allocation/assignments for those still needing IPv4 resources
during a transition period as the industry adopts IPv6. This policy is not
intended to create a 'market' for such transfers and does not introduce or
condone the monetization of address resources or a view of addresses as
property. It does recognize that organizations making available unused or no
longer needed address resources may incur certain costs that might be
compensated by those acquiring the resources. This policy is intended to be
transient and light-weight and does not encourage a sustained or continuing
role for IPv4, but rather helps to mitigate a transitional crisis that may
emerge while the industry adopts IPv6 in accordance with the recommendation
of ARIN's Board of Trustees.

.....Creating a liberalized transfer policy is not the same as encouraging
the buying and selling of IP address resources.




-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Ted Mittelstaedt
Sent: Mon 9/29/2008 4:54 PM
To: 'David Williamson'; 'Kevin Kargel'
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



David and Bill Darte,

  I agree with Kevin and Michael, I am against paying for numbering
transfers.
However I will make the observation that I think David is correct that this
will
happen even if we don't want it to, and it will be black market.  HOWEVER
the point that seems to be missed is that if it does go black market, that
it WON'T HAPPEN until IPv4 runout actually occurs.

  Now is not the time to implement legalized transfers based on money
because if we do allow them or put language into the NPRM at this time
to permit them in the future, we are instantly creating business
justification
for investment in holding companies that do nothing other than lie, cheat
and
steal as much IPv4 as they can get BEFORE runout.  Meaning you will see a
flood
of ficticious requests for IPv4 numbering go into the RIR's pre-runout,
causing
runout to happen that much faster.

  I would prefer to wait until AFTER IPv4 runout, when there is actual
evidence
of black-market IPv4 transfers, THEN implement legalization.  Discuss it all
you want, but DON'T IMPLEMENT ANYTHING OF THE SORT AT THIS TIME.

  This policy is basically ASSUMING that unauthorized transfers are going to
happen and we need to regulate them now.  While we can suspect that they
will happen, and have a very STRONG guess that they will happen, suspicions
and strong guesses are NOT GROUNDS for policy.  With the upcoming POC
cleanup
proposals, we have PROOF that we have stale data in there due to the
number of Bitnet mail addresses discovered, thus policy is called for.  What
PROOF is there that money for IPv4 transfers at this time will help
anything?

  Has anyone ever bothered SURVEYING the existing
IPv4 holders to find out what percentage would even CONSIDER renumbering
should an IPv4 market appear?  And at what price point?

  The ONLY USE that liberalized transfer RIGHT NOW are for people who
are PLANNING on hoarding and going into business as IPv4 brokers.  They
are of no use to anyone else when ARIN still has IPv4 to hand out.

  We have enough work with making policy for things that we KNOW ARE
HAPPENING
RIGHT NOW.  For example, in the past some have asserted in this forum that
some of Dean Anderson's IP addresses are hijacked.  Has anything
been done to even investigate this?  And if it was investigated and
discovered
to be true, what mechanism exists to get them back?  Nothing!  THERE is
where
the policy blanks are that need filling in.

  We also have assertions that a number of IPv4 legacy blocks are
abandonded.  And
we have 2 proposals (mine one) that are tentative steps to discovering which
one of those blocks ARE abandonded.  We will need more policy and more
discussion
to work out a mechanism for ARIN to define abandonded legacy blocks and take
them
back.  Yet ANOTHER policy blank.

  I think it would be more fruitful to worry about making policy for
something
that is a problem right now, than for a problem we think we might possibly
have
a few years down the road.  It might be that in the process of cleaning up
messes like abandonded IPv4 that we will find that we have a lot more IPv4
than
anyone thought.

Ted

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/d5e1fb84/attachment.htm>

From tedm at ipinc.net  Mon Sep 29 20:23:14 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 29 Sep 2008 17:23:14 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <200809292354.m8TNsvrk016295@mail.r-bonomi.com>
Message-ID: <D33F05FE1D16492DAE79D3D09275A685@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert Bonomi
> Sent: Monday, September 29, 2008 4:55 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> for IPv4 Addresses
> 

> 
> If the RIRs are *NOT* in the loop, then what happens is that 
> the RIR database loses touch with reality.  "Name A" is on 
> the books, but the address block is actually being used by 
> "Name B", "Name C", "Name D", and "Name G".  For whom there 
> is _no_ information whatsoever in the database.  Good luck 
> contacting them when _you_ have a problem.
> 

Why is this a problem?

If the RIR can't contact them, then the block is determined to
be rogue and it becomes available for reassignment.

I cannot prevent people from squatting in that empty house down
the street but when property values go up I can buy that lot
and bulldoze the house and do what I want with the lot, and the
squatters will just have to kiss off.

Ted



From stephen at sprunk.org  Mon Sep 29 21:35:39 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 29 Sep 2008 20:35:39 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <D33F05FE1D16492DAE79D3D09275A685@tedsdesk>
References: <D33F05FE1D16492DAE79D3D09275A685@tedsdesk>
Message-ID: <48E1826B.4070405@sprunk.org>

Ted Mittelstaedt wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert Bonomi
>>     
>> If the RIRs are *NOT* in the loop, then what happens is that the RIR database loses touch with reality.  "Name A" is on the books, but the address block is actually being used by "Name B", "Name C", "Name D", and "Name G".  For whom there is _no_ information whatsoever in the database.  Good luck contacting them when _you_ have a problem.
>>     
>
> Why is this a problem?
>
> If the RIR can't contact them, then the block is determined to be rogue and it becomes available for reassignment.
>   

There is currently no policy that allows ARIN to make such a 
determination or invalidate an "abandoned" assignment for any reason 
other than non-payment of fees -- which most assignments are not subject 
to.  That was part of the original rationale for 2007-14, but so far it 
hasn't gained consensus.

> I cannot prevent people from squatting in that empty house down the street but when property values go up I can buy that lot and bulldoze the house and do what I want with the lot, and the squatters will just have to kiss off.
>   

That depends.  If they've been there long enough, they may be entitled 
to the land under "adverse possession" and the deed you paid for is 
worthless.

S


From bonomi at mail.r-bonomi.com  Mon Sep 29 22:04:01 2008
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Mon, 29 Sep 2008 21:04:01 -0500 (CDT)
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
Message-ID: <200809300204.m8U241Gm017605@mail.r-bonomi.com>

> From tedm at ipinc.net  Mon Sep 29 19:23:21 2008
> From: "Ted Mittelstaedt" <tedm at ipinc.net>
> To: "'Robert Bonomi'" <bonomi at mail.r-bonomi.com>, <arin-ppml at arin.net>
> Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
> Date: Mon, 29 Sep 2008 17:23:14 -0700
>
>
>
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert Bonomi
> > Sent: Monday, September 29, 2008 4:55 PM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> > for IPv4 Addresses
> > 
>
> > 
> > If the RIRs are *NOT* in the loop, then what happens is that 
> > the RIR database loses touch with reality.  "Name A" is on 
> > the books, but the address block is actually being used by 
> > "Name B", "Name C", "Name D", and "Name G".  For whom there 
> > is _no_ information whatsoever in the database.  Good luck 
> > contacting them when _you_ have a problem.
> > 
>
> Why is this a problem?

"You'll find out."  <wry grin>

> If the RIR can't contact them, then the block is determined to
> be rogue and it becomes available for reassignment.

Who said anything about the RIR not being ablet to contact
'Name A' the 'owner of record', as it were?

Name A _is_ contactable.  They just "don't care" what the people
they've "sold" the addresses to do with/from that space.

They take the attitude it isn't _their_ fault that the RIR database
isn't up to date -- it isn't *their* job, after all, to maintain it.



From mack at exchange.alphared.com  Mon Sep 29 22:14:51 2008
From: mack at exchange.alphared.com (mack)
Date: Mon, 29 Sep 2008 21:14:51 -0500
Subject: [arin-ppml] Transfer Proposals
In-Reply-To: <mailman.170263.1222734016.29428.arin-ppml@arin.net>
References: <mailman.170263.1222734016.29428.arin-ppml@arin.net>
Message-ID: <6F2FFD7C10F788479E354B84294036C459425B52@EXCH-MBX.exchange.alphared.local>

This is my $.02

The current proposals are flawed.
For most of us being able to execute a transfer is a breach of our current contract with ARIN.
The RSA most of us have signed says we have to return unused space if we no longer need it.
The only people who haven't signed such an RSA are the legacy holders.

A better proposal would be more similar to the radio frequency auctions.
Radio frequencies and IP addresses share a lot of similarities.
There are limits on their availability and they can only be used by one entity at a time in a given place.
For radio it is a geographic area.
For IP addresses it is the DFZ.
Not a perfect analogy but a lot better than the alternatives.

Ie. ARIN pays companies to return blocks and improve the efficiency of utilization.
Then auctions the blocks off to approved applicants.
Any 'profit' is used to create incentives for additional returns and/or IPv6.
This would maintain the non-profit status.

An alternative inverse would be to Auction off the rights to a returned block of given size.
Then offer 'rewards' for the return of blocks.
If no blocks are returned the winning bidder gets their money back.
If a smaller block is returned they get a portion back.
This would be repeated until everyone is happy or disillusioned enough to switch to IPv6.

--
LR Mack McBride
Network Administrator
Alpha Red, Inc.



From BillD at cait.wustl.edu  Mon Sep 29 22:44:11 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 29 Sep 2008 21:44:11 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
References: <1A3D736692514D479DDA4CC1F61F6E62@tedsdesk>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531C62@ex1.cait.wustl.edu>

Implementation is at the discretion of the Board and does not take place until they say that the situation warrants it.

Then, it is 3 years. But of course, if an extension were warranted then, the industry could make that decision as they will make this one.  It is all about consensus after all.

Not hard to be cynical in this world at this time, but reading the not so fine print actually makes sense.

bd


-----Original Message-----
From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
Sent: Mon 9/29/2008 7:20 PM
To: Bill Darte; 'David Williamson'; 'Kevin Kargel'
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
 
The road to Hell is paved with good intentions, as well as "limited time
offers"
that were extended.
 
How many times was the "temporary IPv6 fee deferral" at ARIN extended until
they
finally decided to quit pretending it was temporary and normalized fees to
make
it one fee for IPv4/IPv6?  (effectively making IPv6 free)
 
The 3 year period is just getting the camels nose under the tent.  At the
end of
the 3 years the argument will be "nothing really bad happened so why are you
bitching about extending it" and everyone supporting this will conveniently
forget
the promises they implied that they would make sure it dies at the end of 3
years, and push to extend it for another 3 years.  Then 6 years from now the
argument will be that we extended it for 3 years and no problems, and the
push
will be to extend it again.  Eventually the argument will be, we have been
doing it
for so long, let's make it permanent.
 
If it's not good enough to be permanent, it's not good enough to even try
for 3 years.
 
I didn't say there would never be value in these kinds of efforts.  I said
that there
is no value NOW.  I would prefer we wait until value is apparent THEN talk
about
implementing something like this.
 
Ted

-----Original Message-----
From: Bill Darte [mailto:BillD at cait.wustl.edu] 
Sent: Monday, September 29, 2008 4:57 PM
To: Ted Mittelstaedt; David Williamson; Kevin Kargel
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



"for a period of 3 years" is also found at that URL....

It seeks to serve notice (once again) that these would be extraordinary
times...as determined by the BoT...and that such transfers will cease to be
'legitimate' thereafter.  Hopefully this signals folks and motivates them
toward v6.  But who knows?

2008-6 provides those who think something is necessary in transition a
mechanism to move in that direction.  It does announce its motivation and
what and its consistency with past tradition....helping others to swallow a
bitter pill perhaps.

To those like yourself who think there is no value in these efforts, it
affords nothing. 

Trying to convince 'me' doesn't afford much either, because the proposal is
not 'my' proposal, but one for the industry to consider.

Bill Darte
ARIN AC





-----Original Message-----
From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
Sent: Mon 9/29/2008 6:41 PM
To: Bill Darte; 'David Williamson'; 'Kevin Kargel'
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses

Bill,

The URL would be helpful:

http://www.arin.net/policy/proposals/2008_6.html

The problem is the line:  "transfer of ARIN IPv4 addresses between two
entities in the ARIN region, without the active involvement of ARIN as an
intermediary, will be considered legitimate"

  Have you ever stood in line for movie tickets?  I'm sure you have.

  When your standing there and there's 50 people in front of you, and
someone walks up and wants
to "take cuts" in front of the 3rd guy in line, the 3rd guy in line is not
going to let him unless he
gets paid.

  And everyone else waiting in line behind the 3rd guy ISN'T going to be
paid by the guy
taking "cuts" in front of the 3rd guy.  Naturally they are going to be a
little hot under the
collar.

This is a market.  You can play all the semantic games you want in the
policy proposal,
it's still a market.

After the very last IPV4 block is assigned from ARIN, the next day there may
be someone who
stops paying their bill, and their block goes back to ARIN.  ARIN will then
reassign it to the next
person who had put in a request for IPv4 numbers.

IPv4 runout is more correctly defined as the day that the demand for IPv4
exceeds the supply.
But there will still be IPv4 handed out after that day.

This transfer proposal allows deep pockets to "cut" in front of that line,
post-runout.  Is that
fair to everyone else who is trying to wait patiently in line for numbering?

Imagine that movie ticket line if everyone was paying everyone else for a
chance to be the 3rd
guy in line.

It would resemble your typical line for something in Italy since the
Italians have no concept of
a queue, any time that tickets or anything restricted goes on sale there,
there's a mad rush
and everyone piles on, shoving to get to the front.


Ted

-----Original Message-----
From: Bill Darte [mailto:BillD at cait.wustl.edu]
Sent: Monday, September 29, 2008 3:59 PM
To: Ted Mittelstaedt; David Williamson; Kevin Kargel
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



I would like to remind everyone that 2008-6 has as rationale....
Rationale:

In order for ARIN to fulfill its mission and to facilitate a continuing
supply of IPv4 address resources to its service community when ARIN
resources are no longer adequate, and to preserve the integrity of
documentation and ARIN services for those resources, this policy may be
implemented. Its intent is to preserve the current tradition of
need-based allocation/assignments for those still needing IPv4 resources
during a transition period as the industry adopts IPv6. This policy is not
intended to create a 'market' for such transfers and does not introduce or
condone the monetization of address resources or a view of addresses as
property. It does recognize that organizations making available unused or no
longer needed address resources may incur certain costs that might be
compensated by those acquiring the resources. This policy is intended to be
transient and light-weight and does not encourage a sustained or continuing
role for IPv4, but rather helps to mitigate a transitional crisis that may
emerge while the industry adopts IPv6 in accordance with the recommendation
of ARIN's Board of Trustees.

.....Creating a liberalized transfer policy is not the same as encouraging
the buying and selling of IP address resources.




-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Ted Mittelstaedt
Sent: Mon 9/29/2008 4:54 PM
To: 'David Williamson'; 'Kevin Kargel'
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4
Addresses



David and Bill Darte,

  I agree with Kevin and Michael, I am against paying for numbering
transfers.
However I will make the observation that I think David is correct that this
will
happen even if we don't want it to, and it will be black market.  HOWEVER
the point that seems to be missed is that if it does go black market, that
it WON'T HAPPEN until IPv4 runout actually occurs.

  Now is not the time to implement legalized transfers based on money
because if we do allow them or put language into the NPRM at this time
to permit them in the future, we are instantly creating business
justification
for investment in holding companies that do nothing other than lie, cheat
and
steal as much IPv4 as they can get BEFORE runout.  Meaning you will see a
flood
of ficticious requests for IPv4 numbering go into the RIR's pre-runout,
causing
runout to happen that much faster.

  I would prefer to wait until AFTER IPv4 runout, when there is actual
evidence
of black-market IPv4 transfers, THEN implement legalization.  Discuss it all
you want, but DON'T IMPLEMENT ANYTHING OF THE SORT AT THIS TIME.

  This policy is basically ASSUMING that unauthorized transfers are going to
happen and we need to regulate them now.  While we can suspect that they
will happen, and have a very STRONG guess that they will happen, suspicions
and strong guesses are NOT GROUNDS for policy.  With the upcoming POC
cleanup
proposals, we have PROOF that we have stale data in there due to the
number of Bitnet mail addresses discovered, thus policy is called for.  What
PROOF is there that money for IPv4 transfers at this time will help
anything?

  Has anyone ever bothered SURVEYING the existing
IPv4 holders to find out what percentage would even CONSIDER renumbering
should an IPv4 market appear?  And at what price point?

  The ONLY USE that liberalized transfer RIGHT NOW are for people who
are PLANNING on hoarding and going into business as IPv4 brokers.  They
are of no use to anyone else when ARIN still has IPv4 to hand out.

  We have enough work with making policy for things that we KNOW ARE
HAPPENING
RIGHT NOW.  For example, in the past some have asserted in this forum that
some of Dean Anderson's IP addresses are hijacked.  Has anything
been done to even investigate this?  And if it was investigated and
discovered
to be true, what mechanism exists to get them back?  Nothing!  THERE is
where
the policy blanks are that need filling in.

  We also have assertions that a number of IPv4 legacy blocks are
abandonded.  And
we have 2 proposals (mine one) that are tentative steps to discovering which
one of those blocks ARE abandonded.  We will need more policy and more
discussion
to work out a mechanism for ARIN to define abandonded legacy blocks and take
them
back.  Yet ANOTHER policy blank.

  I think it would be more fruitful to worry about making policy for
something
that is a problem right now, than for a problem we think we might possibly
have
a few years down the road.  It might be that in the process of cleaning up
messes like abandonded IPv4 that we will find that we have a lot more IPv4
than
anyone thought.

Ted

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/448dcb20/attachment.htm>

From ray at snewisp.com  Mon Sep 29 22:42:43 2008
From: ray at snewisp.com (r ay)
Date: Mon, 29 Sep 2008 22:42:43 -0400
Subject: [arin-ppml] arin-ppml] Transfer Proposals
Message-ID: <WorldClient-F200809292242.AA42430120@snewisp.com>

That would likely result in the IP addresses bid up to and owned by like 2 
big 
providers, like FCC auctions. Great idea, but worth only $.02 unless you
are one of them.

Ray Weber
SNEWISP llc


> This is my $.02

>The current proposals are flawed.
For most of us being able to execute a transfer is a breach of our current 
contract with ARIN.
The RSA most of us have signed says we have to return unused space if we no 
longer need it.
The only people who haven't signed such an RSA are the legacy holders.

A better proposal would be more similar to the radio frequency auctions.
Radio frequencies and IP addresses share a lot of similarities.
There are limits on their availability and they can only be used by one 
entity at a time in a given place.
For radio it is a geographic area.
For IP addresses it is the DFZ.
Not a perfect analogy but a lot better than the alternatives.

Ie. ARIN pays companies to return blocks and improve the efficiency of 
utilization.
Then auctions the blocks off to approved applicants.
Any 'profit' is used to create incentives for additional returns and/or 
IPv6.
This would maintain the non-profit status.

An alternative inverse would be to Auction off the rights to a returned 
block of given size.
Then offer 'rewards' for the return of blocks.
If no blocks are returned the winning bidder gets their money back.
If a smaller block is returned they get a portion back.
This would be repeated until everyone is happy or disillusioned enough to 
switch to IPv6.

--
LR Mack McBride
Network Administrator
Alpha Red, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080929/1471c608/attachment.htm>

From stephen at sprunk.org  Tue Sep 30 01:33:39 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 30 Sep 2008 00:33:39 -0500
Subject: [arin-ppml] Transfer Proposals
In-Reply-To: <6F2FFD7C10F788479E354B84294036C459425B52@EXCH-MBX.exchange.alphared.local>
References: <mailman.170263.1222734016.29428.arin-ppml@arin.net>
	<6F2FFD7C10F788479E354B84294036C459425B52@EXCH-MBX.exchange.alphared.local>
Message-ID: <48E1BA33.7070601@sprunk.org>

mack wrote:
> This is my $.02
>
> The current proposals are flawed.
> For most of us being able to execute a transfer is a breach of our current contract with ARIN.
> The RSA most of us have signed says we have to return unused space if we no longer need it.
> The only people who haven't signed such an RSA are the legacy holders.
>   

I don't see where the RSA says that; ?8 does say that the holder must 
comply with policies, but policy only says that the resources must be 
"justified", not "needed".  If an org decides to free up some of its 
resources by becoming more efficient than policy requires (e.g. 
deploying NAT), there is also no policy that enables ARIN to take those 
addresses away -- and if there were, what motivation would folks have to 
incur those costs?  Part of the paid transfer idea is to financially 
motivate orgs to give unnecessary (but justified or legacy) resources to 
someone else who does actually need them.

S


From JOHN at egh.com  Tue Sep 30 01:28:50 2008
From: JOHN at egh.com (John Santos)
Date: Tue, 30 Sep 2008 01:28:50 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <0F1BDEC6418A435A9E9763AFAEFB73A8@tedsdesk>
Message-ID: <1080930011038.10334A@Ives.egh.com>


If there were a market in movie line positions, the 3rd guy in line could
sell his place.  This means the third guy would have to leave the line
(and go to the end), with the new guy taking his place.  The people after
the new guy would still be in the exact same place in line (4th through
50th.)  The guy who used to be 3rd would now be 51st.  This is like
trading a slot in a sports draft.

The situation you describe is totally different.  The 3rd guy is not only
selling his own place, he is also taking 4th place from the guy behind
him and giving him 5th place, which he took from the the guy 2 back, and
so on to the end of the line.  Everyone else loses one position, the 3rd
guy gains all the profit.  This isn't a market, this is theft.

In IP terms, it would be like someone selling a /24 out of everyone else's
allocation, I.E. selling something he didn't own.

I've read as many bogus analogies on this list as anywhere else on the
Internet, and far more than on most technical lists and news groups.
You would think that professionals dealing with a technical subject
would keep things on a higher plane.

(I don't care if a market is allowed or not, but I think it only makes
sense that if one develops, ARIN has some input to how it operates and
acts in some way to prevent egregious exploitation.)


-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

From mack at exchange.alphared.com  Tue Sep 30 02:15:33 2008
From: mack at exchange.alphared.com (mack)
Date: Tue, 30 Sep 2008 01:15:33 -0500
Subject: [arin-ppml] Transfer Proposals
In-Reply-To: <48E1BA33.7070601@sprunk.org>
References: <mailman.170263.1222734016.29428.arin-ppml@arin.net>
	<6F2FFD7C10F788479E354B84294036C459425B52@EXCH-MBX.exchange.alphared.local>
	<48E1BA33.7070601@sprunk.org>
Message-ID: <6F2FFD7C10F788479E354B84294036C459425B57@EXCH-MBX.exchange.alphared.local>

Wow, I did a closer read and you are correct.
There is nothing in either the policy manual or
the RSA that requires the return of unused resources
if they are justified and later not needed.

I am guessing the belief was that you will need them
sooner or later.

Section 8 implies you must use them for the purposes
outlined in your application but doesn't call for
revocation unless they are being used for purposes
other than what was intended, policy violations or
violations of the RSA.  It doesn't say anything about
unused resources.

--
LR Mack McBride
Network Administrator
Alpha Red, Inc.


> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org]
> Sent: Tuesday, September 30, 2008 12:34 AM
> To: mack; ARIN PPML
> Subject: Re: [arin-ppml] Transfer Proposals
>
> mack wrote:
> > This is my $.02
> >
> > The current proposals are flawed.
> > For most of us being able to execute a transfer is a breach of our
> current contract with ARIN.
> > The RSA most of us have signed says we have to return unused space if
> we no longer need it.
> > The only people who haven't signed such an RSA are the legacy
> holders.
> >
>
> I don't see where the RSA says that; ?8 does say that the holder must
> comply with policies, but policy only says that the resources must be
> "justified", not "needed".  If an org decides to free up some of its
> resources by becoming more efficient than policy requires (e.g.
> deploying NAT), there is also no policy that enables ARIN to take those
> addresses away -- and if there were, what motivation would folks have
> to
> incur those costs?  Part of the paid transfer idea is to financially
> motivate orgs to give unnecessary (but justified or legacy) resources
> to
> someone else who does actually need them.
>
> S

From lear at cisco.com  Tue Sep 30 04:39:50 2008
From: lear at cisco.com (Eliot Lear)
Date: Tue, 30 Sep 2008 10:39:50 +0200
Subject: [arin-ppml] On whether morality can be the lone argument against a
 transfer market (was Re: 2008-6: Emergency Transfer Policy for IPv4
 Addresses)
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail>	<20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>
Message-ID: <48E1E5D6.8010707@cisco.com>

Kevin,

You argued in essence that just because something is happening it should 
not be condoned.  That is a very fair argument.  However, it has to be 
balanced with ARIN's other priorities.  In this case, as has been 
repeatedly stated, if the regulatory authority and capability of ARIN is 
such that the transfers cannot be stopped, then the result will be that 
they will occur anyway, and that such transfers have a deleterious 
impact elsewhere.  Robert Bonomi's comments should not understated as a 
necessary function of ARIN when he wrote the following:
> The_only_  "unresolved" question today, is whether or not the RIRs are going
> to be 'in the loop' for those transactions,*when*  they occur.
>    
Here are three cases where accuracy matters:

    * Various law enforcement agencies and other parties seeking to
      either protect the public or to protect private rights need to be
      able to determine who is the responsible party for a given
      address, when it can be shown that it was involved in either a
      criminal or tortuous act.  The whois database plays a key role in
      providing those people information.  It is by no means perfect,
      and it is not the only means to provide the information, but it is
      never-the-less useful.  By encouraging people NOT to update the
      records through a black market, the database accuracy can and will
      degrade over time.
    * The ability to resolve legitimate disputes over address space is
      degraded when it can be shown that ARIN's records do not reflect
      reality.  If two customers attempt to use the same address space,
      service providers may or may not turn to ARIN to understand who
      owns the block.  And if they do, customers may be able to
      challenge ARIN to say that their record keeping is inaccurate.
    * Over the longer term, it should be possible to more tightly bind
      the routing system to the records found in the ARIN database. 
      This is, perhaps, what John Schnizlein referred to as
      "cryptographic saran-wrap", but could eliminate a form of attack
      that currently can be found on the Internet - the hijacking of
      prefixes for nefarious purposes.  Once again, in order for ARIN to
      perform this function, its database must be sufficiently accurate
      that the service providers believe they can trust the system. 
      Absent that trust it will be very difficult to secure the routing
      system as it is currently instantiated.

Does this mean that I believe IP transfer markets are appropriate?  Not 
necessarily.  I believe the impact of such markets is unclear.  What I 
am saying is that we need to balance the moral argument you are 
asserting against other legitimate social needs.  This is a very long 
form of demonstrating the law of unintended consequences.  Doing nothing 
will invoke this law.  So will doing something.  The choice is really 
which goal ARIN should aspire to achieve.

Regards,

Eliot Lear

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080930/cf55dfca/attachment.htm>

From michael.dillon at bt.com  Tue Sep 30 05:29:38 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 30 Sep 2008 10:29:38 +0100
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <200809292124.m8TLOVOp014756@mail.r-bonomi.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC085442E3@E03MVZ2-UKDY.domain1.systemhost.net>

> It is really quite simple.  
> 
> What is granted in a block assignment from a RIR  (or the 
> original DARPA
> address-coordinatior) is not 'ownership' of the addresses, 
> but just a "right to use" license for those integers in a 
> particular context.

Precisely!
The context is what is all-important. Read your RSA and the
ARIN policies to see what the context is and you will discover
that you do not, in fact, have a licence which you can buy
and sell. You must have technical justification for having those
IP addresses.

This whole issue is about how to deal with IPv4 addresses when
the demand for them is higher than the supply. The people in favor
of markets and eBay sales are essentially saying that we should
FAVOR the wealthiest ISPs. This is an auction model of allocation
in which the resources go to the highest bidder.

Complicating the whole situation is the fact that nobody really
needs IPv4 addresses any more. But since so few of the technical
people responsible for IP networks have experience with IPv6, they
fear it, and this fear drives people to delay the inevitable and 
to sweep problems under the carpet. How many of you know that there
are issues with IPv6 and load balancers? How many of you have taken
that issue to load balancer suppliers versus doing nothing?

> The *license* is, itself, "property", and  can bought and sold. 

If that were true then ARIN policy would be irrelevant.

> It is, arguably a 'derivative object', because it's existance 
> is derived from another thing.
> 
> It is not a "derivative instrument", because those things are 
> a 'contract to enter into a contract'.

Not according to Forbes Investopedia which has this to say:

In finance, a security whose price is dependent upon or derived from one
or more underlying assets. The derivative itself is merely a contract
between two or more parties. Its value is determined by fluctuations in
the underlying asset.

--Michael Dillon


From michael.dillon at bt.com  Tue Sep 30 06:40:13 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 30 Sep 2008 11:40:13 +0100
Subject: [arin-ppml] On whether morality can be the lone argument
	against a transfer market (was Re: 2008-6: Emergency Transfer
	Policy for IPv4 Addresses)
In-Reply-To: <48E1E5D6.8010707@cisco.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC085AA69B@E03MVZ2-UKDY.domain1.systemhost.net>

>By encouraging people NOT to update 
> the records through a black market, the database accuracy can 
> and will degrade over time.

If there is an address "owner" who is active enough to sell
IP addresses on the black market in such a way that the "buyer"
can successfully use them on the Internet, then there is a chain
that law enforcement can follow to find the bad guys. Not to
mention the fact, that there is an entirely separate chain
produced by BGP announcements and ISP contracts which does
not depend on whois data at all.

In addition, ARIN has invalidated black market transfers, most
notably earlier this year, and will no doubt continue to do
so. Your argument is simply not valid.

> *	The ability to resolve legitimate disputes over address 
> space is degraded when it can be shown that ARIN's records do 
> not reflect reality. 

That didn't seem to matter when someone rejuvenated two corporate
names that had gone defunct many years ago, in order to sell
address blocks. 

> If two customers attempt to use the 
> same address space, service providers may or may not turn to 
> ARIN to understand who owns the block.  And if they do, 
> customers may be able to challenge ARIN to say that their 
> record keeping is inaccurate.

Anyone can challenge ARIN, but the fact is that it is not ARIN
who does the recordkeeping in the whois directory, but the 
organizations who have been allocated address blocks. If they
choose to shoot themselves in the foot, they themselves
are to blame, not ARIN.

> *	Over the longer term, it should be possible to more 
> tightly bind the routing system to the records found in the 
> ARIN database.

That would be nice, and would in itself, make black market
transfers much harder.

>  What I am saying is that we need to 
> balance the moral argument you are asserting against other 
> legitimate social needs. 

It seems to me that legitimate social needs are better served
by deploying IPv6 instead of spending increasing amounts of money
on band-aid solutions to keep the IPv4 Internet functioning. We
know that things cannot go on as they are. We can choose to waste
money avoiding the inevitable or "you can rock out to it" and invest
your money in IPv6.

All the work that would go into creating a transfer market for IPv4
addresses, and the fees paid for those addresses, is all wasted money
because in the end, IPv6 will be the core Internet protocol.

--Michael Dillon




From chris.misztur at yahoo.com  Tue Sep 30 11:25:39 2008
From: chris.misztur at yahoo.com (chris mr)
Date: Tue, 30 Sep 2008 08:25:39 -0700 (PDT)
Subject: [arin-ppml] Policy Manual : Customer Privacy
Message-ID: <882063.93817.qm@web63707.mail.re1.yahoo.com>

I have to agree with Heather on this one.  

Unless the account holder is a business entity (separate from a person), the POC needs to be the upstream ISP.  Knowing a residential customer's IP block, name, address, and ISP can lead to all kinds of abuse issues.  This is no joke.



----- Original Message ----
From: heather skanks <heather.skanks at gmail.com>
To: chris mr <chris.misztur at yahoo.com>
Cc: arin-ppml at arin.net
Sent: Monday, September 29, 2008 4:05:50 PM
Subject: Re: [arin-ppml] Policy Manual : Customer Privacy


Automated provisioning systems ... did you think that someone generates all those millions of templates by hand?  :)

 --heather


On Sat, Sep 27, 2008 at 7:52 PM, chris mr <chris.misztur at yahoo.com> wrote:

Hello,

Reference: http://www.arin.net/policy/nrpm.html#four2376

I have recently noticed that ISPs such as ATT(SIS-80) and Comcast(CBCI) publish their customers' personal information in /29 reassignments.  For my residential DSL service I was told to contact ipadmin at att.com to hide my personal information, which they did.

What are your thoughts as to why ISPs do not protect their residential customers' privacy by default?

My thought on this subject is that ISPs still have the belief that Internet service with static IP blocks is only required by businesses, therefore ISPs fail to make the distinction between personal and business Internet accounts.

Chris



_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080930/0c2aee6b/attachment.htm>

From dlw+arin at tellme.com  Tue Sep 30 11:18:36 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Tue, 30 Sep 2008 08:18:36 -0700
Subject: [arin-ppml] On whether morality can be the lone argument
	against a transfer market (was Re: 2008-6: Emergency Transfer
	Policy for IPv4 Addresses)
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC085AA69B@E03MVZ2-UKDY.domain1.systemhost.net>
References: <48E1E5D6.8010707@cisco.com>
	<C0F2465B4F386241A58321C884AC7ECC085AA69B@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20080930151836.GR1271@shell02.cell.sv2.tellme.com>

On Tue, Sep 30, 2008 at 11:40:13AM +0100, michael.dillon at bt.com wrote:
> It seems to me that legitimate social needs are better served
> by deploying IPv6 instead of spending increasing amounts of money
> on band-aid solutions to keep the IPv4 Internet functioning. We
> know that things cannot go on as they are. We can choose to waste
> money avoiding the inevitable or "you can rock out to it" and invest
> your money in IPv6.

You are probably right on this point, but good stewardship does not
involve simply abandoning all responsibility for IPv4 resources once we
run out.  If the community wants good record keeping, ARIN should
remain involved until such time that IPv4 is more or less irrelevant.
If that means regulating a market for a short period of time, let's do
that.  It may not be the most efficient use of resources, but it may
also be the most effective form of stewardship for this set of number
resources.  I'd much prefer a concerted effort to deploy and transition
to IPv6, but I suspect the timeline is long enough for that work such
that IPv4 will still matter, even when the number space is fully
consumed.  That will then force the use of "band-aids".  C'est la vie.

-David


From pschopis at oar.net  Tue Sep 30 11:33:07 2008
From: pschopis at oar.net (Paul Schopis)
Date: Tue, 30 Sep 2008 11:33:07 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC085442E3@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC085442E3@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <E711D51C-722D-4E44-8A0C-9E12D276F52C@oar.net>

It seems to me we keep going in circles on the arguments of for or  
against adopting the policy. I am currently reading "Hot, Flat and  
Crowded" Thomas Friedman's new book. In it he argues one of the major  
crisis facing America and the world is a phenomena he refers to as  
"dumb as we want to be". It basically says we have lost the ability to  
face the big challenges and offers as an example (among others) the  
mortgage bailout. He claims we are selling off our grandchildren's  
future because we cannot get our own house in order.  In other words,  
we literally live like there is no tomorrow finding only temporary  
fixes because we refuse to deal with real issues.

It seems to me we are trying to create an artificial market out of a  
public resource, in which some will make a couple of bucks. The life  
of the market will be very limited and very few will benefit in my  
estimation because at the end of the day, IPv4 will run out. Demand  
will outstrip supply no matter how much money is involved.

I think that if as a community, we spent half as much time addressing  
how we get IPv6 deployed and operational as we are debating this band  
aide approach we would all be considerably better off.




From michael.dillon at bt.com  Tue Sep 30 11:42:59 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 30 Sep 2008 16:42:59 +0100
Subject: [arin-ppml] We want IPv6, not bandaids
In-Reply-To: <E711D51C-722D-4E44-8A0C-9E12D276F52C@oar.net>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC085AAC6D@E03MVZ2-UKDY.domain1.systemhost.net>

> I think that if as a community, we spent half as much time 
> addressing how we get IPv6 deployed and operational as we are 
> debating this band aide approach we would all be considerably 
> better off.

Yes.

ARIN has set up a wiki at http://www.getipv6.info where ISPs can
share notes on getting IPv6 deployed and operational. There really
should be more people contributing material to the wiki, but it does
have a lot of useful info from the ISP point of view, largely collected
from discussions on the NANOG mailing list.

Even lists of problems/issues, or questions about operational 
deployment would be useful contributions to the ARIN wiki.

--Michael Dillon


From bicknell at ufp.org  Tue Sep 30 11:49:46 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 30 Sep 2008 11:49:46 -0400
Subject: [arin-ppml] Transfer Proposals
In-Reply-To: <6F2FFD7C10F788479E354B84294036C459425B57@EXCH-MBX.exchange.alphared.local>
References: <mailman.170263.1222734016.29428.arin-ppml@arin.net>
	<6F2FFD7C10F788479E354B84294036C459425B52@EXCH-MBX.exchange.alphared.local>
	<48E1BA33.7070601@sprunk.org>
	<6F2FFD7C10F788479E354B84294036C459425B57@EXCH-MBX.exchange.alphared.local>
Message-ID: <20080930154946.GA23785@ussenterprise.ufp.org>

In a message written on Tue, Sep 30, 2008 at 01:15:33AM -0500, mack wrote:
> Wow, I did a closer read and you are correct.
> There is nothing in either the policy manual or
> the RSA that requires the return of unused resources
> if they are justified and later not needed.

http://www.faqs.org/rfcs/rfc2050.html

Section 3.1:

] IP addresses are valid as long as the criteria continues to be met.
] The IANA reserves the right to invalidate any IP assignments once it
] is determined the the requirement for the address space no longer
] exists.  In the event of address invalidation, reasonable efforts
] will be made by the appropriate registry to inform the organization
] that the addresses have been returned to the free pool of IPv4
] address space.

http://www.arin.net/policy/nrpm.html#four17

] 4.1.7. RFC 2050
] 
] ARIN takes guidance from allocation and assignment policies and
] procedures set forth in RFC 2050. These guidelines were developed to
] meet the needs of the larger Internet community in conserving scarce
] IPv4 address space and allowing continued use of existing Internet
] routing technologies.

http://www.arin.net/registration/agreements/rsa.pdf

] 7. POLICIES 
] 
] Pursuant to ARIN's Internet Resource Policy Evaluation Process
] ("IRPEP"), ARIN maintains the Policies and may amend the Policies,
] implement new policies (which once implemented, will be considered
] Policies), or make certain Policies obsolete. Applicant acknowledges
] and agrees it has read, understands, and agrees to be bound by and
] comply with the Policies, as amended.  ARIN may, at any time in its
] sole and absolute discretion, amend the Policies or create new
] Policies and such amendments or new Policies shall be binding upon
] Applicant immediately after they are posted on the Website.

RSA->Policies->2050->Unused IP allocations can be invalidated.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080930/52065a87/attachment.sig>

From cgrundemann at gmail.com  Tue Sep 30 14:59:15 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 30 Sep 2008 12:59:15 -0600
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877ADB27@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D030877ADB27@ex1.cait.wustl.edu>
Message-ID: <443de7ad0809301159k1c5920atf0f363fba7766d73@mail.gmail.com>

Comments on 2008-6:

0) Basic disclosure; I am still very much on the fence about a
liberalized transfer policy in general but I want to make sure that if
I do end up on the yes side of that fence, there is an acceptable
policy available =).

1) "For a period of 3 years from policy implementation, transfer of
ARIN IPv4 addresses between two entities in the ARIN region, without
the active involvement of ARIN as an intermediary, will be considered
legitimate and will be documented accordingly under the following
conditions:"
Does "without the active involvement of ARIN as an intermediary," mean
that if ARIN does act as an intermediary the transfer will not be
considered legitimate?  I believe this was explained previously to be
taken as a distinction from the current process of an organization
returning unneeded space to ARIN and that space being subsequently
allocated by ARIN to another organization.  In any case I find it
slightly confusing and unnecessary, maybe it is a quibble but I would
strike it.

2) I think that there should be one further condition added.  A
constraint on the transferor barring the transfer of recently acquired
IPv4.  I believe that this is a simple and necessary precaution
against pure IP dealers/speculators etc emerging and potentially
poisoning any legitimate market that does emerge.

3) In contrast to 2008-2, the benefit of this proposal is its
simplicity and the stated intention that it be held in reserve until
such time as the board deems it absolutely necessary (of course the
latter could easily be applied to 2008-2 as well).  Focusing on the
former; I believe that the simplicity is a benefit because if such a
time arises that the need for a more liberal transfer policy is
evident, that policy's effectiveness will hinge upon organizations
actually following it.  What I really don't want is a liberalized
transfer policy that is ignored in favor of a more efficacious black
market.

4) The negative is that I do see merit in most of the detailed
restrictions written into 2008-2 and I fear that should 2008-6 ever be
adopted the policy process may be too slow to react to problems that
arose in the created market.  At this time I feel that this negative
aspect is outweighed by the need to keep such a policy easy to follow
and by the fact that we really do not know what problems will need
addressing in an IP market so trying to address them all now may very
well be futile.

These comments are mine alone and are subject to change with or
without further notice  8-)
~Chris

On Mon, Sep 29, 2008 at 9:00 AM, Bill Darte <BillD at cait.wustl.edu> wrote:
> As the Oct 15 ARIN Public Policy Meeting comes closer, I would like to
> again ask anyone who has not commented (or sufficiently) on this policy
> proposal to do so.  Especially, I am interested in what you think are
> the positive or negative aspects of this proposal in contrast to 2008-2
> the more elaborate and detailed proposal.
>
> 2008-6 was promulgated as an alternative to 2008-6 for those who believe
> that 1./ a more liberal transfer policy is in the best interest of the
> industry and, 2./ feel that it would be easier to pass it and then
> modify it as needed in the future, should 2008-2 fail to gain consensus
> across all of its nuance.
>
> As always, I thank you for your involvement and insight into the policy
> evaluation process of ARIN.  Your participation makes the role of the AC
> much easier and the overall process more rigorous.
>
> Bill Darte
> ARIN Advisory Council
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
Chris Grundemann
www.linkedin.com/in/cgrundemann


From BillD at cait.wustl.edu  Tue Sep 30 15:51:49 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 30 Sep 2008 14:51:49 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <443de7ad0809301159k1c5920atf0f363fba7766d73@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D030877ADB27@ex1.cait.wustl.edu>
	<443de7ad0809301159k1c5920atf0f363fba7766d73@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030877ADBC4@ex1.cait.wustl.edu>

Thanks for being on topic with your response Chris.

You are correct....about ARIN as an intermediary.  Arin not a 'transfer
intermediary' is perhaps better....if at all.
 
bd
> -----Original Message-----
> From: Chris Grundemann [mailto:cgrundemann at gmail.com] 
> Sent: Tuesday, September 30, 2008 1:59 PM
> To: Bill Darte
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> for IPv4 Addresses
> 
> Comments on 2008-6:
> 
> 0) Basic disclosure; I am still very much on the fence about 
> a liberalized transfer policy in general but I want to make 
> sure that if I do end up on the yes side of that fence, there 
> is an acceptable policy available =).
> 
> 1) "For a period of 3 years from policy implementation, 
> transfer of ARIN IPv4 addresses between two entities in the 
> ARIN region, without the active involvement of ARIN as an 
> intermediary, will be considered legitimate and will be 
> documented accordingly under the following conditions:"
> Does "without the active involvement of ARIN as an 
> intermediary," mean that if ARIN does act as an intermediary 
> the transfer will not be considered legitimate?  I believe 
> this was explained previously to be taken as a distinction 
> from the current process of an organization returning 
> unneeded space to ARIN and that space being subsequently 
> allocated by ARIN to another organization.  In any case I 
> find it slightly confusing and unnecessary, maybe it is a 
> quibble but I would strike it.
> 
> 2) I think that there should be one further condition added.  
> A constraint on the transferor barring the transfer of 
> recently acquired IPv4.  I believe that this is a simple and 
> necessary precaution against pure IP dealers/speculators etc 
> emerging and potentially poisoning any legitimate market that 
> does emerge.
> 
> 3) In contrast to 2008-2, the benefit of this proposal is its 
> simplicity and the stated intention that it be held in 
> reserve until such time as the board deems it absolutely 
> necessary (of course the latter could easily be applied to 
> 2008-2 as well).  Focusing on the former; I believe that the 
> simplicity is a benefit because if such a time arises that 
> the need for a more liberal transfer policy is evident, that 
> policy's effectiveness will hinge upon organizations actually 
> following it.  What I really don't want is a liberalized 
> transfer policy that is ignored in favor of a more 
> efficacious black market.
> 
> 4) The negative is that I do see merit in most of the 
> detailed restrictions written into 2008-2 and I fear that 
> should 2008-6 ever be adopted the policy process may be too 
> slow to react to problems that arose in the created market.  
> At this time I feel that this negative aspect is outweighed 
> by the need to keep such a policy easy to follow and by the 
> fact that we really do not know what problems will need 
> addressing in an IP market so trying to address them all now 
> may very well be futile.
> 
> These comments are mine alone and are subject to change with 
> or without further notice  8-) ~Chris
> 
> On Mon, Sep 29, 2008 at 9:00 AM, Bill Darte 
> <BillD at cait.wustl.edu> wrote:
> > As the Oct 15 ARIN Public Policy Meeting comes closer, I 
> would like to 
> > again ask anyone who has not commented (or sufficiently) on this 
> > policy proposal to do so.  Especially, I am interested in what you 
> > think are the positive or negative aspects of this proposal in 
> > contrast to 2008-2 the more elaborate and detailed proposal.
> >
> > 2008-6 was promulgated as an alternative to 2008-6 for those who 
> > believe that 1./ a more liberal transfer policy is in the best 
> > interest of the industry and, 2./ feel that it would be 
> easier to pass 
> > it and then modify it as needed in the future, should 
> 2008-2 fail to 
> > gain consensus across all of its nuance.
> >
> > As always, I thank you for your involvement and insight into the 
> > policy evaluation process of ARIN.  Your participation 
> makes the role 
> > of the AC much easier and the overall process more rigorous.
> >
> > Bill Darte
> > ARIN Advisory Council
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> 
> 
> 
> --
> Chris Grundemann
> www.linkedin.com/in/cgrundemann
> 


From bonomi at mail.r-bonomi.com  Tue Sep 30 16:06:43 2008
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Tue, 30 Sep 2008 15:06:43 -0500 (CDT)
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
Message-ID: <200809302006.m8UK6hA0000721@mail.r-bonomi.com>

> Date: Tue, 30 Sep 2008 10:29:38 +0100
> From: <michael.dillon at bt.com>
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
>
> > It is really quite simple.  
> > 
> > What is granted in a block assignment from a RIR  (or the 
> > original DARPA
> > address-coordinatior) is not 'ownership' of the addresses, 
> > but just a "right to use" license for those integers in a 
> > particular context.
>
> Precisely!
> The context is what is all-important. Read your RSA and the
> ARIN policies to see what the context is and you will discover
> that you do not, in fact, have a licence which you can buy
> and sell. 

And the applicibility of any of that that to 'legacy' licensees is?

>           You must have technical justification for having those
> IP addresses.

>From early days, one had to have justification at the time the application
was made.  There was no requirement to return them if that justification
vanished.  "Polite", yes, but required, no.

As for the recipient of the transfer, ARIN can simply require that they
justify their need (to the same standard as a direct applicant would), 
_and_ sign a current RSA. before the license transfer is approved.

(Incidentally, note that this last pretty much prevents a recurring
 secondary market, because anybody that is covered by a modern RSA
 does have to give the license back to ARIN if it's not being used.
 and that would _include_ the "buyer" of a block. :)

> > The *license* is, itself, "property", and  can bought and sold. 
>
> If that were true then ARIN policy would be irrelevant.

Wrong.

ARIN (and predecessors) _issue_ the licenses, and thus control the terms,
*if*any*, under which it can be transferred, and to whom.

Note: for many years, there has been a substantial business in buying and 
      selling various kinds of licenses -- software, for example. (Or, in
      Illinois, truck-driving ones. :)

All 'post legacy' licenses are non-transferrable, in their entireity.

The status of legacy licenses is much less clear.

In _either_ case, *nothing* prevents the license-holder from delegating some
of that space to another party. Historically, such a delegation of address-
space has been done only with accompanying 'connectivity' service provisioning.
*BUT*, I can't see anything in the 'rules' that prohibits doing the former
_without_ the latter.  "Vice-versa" is _not_ uncommon.  I don't see anything
that prohibits a 'disjoint' use of address-space.

Whether or not 'transfers' are allowed will be absolutely irrelevant and 
immaterial.  If transfers are prohibited. then the 'seller' will simply
"rent" the block to the 'buyer', without including connectivity, but
including authoriztion for the 'provider of choice' of the 'buyer' to 
announce and route those addresses.  

One way or the other, it _will_ happen. *UNLESS* the _entire_ 'world' moves
to IPv6  before the IPv4 exhaustion point.

> > It is, arguably a 'derivative object', because it's existence 
> > is derived from another thing.
> > 
> > It is not a "derivative instrument", because those things are 
> > a 'contract to enter into a contract'.
>
> Not according to Forbes Investopedia which has this to say:
>
> In finance, a security whose price is dependent upon or derived from one
> or more underlying assets. The derivative itself is merely a contract
> between two or more parties. Its value is determined by fluctuations in
> the underlying asset.

By that definition, RIR 'licenses' are not derivitives. 

The underlying numbers are not assets. And the value of them does not fluctuate.

The value is entirely in the "right to use", and the "guarantee of uniqueness".

A 'lease' of the 'right to use' would be a derivitive.  A sale, or other
transfer would _not_.



From Daniel_Alexander at Cable.Comcast.com  Tue Sep 30 16:52:08 2008
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Tue, 30 Sep 2008 16:52:08 -0400
Subject: [arin-ppml] On whether morality can be the lone argumentagainst
	a transfer market (was Re: 2008-6: Emergency TransferPolicy
	for IPv4 Addresses)
In-Reply-To: <20080930151836.GR1271@shell02.cell.sv2.tellme.com>
References: <48E1E5D6.8010707@cisco.com><C0F2465B4F386241A58321C884AC7ECC085AA69B@E03MVZ2-UKDY.domain1.systemhost.net>
	<20080930151836.GR1271@shell02.cell.sv2.tellme.com>
Message-ID: <997BC128AE961E4A8B880CD7442D9480072E1F61@NJCHLEXCMB01.cable.comcast.com>


Suppose the RIRs implement policy to provide for existing and new
entrants, along the lines of prop-062 (use of final /8), or 2008-5
(Dedicated IPv4 block to facilitate IPv6 deployment), or some other
proposals that provides three to five years of IPv4 allocations from the
final /8 given to each Registry. 

Also suppose the IETF found it possible to create standards of some IPv4
to IPv6 translation mechanisms to provide communications between the
protocols. 

Some might be quick to dismiss this as impossible or improbable, but for
the sake of discussion, do you think the Internet would still need paid
transfers? 

-Dan 


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of David Williamson
Sent: Tuesday, September 30, 2008 11:19 AM
To: michael.dillon at bt.com
Cc: ppml at arin.net
Subject: Re: [arin-ppml] On whether morality can be the lone
argumentagainst a transfer market (was Re: 2008-6: Emergency
TransferPolicy for IPv4 Addresses)

On Tue, Sep 30, 2008 at 11:40:13AM +0100, michael.dillon at bt.com wrote:
> It seems to me that legitimate social needs are better served by 
> deploying IPv6 instead of spending increasing amounts of money on 
> band-aid solutions to keep the IPv4 Internet functioning. We know that

> things cannot go on as they are. We can choose to waste money avoiding

> the inevitable or "you can rock out to it" and invest your money in 
> IPv6.

You are probably right on this point, but good stewardship does not
involve simply abandoning all responsibility for IPv4 resources once we
run out.  If the community wants good record keeping, ARIN should remain
involved until such time that IPv4 is more or less irrelevant.
If that means regulating a market for a short period of time, let's do
that.  It may not be the most efficient use of resources, but it may
also be the most effective form of stewardship for this set of number
resources.  I'd much prefer a concerted effort to deploy and transition
to IPv6, but I suspect the timeline is long enough for that work such
that IPv4 will still matter, even when the number space is fully
consumed.  That will then force the use of "band-aids".  C'est la vie.

-David
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN
Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From kkargel at polartel.com  Tue Sep 30 17:09:53 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 30 Sep 2008 16:09:53 -0500
Subject: [arin-ppml] On whether morality can be the lone
	argumentagainsta transfer market (was Re: 2008-6: Emergency
	TransferPolicyfor IPv4 Addresses)
In-Reply-To: <997BC128AE961E4A8B880CD7442D9480072E1F61@NJCHLEXCMB01.cable.comcast.com>
References: <48E1E5D6.8010707@cisco.com><C0F2465B4F386241A58321C884AC7ECC085AA69B@E03MVZ2-UKDY.domain1.systemhost.net><20080930151836.GR1271@shell02.cell.sv2.tellme.com>
	<997BC128AE961E4A8B880CD7442D9480072E1F61@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B76@mail>

Sigh, the internet doesn't "need" paid transfers now, so then no, it would
not "still" need paid transfers.

Despite all the talk there is no forgone conclusion that a transfer policy
is a requirement.  To the contrary, the transfer policy talk is preventing
people from returning unused space.  Why would anyone surrender unneeded IP
space if there were a likelyhood or even a possibility that that space will
hold monetary value?  




> Some might be quick to dismiss this as impossible or 
> improbable, but for the sake of discussion, do you think the 
> Internet would still need paid transfers? 
> 
> -Dan 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080930/d5507f00/attachment.bin>

From sleibrand at internap.com  Tue Sep 30 17:19:09 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 30 Sep 2008 14:19:09 -0700
Subject: [arin-ppml] On whether morality can be the
 lone	argumentagainsta transfer market (was Re: 2008-6:
 Emergency	TransferPolicyfor IPv4 Addresses)
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B76@mail>
References: <48E1E5D6.8010707@cisco.com><C0F2465B4F386241A58321C884AC7ECC085AA69B@E03MVZ2-UKDY.domain1.systemhost.net><20080930151836.GR1271@shell02.cell.sv2.tellme.com>	<997BC128AE961E4A8B880CD7442D9480072E1F61@NJCHLEXCMB01.cable.comcast.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B76@mail>
Message-ID: <48E297CD.2030408@internap.com>

IPv4 space will hold monetary value after free pool exhaustion, whether or 
not there is a transfer policy.  Anyone holding IPv4 space will be able to 
rent it out.  They only need to SWIP it to the new holder to comply with 
ARIN policies.

-Scott

Kevin Kargel wrote:
> Sigh, the internet doesn't "need" paid transfers now, so then no, it would
> not "still" need paid transfers.
> 
> Despite all the talk there is no forgone conclusion that a transfer policy
> is a requirement.  To the contrary, the transfer policy talk is preventing
> people from returning unused space.  Why would anyone surrender unneeded IP
> space if there were a likelyhood or even a possibility that that space will
> hold monetary value?  
> 
> 
> 
> 
>> Some might be quick to dismiss this as impossible or 
>> improbable, but for the sake of discussion, do you think the 
>> Internet would still need paid transfers? 
>>
>> -Dan 
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.


From sleibrand at internap.com  Tue Sep 30 17:19:20 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 30 Sep 2008 14:19:20 -0700
Subject: [arin-ppml] Would paid transfers still be needed with IPv4-IPv6
	translation?
In-Reply-To: <997BC128AE961E4A8B880CD7442D9480072E1F61@NJCHLEXCMB01.cable.comcast.com>
References: <48E1E5D6.8010707@cisco.com><C0F2465B4F386241A58321C884AC7ECC085AA69B@E03MVZ2-UKDY.domain1.systemhost.net>	<20080930151836.GR1271@shell02.cell.sv2.tellme.com>
	<997BC128AE961E4A8B880CD7442D9480072E1F61@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <48E297D8.1000204@internap.com>

Alexander, Daniel wrote:
> Suppose the RIRs implement policy to provide for existing and new
> entrants, along the lines of prop-062 (use of final /8), or 2008-5
> (Dedicated IPv4 block to facilitate IPv6 deployment), or some other
> proposals that provides three to five years of IPv4 allocations from the
> final /8 given to each Registry. 
> 
> Also suppose the IETF found it possible to create standards of some IPv4
> to IPv6 translation mechanisms to provide communications between the
> protocols. 
> 
> Some might be quick to dismiss this as impossible or improbable, but for
> the sake of discussion, do you think the Internet would still need paid
> transfers? 

My answer would be a qualified yes.  No matter how good the translation 
mechanism is, it won't satisfy all need for IPv4 addresses during the 
transition.  (For example, translation may work very well for clients, but 
servers probably need a certain number of unique IPv4 addresses.)  In such 
a scenario, new market entrants would still need their own IPv4 addresses 
in order to provide Internet service to content providers.  Without a 
transfer policy, such new ISPs would have to settle for PA space (from an 
ISP or from some legacy holder who gets into the IP-renting business). 
That wouldn't be the end of the world, but it would be a good deal 
messier, IMO, than a straight transfer of space.

-Scott


From sleibrand at internap.com  Tue Sep 30 17:49:09 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 30 Sep 2008 14:49:09 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <443de7ad0809301159k1c5920atf0f363fba7766d73@mail.gmail.com>
References: <EACF8B735E9CBA4B8BAF9E4165D030877ADB27@ex1.cait.wustl.edu>
	<443de7ad0809301159k1c5920atf0f363fba7766d73@mail.gmail.com>
Message-ID: <48E29ED5.3010606@internap.com>

Chris Grundemann wrote:

> 3) In contrast to 2008-2, the benefit of this proposal is its
> simplicity and the stated intention that it be held in reserve until
> such time as the board deems it absolutely necessary (of course the
> latter could easily be applied to 2008-2 as well).  Focusing on the
> former; I believe that the simplicity is a benefit because if such a
> time arises that the need for a more liberal transfer policy is
> evident, that policy's effectiveness will hinge upon organizations
> actually following it.  What I really don't want is a liberalized
> transfer policy that is ignored in favor of a more efficacious black
> market.
> 
> 4) The negative is that I do see merit in most of the detailed
> restrictions written into 2008-2 and I fear that should 2008-6 ever be
> adopted the policy process may be too slow to react to problems that
> arose in the created market.  At this time I feel that this negative
> aspect is outweighed by the need to keep such a policy easy to follow
> and by the fact that we really do not know what problems will need
> addressing in an IP market so trying to address them all now may very
> well be futile.

I think the two points above illustrate a central tension in deciding how 
we want a transfer policy to look.  On the one hand, we have general 
agreement that each individual restriction in 2008-2 is merited.  On the 
other hand, there seems to be a general sense that, taken as a whole, 
2008-2 is still a little bit too detailed...

In light of that, the most recent version of 2008-2 has been simplified 
considerably.  I would love to hear feedback from the community as to 
whether we've achieved the right balance, or whether there are any 
restrictions that could be further simplified or removed to strike that 
balance.  Part of what we're trying to accomplish between now and the end 
of the public policy meeting in L.A. is to figure out where consensus lies 
  between 2008-2 and 2008-6...

Thanks,
Scott


From farmer at umn.edu  Tue Sep 30 19:30:50 2008
From: farmer at umn.edu (David Farmer)
Date: Tue, 30 Sep 2008 18:30:50 -0500
Subject: [arin-ppml] Transfer Proposals
In-Reply-To: <20080930154946.GA23785@ussenterprise.ufp.org>
References: <mailman.170263.1222734016.29428.arin-ppml@arin.net>,
	<6F2FFD7C10F788479E354B84294036C459425B57@EXCH-MBX.exchange.alphared.local>,
	<20080930154946.GA23785@ussenterprise.ufp.org>
Message-ID: <48E2705A.3236.50FE331@farmer.umn.edu>

On 30 Sep 2008 Leo Bicknell wrote:

...deleted...

> RSA->Policies->2050->Unused IP allocations can be invalidated.

Leo your logic is correct, as usual I believe.  

However, one would hope that an issues as important as this, "the return of 
resources", would be more directly dealt with in ARIN's Policies.  It could, 
and probably should, reference RFC 2050 section 3.1 for support.  But, I 
believe it is particularly important to raise the profile of this issue as we 
approach IPv4 Free Pool Exhaustion, especially if you are of the non-
liberalized transfer policy persuasion.
 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
 



=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================



From Daniel_Alexander at Cable.Comcast.com  Tue Sep 30 23:38:38 2008
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Tue, 30 Sep 2008 23:38:38 -0400
Subject: [arin-ppml] On whether morality can be the loneargumentagainsta
	transfer market (was Re: 2008-6: EmergencyTransferPolicyfor
	IPv4 Addresses)
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10B76@mail>
References: <48E1E5D6.8010707@cisco.com><C0F2465B4F386241A58321C884AC7ECC085AA69B@E03MVZ2-UKDY.domain1.systemhost.net><20080930151836.GR1271@shell02.cell.sv2.tellme.com><997BC128AE961E4A8B880CD7442D9480072E1F61@NJCHLEXCMB01.cable.comcast.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B76@mail>
Message-ID: <997BC128AE961E4A8B880CD7442D9480072E2048@NJCHLEXCMB01.cable.comcast.com>

Kevin,
 
"still or need" may have been a poor choice of words. I did not mean to
imply that paid transfers were a forgone conclusion. I was only trying
to direct the question to those who feel that paid transfers are
necessary, and whether they would still feel that way if the last RIR /8
was rationed for extending IPv4 allocations, AND a functional IPv4/IPv6
translator was available.

-Dan
 

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Kevin Kargel
Sent: Tuesday, September 30, 2008 5:10 PM
To: ppml at arin.net
Subject: Re: [arin-ppml] On whether morality can be the
loneargumentagainsta transfer market (was Re: 2008-6:
EmergencyTransferPolicyfor IPv4 Addresses)

Sigh, the internet doesn't "need" paid transfers now, so then no, it
would not "still" need paid transfers.

Despite all the talk there is no forgone conclusion that a transfer
policy is a requirement.  To the contrary, the transfer policy talk is
preventing people from returning unused space.  Why would anyone
surrender unneeded IP space if there were a likelyhood or even a
possibility that that space will hold monetary value?  




> Some might be quick to dismiss this as impossible or improbable, but 
> for the sake of discussion, do you think the Internet would still need

> paid transfers?
> 
> -Dan



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Alexander, Daniel
Sent: Tuesday, September 30, 2008 4:52 PM
To: David Williamson; michael.dillon at bt.com; ppml at arin.net
Subject: Re: [arin-ppml] On whether morality can be the lone
argumentagainsta transfer market (was Re: 2008-6: Emergency
TransferPolicyfor IPv4 Addresses)


Suppose the RIRs implement policy to provide for existing and new
entrants, along the lines of prop-062 (use of final /8), or 2008-5
(Dedicated IPv4 block to facilitate IPv6 deployment), or some other
proposals that provides three to five years of IPv4 allocations from the
final /8 given to each Registry. 

Also suppose the IETF found it possible to create standards of some IPv4
to IPv6 translation mechanisms to provide communications between the
protocols. 

Some might be quick to dismiss this as impossible or improbable, but for
the sake of discussion, do you think the Internet would still need paid
transfers? 

-Dan