From chris.misztur at yahoo.com  Wed Oct  1 01:21:38 2008
From: chris.misztur at yahoo.com (chris mr)
Date: Tue, 30 Sep 2008 22:21:38 -0700 (PDT)
Subject: [arin-ppml] Policy Manual : Customer Privacy
Message-ID: <826610.38655.qm@web63703.mail.re1.yahoo.com>

It is a very simple resolution, however most people are not aware that WHOIS databases exist.?

I still believe?non-business customers requesting a /29?CIDR should?be provided with a voluntary NDA regarding WHOIS.? For ONCE, can't we have a business that stands behing their customers!? 

?
From Comcast Website:
How does Comcast protect personally identifiable information?
We follow industry-standard practices to take such actions as are necessary to prevent unauthorized access to personally identifiable information by a person other than the subscriber or us.? However, we cannot guarantee that these practices will prevent every unauthorized attempt to access, use, or disclose personally identifiable information.?
?



----- Original Message ----
From: Kevin Kargel <kkargel at polartel.com>
To: chris mr <chris.misztur at yahoo.com>
Sent: Tuesday, September 30, 2008 11:05:00 AM
Subject: RE: [arin-ppml] Policy Manual : Customer Privacy


Of course it can lead to abuse issues.?It is also an easy resolution.? All the end user has to do is supply the ISP with the information they want to have associated with the WHOIS entry.? This can include a P.O. box, a cel phone., or they can have the ISP (for a fee?) hide the info behind the ISP.? 
?
Best practice for an ISP is to publish WHOIS data for static assignments.? This lets abuse forensics more easily track back to a malfunctioning or malicious machine, and perhaps the biggest reason is that it protects the ISP from the fallout of a misbehaving mail server by segregating the subnet from the ISP's email domain.? 
?
?


________________________________
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of chris mr
Sent: Tuesday, September 30, 2008 10:26 AM
To: heather skanks
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Manual : Customer Privacy


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.


      


From tvest at pch.net  Wed Oct  1 10:07:40 2008
From: tvest at pch.net (Tom Vest)
Date: Wed, 1 Oct 2008 10:07:40 -0400
Subject: [arin-ppml] On whether morality can be the lone argument
	against a transfer market (was Re: 2008-6:
	EmergencyTransferPolicyfor IPv4 Addresses)
In-Reply-To: <997BC128AE961E4A8B880CD7442D9480072E2048@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>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B76@mail>
	<997BC128AE961E4A8B880CD7442D9480072E2048@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <69BFB637-4973-4B90-A194-24F221FEF9AD@pch.net>

This thread is a complete red herring.
The question is not whether or not transfers are good or nice, but  
rather whether they'll work, and whether they'll be sustainable, and  
at what cost to everyone, participants and non-participants alike.

Many people thought that CIDR, aggregation, and route filtering -- the  
elements that made the RIR system "work" (i.e., rationalize demand for  
address resources and routing system capacity) -- were evil, because  
they reinforced customer-level "provider lock-in." That fact probably  
made it a bit easier for the largest operators at the time to sign  
onto the idea of RIRs in the first place. However, arguably, this  
"immoral" feature was counterbalanced by the fact that the system  
preserved openness at the routing service provider (including self- 
provider) level. So incumbents got something out of the deal, but so  
did everyone else -- or at least everyone else who was willing to buy  
a couple of routers and hire an engineer. That openness helped to  
assure that even those who didn't want to opt into the routing game  
would benefit indirectly from the continuous churn and competition  
that new entry *alone* permits.

Set aside the question of whether transfer markets will work or not.  
Ignore doubts about their technical sustainability. Even if the  
rosiest scenarios on these two counts come true, transfer markets will  
still undermine the interests of both "customers" and all future  
aspiring new entrants -- both of whom can look forward to a future  
with all of the downsides of PA and then some, and none of the benefits.

For that reason alone, the community should be seriously considering  
other approaches.

TV



  


From sleibrand at internap.com  Wed Oct  1 11:53:08 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 01 Oct 2008 08:53:08 -0700
Subject: [arin-ppml] On whether morality can be the lone argument
 against a transfer market
In-Reply-To: <69BFB637-4973-4B90-A194-24F221FEF9AD@pch.net>
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>	<997BC128AE961E4A8B880CD7442D9480072E2048@NJCHLEXCMB01.cable.comcast.com>
	<69BFB637-4973-4B90-A194-24F221FEF9AD@pch.net>
Message-ID: <48E39CE4.3060202@internap.com>

Tom,

You argue that the main benefit of the last system was that it allowed new 
entrants into the market.  How do you propose that we allow new entrants 
to the market after IPv4 exhaustion?  I would think that a transfer policy 
would help new entrants, as they would still be able to get their own PI 
space, through transfer, rather than being stuck with PA space from 
whatever provider still has addresses to rent.

The only other approaches I've seen any support for are rationing 
policies, whereby a block of addresses is reserved to allow new entrants 
to get at least a little bit of space.  I think such a policy is a good 
idea, but it only helps the smallest new entrants, or those who choose not 
to compete for customers requiring IPv4 space.  Therefore, I think a 
transfer policy is also needed to allow new entrants to acquire IPv4 space 
and compete in that market.

-Scott

Tom Vest wrote:
> This thread is a complete red herring.
> The question is not whether or not transfers are good or nice, but  
> rather whether they'll work, and whether they'll be sustainable, and  
> at what cost to everyone, participants and non-participants alike.
> 
> Many people thought that CIDR, aggregation, and route filtering -- the  
> elements that made the RIR system "work" (i.e., rationalize demand for  
> address resources and routing system capacity) -- were evil, because  
> they reinforced customer-level "provider lock-in." That fact probably  
> made it a bit easier for the largest operators at the time to sign  
> onto the idea of RIRs in the first place. However, arguably, this  
> "immoral" feature was counterbalanced by the fact that the system  
> preserved openness at the routing service provider (including self- 
> provider) level. So incumbents got something out of the deal, but so  
> did everyone else -- or at least everyone else who was willing to buy  
> a couple of routers and hire an engineer. That openness helped to  
> assure that even those who didn't want to opt into the routing game  
> would benefit indirectly from the continuous churn and competition  
> that new entry *alone* permits.
> 
> Set aside the question of whether transfer markets will work or not.  
> Ignore doubts about their technical sustainability. Even if the  
> rosiest scenarios on these two counts come true, transfer markets will  
> still undermine the interests of both "customers" and all future  
> aspiring new entrants -- both of whom can look forward to a future  
> with all of the downsides of PA and then some, and none of the benefits.
> 
> For that reason alone, the community should be seriously considering  
> other approaches.
> 
> TV
> 
> 
> 
>   
> _______________________________________________
> 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  Wed Oct  1 13:08:09 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 1 Oct 2008 18:08:09 +0100
Subject: [arin-ppml] On whether morality can be the lone argument
	against a transfer market
In-Reply-To: <48E39CE4.3060202@internap.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC0861F46F@E03MVZ2-UKDY.domain1.systemhost.net>


> You argue that the main benefit of the last system was that 
> it allowed new entrants into the market.  How do you propose 
> that we allow new entrants to the market after IPv4 
> exhaustion? 

This has now descended into the ridiculous.

It is not up to ARIN, or the network operator community,
or society, or the government, to preserve the market for
IPv4 data communication services. We've had a good run, but
obsolence was built into it from the very beginning. When
it is done, it is done and we all need to move on.

Some businesses will continue to find a niche market with
IPv4 for many years, and they are welcome to it. 

> I would think that a transfer policy would help 
> new entrants, as they would still be able to get their own PI 
> space, through transfer, rather than being stuck with PA 
> space from whatever provider still has addresses to rent.

When IPv4 is exhausted, new entrants can still get into the 
Internet business using IPv6. In fact, they may well have an
advantage over previous entrants in that they don't have all
the IPv4 baggage built into their systems and their processes.

People didn't moan about the death of IPX, DECNET and NETBEUI,
and suggest that we needed to take extraordinary measures to
preserve the use of those outdated protocols. We just moved 
on. Now it's time to say good-bye to IPv4 and plan for an
IPv6 future.

If the lack of IPv4 addresses materially damages someone's
business, two years from now, I can't imagine a judge awarding
then damages against ARIN. However I can imagine a judge throwing
them out of court on their ear with nothing to show for it.

--Michael Dillon



From tvest at pch.net  Wed Oct  1 15:10:39 2008
From: tvest at pch.net (Tom Vest)
Date: Wed, 1 Oct 2008 15:10:39 -0400
Subject: [arin-ppml] On whether morality can be the lone argument
	against a transfer market
In-Reply-To: <48E39CE4.3060202@internap.com>
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>	<997BC128AE961E4A8B880CD7442D9480072E2048@NJCHLEXCMB01.cable.comcast.com>
	<69BFB637-4973-4B90-A194-24F221FEF9AD@pch.net>
	<48E39CE4.3060202@internap.com>
Message-ID: <A63FCEB1-FE65-4D9E-8F36-3B9C36CC0610@pch.net>


On Oct 1, 2008, at 11:53 AM, Scott Leibrand wrote:

> Tom,
>
> You argue that the main benefit of the last system was that it  
> allowed new entrants into the market.


No I don't. I argue that the system that may now be in its last days  
worked for everybody. It made de facto global IP transit -- the one- 
stop shopping option for all customers and all non-DFZ routing service  
providers -- possible... and possible without closing the market to  
new entrants. That was a huge benefit for everybody, and huge benefit+  
for those who were/are able to sell domestic IP transit, and a huge  
benefit+++ for those able to sell international IP transit, which  
really was/is a historically unprecedented market opportunity.  
Technically, IP transit was/is a by-product of the "economies of  
scale" that were made possible by the combination of

+CIDR  -- which provided the basic tools.
+ top-level aggregation -- which the RIR community-system provided,  
and kept flexible over time as technology improved and RIR community  
practices changed.
+ filtering -- which was only commercially feasible because of the top- 
level aggregation made possible by the RIR system.
+ open entry for new routing service providers, which the arms-length  
RIR processes also enabled, and which effectively made aggregation and  
filtering "justifiable" and thus palatable to most direct  
stakeholders, as well as to the few indirect stakeholders/outside  
observer who knew that the system existed and understood the basics of  
how it worked.

That last "open entry" bit was what effectively made new markets --  
e.g., aspiring new RIR communities -- want to opt in to the growing  
system, and what encouraged national regulators, who were generally  
neither accustomed nor willing to abide that level of extra- 
territorial service delivery, to sit on their hands.

> How do you propose that we allow new entrants to the market after  
> IPv4 exhaustion?


I will spare the list another recital of details I've already shared  
several times.
I propose that we allow new entrants to the market after IPv4  
exhaustion by:

1. Preventing Pv4 exhaustion from happening for new entrants, through  
mechanisms like 2008-5 at minimum -- if not more vigorous initiatives  
like the scale-sensitive "contribution scheme" that I've suggested in  
the past.

2. Gradually reducing the non-substitutability / critical demand for  
IPv4 over time, e.g., through a commitment to rapid and ultimately  
universal dual-stacking of all "important" public-oriented Internet  
resources -- if not more vigorous initiatives like the scale-sensitive  
"contribution scheme" that I've suggested in the past.


> I would think that a transfer policy would help new entrants, as  
> they would still be able to get their own PI space, through  
> transfer, rather than being stuck with PA space from whatever  
> provider still has addresses to rent.


Is that really realistic? The current demand for transfer markets is a  
combination of some mixture of (a) incumbents who are apparently  
willing to spend a lot to delay or perhaps avoid IPv6 altogether, plus  
(b) surplus IPv4 holders who are not willing to part with their  
surplus resources unless/until someone pays them a lot to do it. As  
soon as a market is legitimized, they might or might not be joined by  
(c) other incumbents that are willing to cannibalize their own  
critical/production IPv4 assets, despite the uncertainty of the future  
IP addressing base, in order to secure a quick, one-time payout. They  
will almost certainly be joined by (d) new speculators who will be  
looking for every opportunity to buy early/cheap and hold out until  
they can sell at a much higher price.

Speculators are an intrinsic part of every market -- so those who  
imagine that they can somehow be avoided in this case should probably  
"get over it," as they say. But even if you manage to create the first  
speculation-free market in human history, I doubt that it will matter.  
Give (a+b), why should anyone assume that the "reservation price" for  
IPv4 transfers will actually be attainable for new entrants, much less  
be able to pass the anti-trust sniff test -- with or without any added  
speculation premium?


> The only other approaches I've seen any support for are rationing  
> policies, whereby a block of addresses is reserved to allow new  
> entrants to get at least a little bit of space.


If "rationing" means "more than you want," then we've been doing it  
for about 15 years. If it means "more than you need," then we haven't  
-- but only because we've been actively defining and redefining what  
"need" means on a rolling basis, in response to real changes (most of  
which we also *caused*) in the wider world. Given that long history of  
community awareness of and responsiveness to past real-world changes,  
the failure to even consider policy actions that might help to reduce  
the actual need for IPv4, for incumbents and especially for new  
entrants, is not confidence inspiring, to say the least.


> I think such a policy is a good idea, but it only helps the smallest  
> new entrants, or those who choose not to compete for customers  
> requiring IPv4 space.


One key rationale for the reservation policies is to make it at least  
theoretically possible for successive generations of new entrants to  
internalize their own IPv6-IPv4 translation requirements. That  way,  
maybe -- i.e., if the reservation is large enough to last for many  
decades and/or many many thousands of new entrants -- fewer current  
surplus IPv4 holders will hold out in anticipation of perpetual demand  
and ever-escalating prices for IPv4. Maybe, in combination, the  
greater (albeit limited) potential for IPv6-based market entry, plus  
the reduced certainty of big payoffs for continued strategic hoarding,  
will actually help to cause the "need" for IPv4 to diminish, after a  
long long time.


> Therefore, I think a transfer policy is also needed to allow new  
> entrants to acquire IPv4 space and compete in that market.


In an all-IPv4 Internet with no clear IPv6 migration strategy, IPv4 is  
the ultimate infrastructure bottleneck. It will be just like the last- 
mile facilities access plant, only ubiquitous, omni-directional, and  
impossible to bypass.

If you're suggesting that market transfers should be approved because  
they will enable future new entrants to buy in and actually compete in  
the wholesale-IPv4-mandatory services market against incumbents who  
got theirs effectively for free, then I strongly suggest that you  
think about how that notion actually has worked out in practice, e.g.,  
in the facilities-based Internet access business itself.

TV


> -Scott
>
> Tom Vest wrote:
>> This thread is a complete red herring.
>> The question is not whether or not transfers are good or nice, but   
>> rather whether they'll work, and whether they'll be sustainable,  
>> and  at what cost to everyone, participants and non-participants  
>> alike.
>> Many people thought that CIDR, aggregation, and route filtering --  
>> the  elements that made the RIR system "work" (i.e., rationalize  
>> demand for  address resources and routing system capacity) -- were  
>> evil, because  they reinforced customer-level "provider lock-in."  
>> That fact probably  made it a bit easier for the largest operators  
>> at the time to sign  onto the idea of RIRs in the first place.  
>> However, arguably, this  "immoral" feature was counterbalanced by  
>> the fact that the system  preserved openness at the routing service  
>> provider (including self- provider) level. So incumbents got  
>> something out of the deal, but so  did everyone else -- or at least  
>> everyone else who was willing to buy  a couple of routers and hire  
>> an engineer. That openness helped to  assure that even those who  
>> didn't want to opt into the routing game  would benefit indirectly  
>> from the continuous churn and competition  that new entry *alone*  
>> permits.
>> Set aside the question of whether transfer markets will work or  
>> not.  Ignore doubts about their technical sustainability. Even if  
>> the  rosiest scenarios on these two counts come true, transfer  
>> markets will  still undermine the interests of both "customers" and  
>> all future  aspiring new entrants -- both of whom can look forward  
>> to a future  with all of the downsides of PA and then some, and  
>> none of the benefits.
>> For that reason alone, the community should be seriously  
>> considering  other approaches.
>> TV
>>  _______________________________________________
>> 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  Wed Oct  1 15:58:42 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 1 Oct 2008 15:58:42 -0400
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: <7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>

Again with the equation of a simple, rational and not intrinsically
illegal or harmful economic transaction with harmful and exploitive
activities. This is just pure rhetoric. Please try to elevate your
discussion of the topic to an appropriate level. 

> -----Original Message-----
> 
>  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?
> 


From owen at delong.com  Wed Oct  1 16:17:08 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 1 Oct 2008 13:17:08 -0700
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: <94E95BBD-B0D4-4B8A-9B04-18F281A332C1@delong.com>


On Sep 30, 2008, at 2:29 AM, <michael.dillon at bt.com> wrote:

>> 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.
>
That simply isn't completely accurate.  There is no right to use
conveyed. ARIN specifically decries any guarantee of routability
of addresses, and, for any other purpose, ARIN does not have the
ability to give you any more right than anyone else.

All that IP assignments/allocations from ARIN grant is:

	1.	Neither ARIN nor any other cooperating RIR nor IANA
		will register the same set of integers to another party
		so long as your registration with ARIN remains valid.

	2.	ARIN will, in the in-addr.arpa nameservers place a
		delegation for the corresponding in-addr.arpa zone(s)
		which have NS records pointed at your chosen DNS servers.

	3.	ARIN will, in the whois database, display the registered
		contact information.

That's it. That's what you get.  No right to use. No property rights.
Nothing other than a registration.

It turns out that cooperating entities known as ISPs tend to use the
RIR databases as an authoritative source for who they wish to route
addresses for (this is not 100% true, however).  This can create
the illusion of a unique right to use, but, no such hard fact exists.

> 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?
>
Michael, until all of the sites people care about reaching are also
reachable by dual-stack, users will perceive a need for IPv4
addresses. Sure, in many cases, there are hacks and workarounds
that could provide for some form of NATPT or other partial
solution, but, none is 100% effective.

Additionally, until all of the eye-ball users have the ability to  
directly
reach sites via IPv6, site-owners will perceive a need for IPv4
in order to serve those customers.  Ih this context, no amount of
NATPT under the control of the site owner will replace the need
for IPv4 since the NATPT box would require IPv4 addresses
in order to do the translation.

>> The *license* is, itself, "property", and  can bought and sold.
>
> If that were true then ARIN policy would be irrelevant.
>
The *license* isn't a even a license let alone property.
It's a registration.

>> 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.
>
That would make all stock shares derivatives, so, I think Forbe's
definition is lacking.  Generally, derivatives are things like
options and futures where the value is determined by speculation
about the fluctuations in the value of the underlying contracts.

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/20081001/f0d32e0e/attachment.p7s>

From mueller at syr.edu  Wed Oct  1 16:21:51 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 1 Oct 2008 16:21:51 -0400
Subject: [arin-ppml] On whether morality can be the lone argumentagainst
	a transfer market
In-Reply-To: <A63FCEB1-FE65-4D9E-8F36-3B9C36CC0610@pch.net>
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>	<997BC128AE961E4A8B880CD7442D9480072E2048@NJCHLEXCMB01.cable.comcast.com><69BFB637-4973-4B90-A194-24F221FEF9AD@pch.net><48E39CE4.3060202@internap.com>
	<A63FCEB1-FE65-4D9E-8F36-3B9C36CC0610@pch.net>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9023C97A4@SUEXCL-02.ad.syr.edu>



> -----Original Message-----
> Behalf Of Tom Vest
> No I don't. I argue that the system that may now be in its last days
> worked for everybody. It made de facto global IP transit -- the one-
> stop shopping option for all customers and all non-DFZ routing service

Fine, but irrelevant. Those days were predicated on no scarcity of ipv4
addresses, and we do have scarcity. Useless to pine for the good old
days. 

> That last "open entry" bit was what effectively made new markets --
> e.g., aspiring new RIR communities -- want to opt in to the growing
> system, and what encouraged national regulators, who were generally
> neither accustomed nor willing to abide that level of extra-
> territorial service delivery, to sit on their hands.

National regulators sat on their hands for various reasons, but not
those. Mostly they had no idea what you were doing or how to intervene
in it. That, too, will end eventually. 

> 1. Preventing Pv4 exhaustion from happening for new entrants, through
> mechanisms like 2008-5 at minimum -- if not more vigorous initiatives
> like the scale-sensitive "contribution scheme" that I've suggested in
> the past.
> 
> 2. Gradually reducing the non-substitutability / critical demand for
> IPv4 over time, e.g., through a commitment to rapid and ultimately
> universal dual-stacking of all "important" public-oriented Internet
> resources -- if not more vigorous initiatives like the scale-sensitive
> "contribution scheme" that I've suggested in the past.

Both seem to me to be just fancy ways of denying that scarcity is a
fact. But it is a fact. By definition, when there is more demand for v4
addresses than there are addresses, you allocate them by voluntary,
user-driven transfer or by centralized command-transfers in which an
authority takes them away from one person and gives them to another. 

Or there are reservation policies. How far do you go with it? And what
criteria do you use to grant address blocks from the reserved space? 

Assume, e.g., that tomorrow ARIN says "no" to all requests for v4 except
those it deems "new entrants." At best, that just sets in motion a game
to present oneself as a "new entrant" to ARIN, and/or privileges
guesswork about the importance and economic viability of a "new
entrant's" plans over the demonstrated needs of "old entrants," which
might be just as valid. 

> Is that really realistic? The current demand for transfer markets is a
> combination of some mixture of (a) incumbents who are apparently
> willing to spend a lot to delay or perhaps avoid IPv6 altogether, plus
> (b) surplus IPv4 holders who are not willing to part with their
> surplus resources unless/until someone pays them a lot to do it. As
> soon as a market is legitimized, they might or might not be joined by
> (c) other incumbents that are willing to cannibalize their own
> critical/production IPv4 assets, despite the uncertainty of the future
> IP addressing base, in order to secure a quick, one-time payout. They
> will almost certainly be joined by (d) new speculators who will be
> looking for every opportunity to buy early/cheap and hold out until
> they can sell at a much higher price.

And so, at the VERY WORST, a transfer market will behave very much like
simple depletion of the v4 address pool. 

> 
> One key rationale for the reservation policies is to make it at least
> theoretically possible for successive generations of new entrants to
> internalize their own IPv6-IPv4 translation requirements. That  way,

Can you define a "new entrant" for us? A precise definition capable of
being operationalized? Anyway, just for the record I have no objection
to an addressing equivalent of the FCC's "pioneer's preference" band, so
that a small block of reserved addresses is allocated to some definition
of a new entrant that promises to do something innovative and useful
with it -- as long as a transfer policy is in place for the rest of the
v4 block. 

--MM



From owen at delong.com  Wed Oct  1 16:25:32 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 1 Oct 2008 13:25:32 -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: <48E1E5D6.8010707@cisco.com>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail>	<20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>
	<48E1E5D6.8010707@cisco.com>
Message-ID: <1AAA888C-F8D6-48CF-B26B-E5DCEA913C58@delong.com>


On Sep 30, 2008, at 1:39 AM, Eliot Lear wrote:

> 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.
1.	Prefix hijacking occurs today.
2.	Unauthorized transfers are, essentially a pathological case of  
prefix hijacking.
3.	If you can explain how the above three points are addressed for a  
hijacked prefix
	which was hijacked from a defunct resource holder, then, you have the  
exact
	answer needed for dealing with a black market.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081001/6fab04c4/attachment.htm>
-------------- 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/20081001/6fab04c4/attachment.p7s>

From kkargel at polartel.com  Wed Oct  1 16:27:04 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 1 Oct 2008 15:27:04 -0500
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>
	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10B81@mail>

 
My argument is no more rhetoric than "It's gonna happen anyway so we might
as well do it too.."

Just because someone else does something is not justification for everyone
to do it..

That is the most childish of reasoning and is used by six year olds
everywhere..

The sale of IP's is a harmful and/or exploitive activity.  Direct transfers
of IP addresses could prevent them from being available in the global pool.
Small consumers without deep pockets or not at favor with the trading
community will be at a distinct disadvantage.  Your small ISP could well
find itself without the possibility of even purchasing IP's at all because
the big corp that is holding them will only sell to partners and peers and
will withold them from anyone it deems a competitor or even an annoyance.
As an IP cable TV provider what do you think is going to happen when you go
to your competitor to purchase their "excess" IP's?

Do you claim that big businesses never do anything unfair or unethical so
that would never happen?

This is just one tiny example.  The direct transfer concept is rife with
ways that it could be abused.

There are already methods and policies giving methods for transfer of IP
addresses.  The ONLY difference is that the existing methods do not give the
surrenderor absolute control so they cannot demand money for the action.  

ARIN has in the past been very helpful and accomodating when one company
bought another.  IP blocks have been transferred to the new network owner.
There is no reason that this cooperation should change in the future.  




> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
> Sent: Wednesday, October 01, 2008 2:59 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2008-6: Emergency Transfer Policy 
> for IPv4 Addresses
> 
> Again with the equation of a simple, rational and not 
> intrinsically illegal or harmful economic transaction with 
> harmful and exploitive activities. This is just pure 
> rhetoric. Please try to elevate your discussion of the topic 
> to an appropriate level. 
> 
> > -----Original Message-----
> > 
> >  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?
> > 
> _______________________________________________
> 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/20081001/d98f383a/attachment.bin>

From Matthew.Wilder at telus.com  Wed Oct  1 16:32:08 2008
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Wed, 1 Oct 2008 14:32:08 -0600
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>
	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>

I was just on a trip in Europe, and I picked up a copy of the book "Undercover Economist", which was a phenomenal read, and one that made me passionate about free markets.  I even wondered if there was a place for applying the free market model (albeit a regulated one) in the world of IP Addressing.  Reason would suggest that the IP Addresses would go to the most deserving applications (financially anyway) since bidding would rise to the point where only the successful bidder of a resource is willing to pay.

Since considering this thought and trying to develop it out, I cannot reconcile multiple and very important issues.

1) Fairness:
The fundamental struggle of free markets is a tendency to drift away from fairness and toward efficiency.  In the case of introducing a free market to a resource that was never at any point intended to be a free market would introduce ridiculous unfairness, and result only in rewarding those who could be argued have been dishonest (apologies for the moral tone, but fairness requires some moral perspective).

2) Externality:
In economic terms, externality is the cost is incurred outside of a closed transaction.  Liberalized IP Address Transfer would result in considerable externality outside of the parties who transfer the resources.  Not to mention that there are at least two transfers in the case of successful brokerages who will firstly buy a resource, then secondly sell that resource off.  Or what if they buy a single /16 and split it up into 16 /20 subnet, which results in 17 transactions from one original resource, not to mention the routing table explosion it causes.  Will the bystanders be compensated for their incurred cost?

3) TRUE Efficiency:
The lobbyist for the liberalized transfer policy appeals to the ongoing ability of deserving organizations to procure IP Address space.  Perhaps the most significant misrepresentation here is the meaning of the word deserving.  Though it would imply the organization who can best justify the need for the addresses, it actually means the organization willing to fork out the most, which are two entirely different thing.  For example, consider who is most deserving between a non-profit internet society with hundreds of members versus a small accounting firm.

I believe that morality is a very reasonable basis for discussion, but that other arguments also challenge the reason behind a liberalized transfer policy.


-----Original Message-----

Milton Mueller wrote:

> Again with the equation of a simple, rational and not
> intrinsically illegal or harmful economic transaction
> with harmful and exploitive activities.
> This is just pure rhetoric. Please try to elevate your
> discussion of the topic to an appropriate level.

>> -----Original Message-----
>>
>>  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?
>>
_______________________________________________
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  Wed Oct  1 16:36:22 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 1 Oct 2008 13:36:22 -0700
Subject: [arin-ppml] Policy Manual : Customer Privacy
In-Reply-To: <882063.93817.qm@web63707.mail.re1.yahoo.com>
References: <882063.93817.qm@web63707.mail.re1.yahoo.com>
Message-ID: <7624211B-23BE-444B-80B6-F176202A43B8@delong.com>

I think this is not an area for policy.  Policy allows the ISP to  
choose their level
of protection for their customers as they see fit for their business.

Customers have the freedom to choose their ISP such that ISPs which do
not provide adequate protection probably lose customers.

ARIN allows for adequate protections if the ISP chooses to use them.   
It is not
ARIN's job to be the ISP behavior police.  At least not in this area.

Owen

On Sep 30, 2008, at 8:25 AM, chris mr wrote:

> 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.
>
>
> _______________________________________________
> 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/20081001/a385085e/attachment.htm>
-------------- 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/20081001/a385085e/attachment.p7s>

From info at arin.net  Wed Oct  1 17:11:34 2008
From: info at arin.net (Member Services)
Date: Wed, 01 Oct 2008 17:11:34 -0400
Subject: [arin-ppml] New Remote Participation Features at ARIN XXII
Message-ID: <48E3E786.90707@arin.net>

Even if you can?t be with us in LA, you don?t have to miss out on all 
the fun! Join us online by registering as a remote participant to take 
advantage of our improved options to participate in policy discussions 
and other meeting sessions included in the ARIN XXII webcast. Go to 
?Meeting Registration? at http://www.arin.net/ARIN-XXII/ and choose 
"ARIN XXII Remote Participant" from the drop-down.

Before you register as a remote meeting participant, make sure you have 
a Jabber Identfier (JID). You will need to provide your JID on the 
remote participation registration form in order to log in to the 
restricted meeting chats. To learn more about the ARIN meeting chats and 
available free Jabber services please go to:

www.arin.net/ARIN_XXII/remote.html

All remote participants are subject to the Remote Participation 
Acceptable Use Policy (AUP). Additional information about remote 
participation, including the Remote Participation AUP, is available at:

http://www.arin.net/ARIN-XXII/remote_aup.html

Be sure to download your participant?s packet to help you follow along 
with the meeting program, discussion guide, and other meeting support 
documents. Registration is not required to view the webcast or live 
transcript, but as a registered remote chat participant, you will be 
able to submit comments for moderated presentation during normal 
question and answer periods, and ?raise your hand? to be counted during 
polling.

You will also have full access to the popular Cyber Caf?, where you can 
connect with colleagues, access educational materials, and participate 
in daily meeting raffles to win fabulous prizes.

We will also have a live transcript to accompany the webcast to further 
enhance your remote meeting experience.

We look forward to your participation in ARIN XXII. Meeting details are 
available at http://www.arin.net/ARIN-XXII/.

We hope that the new features we are piloting at ARIN XXII will give you 
the full public policy meeting experience. Your post-meeting feedback 
will be critical as we evaluate the success of these enhancements.

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 info at arin.net  Wed Oct  1 17:25:34 2008
From: info at arin.net (Member Services)
Date: Wed, 01 Oct 2008 17:25:34 -0400
Subject: [arin-ppml] New Remote Participation Features at ARIN XXII
	(correction)
Message-ID: <48E3EACE.2090509@arin.net>

In our enthusiasm to share the news about our remote participation 
enhancements, a rather critical typographical error snuck through.  To 
learn more about the meeting chats and free Jabber services, you will 
need to go to:

http://www.arin.net/ARIN-XXII/remote.html

We apologize for any inconvenience.

Regards,

Member Services
The American Registry for Internet Numbers (ARIN)





From tvest at pch.net  Wed Oct  1 17:50:28 2008
From: tvest at pch.net (Tom Vest)
Date: Wed, 1 Oct 2008 17:50:28 -0400
Subject: [arin-ppml] On whether morality can be the lone argumentagainst
	a transfer market
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9023C97A4@SUEXCL-02.ad.syr.edu>
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>	<997BC128AE961E4A8B880CD7442D9480072E2048@NJCHLEXCMB01.cable.comcast.com><69BFB637-4973-4B90-A194-24F221FEF9AD@pch.net><48E39CE4.3060202@internap.com>
	<A63FCEB1-FE65-4D9E-8F36-3B9C36CC0610@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD9023C97A4@SUEXCL-02.ad.syr.edu>
Message-ID: <8BF2385B-06B5-4FF9-B8D8-305C133ACE79@pch.net>


On Oct 1, 2008, at 4:21 PM, Milton L Mueller wrote:

>> -----Original Message-----
>> Behalf Of Tom Vest
>> No I don't. I argue that the system that may now be in its last days
>> worked for everybody. It made de facto global IP transit -- the one-
>> stop shopping option for all customers and all non-DFZ routing  
>> service
>
> Fine, but irrelevant. Those days were predicated on no scarcity of  
> ipv4
> addresses, and we do have scarcity. Useless to pine for the good old
> days.

Perhaps you missed my point, or perhaps you simply accept it as  
inevitable:
De-facto global IP transit was an artifact of the system; as the  
system goes (away), so goes the service.

Could you confirm, or else clarify?

>> That last "open entry" bit was what effectively made new markets --
>> e.g., aspiring new RIR communities -- want to opt in to the growing
>> system, and what encouraged national regulators, who were generally
>> neither accustomed nor willing to abide that level of extra-
>> territorial service delivery, to sit on their hands.
>
> National regulators sat on their hands for various reasons, but not
> those. Mostly they had no idea what you were doing or how to intervene
> in it. That, too, will end eventually.


Of course you are right that general ignorance is no longer a fact.
However, I think that this has been true in many quarters for a while  
now.
In my experience, most national regulators actually like, perhaps even  
prefer self-governing industries -- so long as they're functional,  
which is to say that they keep direct stakeholders happy, satisfy  
external/indirect stakeholder needs, and don't run afoul of larger  
state interests. None of those criteria are optional.

if that were not true, I guess governments would own and operate  
everything.


>> 1. Preventing Pv4 exhaustion from happening for new entrants, through
>> mechanisms like 2008-5 at minimum -- if not more vigorous initiatives
>> like the scale-sensitive "contribution scheme" that I've suggested in
>> the past.
>>
>> 2. Gradually reducing the non-substitutability / critical demand for
>> IPv4 over time, e.g., through a commitment to rapid and ultimately
>> universal dual-stacking of all "important" public-oriented Internet
>> resources -- if not more vigorous initiatives like the scale- 
>> sensitive
>> "contribution scheme" that I've suggested in the past.
>
> Both seem to me to be just fancy ways of denying that scarcity is a
> fact.


Vert astute. I deny that scarcity is a fact. I assert that scarcity is  
a choice, and in this case one that markets will perpetuate rather  
than alleviate.
I assert that, in this case, the elimination of scarcity is not only  
an equally legitimate alternative, but that it's an absolutely better  
one -- not only for community members, but also for the people that  
won't be voting in two weeks, but who no doubt will be making their  
interests known sooner or later, depending on the outcome.

Note that I didn't say that it's an easy choice, or a free choice --  
just that it's never going to be any easier or cheaper than it is now.


> But it is a fact. By definition, when there is more demand for v4
> addresses than there are addresses, you allocate them by voluntary,
> user-driven transfer or by centralized command-transfers in which an
> authority takes them away from one person and gives them to another.

Milton, this is silly.
Credit is always scarce; that's a fact.
Does that fact mean that a stakeholder community has no interest in or  
business considering policies that could dramatically aggravate the  
consequences of that fact in the future? Selective myopia is not a  
credible option -- or at least I hope it's not.

> Or there are reservation policies. How far do you go with it? And what
> criteria do you use to grant address blocks from the reserved space?
>
> Assume, e.g., that tomorrow ARIN says "no" to all requests for v4  
> except
> those it deems "new entrants." At best, that just sets in motion a  
> game
> to present oneself as a "new entrant" to ARIN,

Either the community already has ways to deal with that, or else they  
will develop them, or else it will not work.
Nobody's advocating a beauty contest -- unless you want to dismiss the  
basic idea of "eligibility criteria" as everywhere and always a beauty  
contest.
In your own writings you claim that the system has worked "fairly  
well" up to know -- does this mean that you've changed your mind?

> and/or privileges
> guesswork about the importance and economic viability of a "new
> entrant's" plans over the demonstrated needs of "old entrants," which
> might be just as valid.


Most people are able to distinguish between a difference of degree and  
one of kind.
"Incrementally more expensive to grow my business, because I have to  
incorporate some IPv6" and "impossible to start a business at all" is  
a difference of kind that many people probably recognize, including  
would-be entrepreneurs, and most antitrust authorities.


>> Is that really realistic? The current demand for transfer markets  
>> is a
>> combination of some mixture of (a) incumbents who are apparently
>> willing to spend a lot to delay or perhaps avoid IPv6 altogether,  
>> plus
>> (b) surplus IPv4 holders who are not willing to part with their
>> surplus resources unless/until someone pays them a lot to do it. As
>> soon as a market is legitimized, they might or might not be joined by
>> (c) other incumbents that are willing to cannibalize their own
>> critical/production IPv4 assets, despite the uncertainty of the  
>> future
>> IP addressing base, in order to secure a quick, one-time payout. They
>> will almost certainly be joined by (d) new speculators who will be
>> looking for every opportunity to buy early/cheap and hold out until
>> they can sell at a much higher price.
>
> And so, at the VERY WORST, a transfer market will behave very much  
> like
> simple depletion of the v4 address pool.

In a way you're exactly right -- but only in the exact same way that a  
transfer market will behave very much like if the original legacy IPv4  
holders had delegated 100% of the entire IPv4 address pool to  
themselves in 1993, or the founding members of the RIR community had  
agreed that each of them would be permitted to originate two prefixes,  
and that henceforth the global routing table would be restricted to  
(2* #founding members) entries.

I'm glad they made other choices.


>> One key rationale for the reservation policies is to make it at least
>> theoretically possible for successive generations of new entrants to
>> internalize their own IPv6-IPv4 translation requirements. That  way,
>
> Can you define a "new entrant" for us? A precise definition capable of
> being operationalized?


I don't need to. Each RIR has its own criteria to distinguish between  
an "initial allocation" seeker and a "subsequent allocation" seeker.
APNIC addressed this question when they approved their "reservation"  
proposal last month, and concluded that established guidelines are  
good enough, for now.


> Anyway, just for the record I have no objection
> to an addressing equivalent of the FCC's "pioneer's preference"  
> band, so
> that a small block of reserved addresses is allocated to some  
> definition
> of a new entrant that promises to do something innovative and useful
> with it -- as long as a transfer policy is in place for the rest of  
> the
> v4 block.

The policies will stand or fall on their own -- but it's good that  
you've made your feelings clear.


TV



From mack at exchange.alphared.com  Wed Oct  1 22:15:46 2008
From: mack at exchange.alphared.com (mack)
Date: Wed, 1 Oct 2008 21:15:46 -0500
Subject: [arin-ppml] Transfer Proposals
In-Reply-To: <mailman.5.1222790401.18114.arin-ppml@arin.net>
References: <mailman.5.1222790401.18114.arin-ppml@arin.net>
Message-ID: <6F2FFD7C10F788479E354B84294036C459425BF4@EXCH-MBX.exchange.alphared.local>

This probably needs a statement from the ARIN legal counsel.

If the transfer policy would conflict with the existing RSA and
corresponding policies, that would need to be sorted out.
If RSA signers are required to return unused address space then
A transfer policy would only apply to legacy holders.

3.1 of 2050 seems to indicate that ARIN can revoke IPs if the
need no longer exists.

This does not cover the case of partial usage though.
2050 only requires a 25% immediate utilization rate for allocation.
and an estimate of 50% within a year.
It also states these are only guidelines.

The basic question is:

What level of utilization is necessary to prevent revocation and
are RSA signers required to return unused space at some level of
utilization if they will not need it within one year?

--
LR Mack McBride
Network Administrator
Alpha Red, Inc.


>
> Message: 6
> Date: Tue, 30 Sep 2008 11:49:46 -0400
> From: Leo Bicknell <bicknell at ufp.org>
> Subject: Re: [arin-ppml] Transfer Proposals
> To: ARIN PPML <ppml at arin.net>
> Message-ID: <20080930154946.GA23785 at ussenterprise.ufp.org>
> Content-Type: text/plain; charset="us-ascii"
>
> 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/



From sleibrand at internap.com  Thu Oct  2 01:02:28 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 01 Oct 2008 22:02:28 -0700
Subject: [arin-ppml] Transfer Proposals and 2007-14: Resource Review
In-Reply-To: <6F2FFD7C10F788479E354B84294036C459425BF4@EXCH-MBX.exchange.alphared.local>
References: <mailman.5.1222790401.18114.arin-ppml@arin.net>
	<6F2FFD7C10F788479E354B84294036C459425BF4@EXCH-MBX.exchange.alphared.local>
Message-ID: <48E455E4.1060108@internap.com>

ARIN will provide another legal review of all policies being considered at 
the L.A. meeting.  (2008-2 got one at Denver, as well.)  My understanding 
is that the RSA references ARIN policy, so if a transfer policy passes, 
whatever the new policy allows will be allowed by the RSA (by reference).

That does not, however, completely address the issues raised below, which 
have more to do with what type of reclamation is allowed and performed, 
orthogonal to any transfer policy.  That issue is being addressed through 
another policy proposal, 2007-14: Resource Review Process, which seeks to 
codify in policy how and when ARIN may review resource utilization, and 
what action it may take to request the return of or revoke under-utilized 
resources.

-Scott

mack wrote:
> This probably needs a statement from the ARIN legal counsel.
> 
> If the transfer policy would conflict with the existing RSA and
> corresponding policies, that would need to be sorted out.
> If RSA signers are required to return unused address space then
> A transfer policy would only apply to legacy holders.
> 
> 3.1 of 2050 seems to indicate that ARIN can revoke IPs if the
> need no longer exists.
> 
> This does not cover the case of partial usage though.
> 2050 only requires a 25% immediate utilization rate for allocation.
> and an estimate of 50% within a year.
> It also states these are only guidelines.
> 
> The basic question is:
> 
> What level of utilization is necessary to prevent revocation and
> are RSA signers required to return unused space at some level of
> utilization if they will not need it within one year?
> 
> --
> LR Mack McBride
> Network Administrator
> Alpha Red, Inc.
> 
> 
>> Message: 6
>> Date: Tue, 30 Sep 2008 11:49:46 -0400
>> From: Leo Bicknell <bicknell at ufp.org>
>> Subject: Re: [arin-ppml] Transfer Proposals
>> To: ARIN PPML <ppml at arin.net>
>> Message-ID: <20080930154946.GA23785 at ussenterprise.ufp.org>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> 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/
> 
> _______________________________________________
> 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  Thu Oct  2 13:58:45 2008
From: info at arin.net (Member Services)
Date: Thu, 02 Oct 2008 13:58:45 -0400
Subject: [arin-ppml] Reminder: Sign up for ARIN XXII Open Policy Hour
Message-ID: <48E50BD5.2090503@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 is the showroom for your policy ideas. Sign up by 
10 October to get your turn at 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.

Information on this and other sessions is available at:

http://www.arin.net/ARIN-XXII/agenda.html

Can?t join us in LA? No worries! Join us online via the webcast, live 
transcript, and moderated chat available at: 
http://www.arin.net/ARIN-XXII/remote.html


Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From info at arin.net  Fri Oct  3 14:16:47 2008
From: info at arin.net (Member Services)
Date: Fri, 03 Oct 2008 14:16:47 -0400
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation - Revised
Message-ID: <48E6618F.50103@arin.net>

The author submitted a revised version of the 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: Annual WHOIS POC Validation

Author: Chris Grundemann

Proposal Version: 2

Submission Date: 2 October 2008

Proposal type: new

Policy term: permanent

Policy statement:

ARIN will conduct POC validation annually.  This validation will
employ an automated system which will send a message to every separate
email address in the whois directory.  The message sent will request
that the receiver verify that they are in fact the POC in question by
replying to the email in a manner which will satisfy the automated
systems requirements.  The email message will also include information
and instructions for reporting suspected fraud.  If a valid response
is not received within the response period, every instance of the 
unresponsive
email address will be marked with "NO RESPONSE" in the whois
directory.  Expected transmission dates and sender email addresses will
be published as widely and be as readily available as is reasonable and
practical.

The list of POCs with this marking will be reviewed by ARIN staff and
manual contact attempts (telephone, postal mail) can be made at their
discretion.  After a minimum of three manual contact attempts have
been made, with at least one to each physical address and telephone
number provided and a minimum of three calendar months have passed
from the third qualifying attempt; the POC record should be locked or
deleted.  The decision of whether to lock or delete the account should
be made on a case by case basis.

Following this validation each year, a list of address blocks with
zero valid POCs should be made easily available to the community.
Accurate annual records should be kept with regard to the total number
of POCs, the number of POCs marked with "REFUSED RESPONSE," the number
of locked POCs and the number of deleted POCs in addition to any other
data that ARIN staff believes is appropriate to record with regard to
this validation process.  These records should be available to the
public on request.

Rationale:

The intention of this proposal is to ensure valid whois POC
information with an annual validation process.  It further aims to
mitigate any risk that it creates in so doing.

One of the most important resources when dealing with abuse (including
hijacking, spam, ddos, etc) is whois.  ARIN's whois data is only
useful if it is known to be valid.  The current NRPM does not address
this in a manner which ensures up to date POC contact information in
all cases.  The focus is on valid email addresses because this is the
contact method of choice for most in the Internet community when
dealing with abuse or hijacking issues.  POC information that can not
be confirmed can be judged as not valid.

A netblock with no valid POC presents a target to hijackers.  Once POC
info is marked or tagged as invalid (like this policy proposes), it
becomes possible for potential hijackers to locate such netblocks by
searching the whois database.  As a defense against such hijacking
attempts, this policy proposes that the information be presented in
full to the entire community.  This should do at least one of two
things; bring the netblock to the attention of whomever is responsible
for it and/or allow other network operators to understand the
potential risk and take appropriate action to mitigate.

Timetable for implementation: The first validation should take place
within one calendar year of the policy being accepted.










From cgrundemann at gmail.com  Fri Oct  3 14:49:51 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 3 Oct 2008 12:49:51 -0600
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation -
	Revised
In-Reply-To: <48E6618F.50103@arin.net>
References: <48E6618F.50103@arin.net>
Message-ID: <443de7ad0810031149m47b936fbqa750ea0f3cee3ab6@mail.gmail.com>

<Summary of changes in Version 2>

"...is not received within 's/14 days/the responce period/', every..."
Lets ARIN staff adjust the period year to year, based on the number of
false positives from the years before.

--

"...instance of the unresponsive email address will be
's/replaced/marked/' with..."
Allows the email address to remain in the database.  The policy leaves
implementation up to ARIN staff but I envision something similar to
John Santos' suggestion: "No response (was:
<original_e-mail_address>)"

--

"...with 's/"REFUSED RESPONSE"/"NO RESPONSE"/' in the whois directory."
Better reflects that a lack of response, not necessarily refusal, is
the trigger.

--

"Expected transmission dates and sender email addresses will
be published as widely and be as readily available as is reasonable and
practical."
This was added to help assist conscientious recipients in whitelisting
the messages (thanks to Eric Westbrook for the wording).

</changelog>

Thanks to everyone who commented on and critiqued the first version.

~Chris


On Fri, Oct 3, 2008 at 12:16 PM, Member Services <info at arin.net> wrote:
> The author submitted a revised version of the 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: Annual WHOIS POC Validation
>
> Author: Chris Grundemann
>
> Proposal Version: 2
>
> Submission Date: 2 October 2008
>
> Proposal type: new
>
> Policy term: permanent
>
> Policy statement:
>
> ARIN will conduct POC validation annually.  This validation will
> employ an automated system which will send a message to every separate
> email address in the whois directory.  The message sent will request
> that the receiver verify that they are in fact the POC in question by
> replying to the email in a manner which will satisfy the automated
> systems requirements.  The email message will also include information
> and instructions for reporting suspected fraud.  If a valid response
> is not received within the response period, every instance of the
> unresponsive
> email address will be marked with "NO RESPONSE" in the whois
> directory.  Expected transmission dates and sender email addresses will
> be published as widely and be as readily available as is reasonable and
> practical.
>
> The list of POCs with this marking will be reviewed by ARIN staff and
> manual contact attempts (telephone, postal mail) can be made at their
> discretion.  After a minimum of three manual contact attempts have
> been made, with at least one to each physical address and telephone
> number provided and a minimum of three calendar months have passed
> from the third qualifying attempt; the POC record should be locked or
> deleted.  The decision of whether to lock or delete the account should
> be made on a case by case basis.
>
> Following this validation each year, a list of address blocks with
> zero valid POCs should be made easily available to the community.
> Accurate annual records should be kept with regard to the total number
> of POCs, the number of POCs marked with "REFUSED RESPONSE," the number
> of locked POCs and the number of deleted POCs in addition to any other
> data that ARIN staff believes is appropriate to record with regard to
> this validation process.  These records should be available to the
> public on request.
>
> Rationale:
>
> The intention of this proposal is to ensure valid whois POC
> information with an annual validation process.  It further aims to
> mitigate any risk that it creates in so doing.
>
> One of the most important resources when dealing with abuse (including
> hijacking, spam, ddos, etc) is whois.  ARIN's whois data is only
> useful if it is known to be valid.  The current NRPM does not address
> this in a manner which ensures up to date POC contact information in
> all cases.  The focus is on valid email addresses because this is the
> contact method of choice for most in the Internet community when
> dealing with abuse or hijacking issues.  POC information that can not
> be confirmed can be judged as not valid.
>
> A netblock with no valid POC presents a target to hijackers.  Once POC
> info is marked or tagged as invalid (like this policy proposes), it
> becomes possible for potential hijackers to locate such netblocks by
> searching the whois database.  As a defense against such hijacking
> attempts, this policy proposes that the information be presented in
> full to the entire community.  This should do at least one of two
> things; bring the netblock to the attention of whomever is responsible
> for it and/or allow other network operators to understand the
> potential risk and take appropriate action to mitigate.
>
> Timetable for implementation: The first validation should take place
> within one calendar year of the policy being accepted.
>
>
>
>
>
>
>
>
> _______________________________________________
> 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 stephen at sprunk.org  Fri Oct  3 14:53:34 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 03 Oct 2008 13:53:34 -0500
Subject: [arin-ppml] Transfer Proposals
In-Reply-To: <20080930154946.GA23785@ussenterprise.ufp.org>
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>
	<20080930154946.GA23785@ussenterprise.ufp.org>
Message-ID: <48E66A2E.2040609@sprunk.org>

Leo Bicknell wrote:
> 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.
>   

The problem with that chain is that policy only claims "guidance" from 
RFC 2050; it isn't binding and we are free to directly contradict it if 
we so desire -- just like we ignored the IETF when adopting direct 
end-user assignments for IPv6.  It was a good starting point and a 
historical statement of intent that might be useful to staff (or, worst 
case, courts) when policy is ambiguous, but that's it.

I'll point out again that, when I put in an ACSP suggestion that ARIN 
start reclaiming unused space, the official answer was that ARIN _did 
not_ have the policy authority to do that.  OTOH, Steve Ryan has said 
ARIN has the contractual authority.  This disagreement is where my part 
of 2007-14 came from: I wanted a policy that clearly said ARIN did have 
the authority (which many of us previously assumed it already had, 
perhaps incorrectly), but to put some reasonable limits on its use.

S


From michael.dillon at bt.com  Sun Oct  5 04:47:42 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sun, 5 Oct 2008 09:47:42 +0100
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation
	-Revised
In-Reply-To: <443de7ad0810031149m47b936fbqa750ea0f3cee3ab6@mail.gmail.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08697510@E03MVZ2-UKDY.domain1.systemhost.net>

> <Summary of changes in Version 2>
> 
> "...is not received within 's/14 days/the responce period/', every..."
> Lets ARIN staff adjust the period year to year, based on the 
> number of false positives from the years before.

While I like sensible processes such as your proposed change,
I do not like the idea of ARIN policy containing such detailed
instructions to staff on something which really is irrelevant
to ARIN's mission.

Who really cares how ARIN staff makes the determination that
a Point Of Contact (POC) is no longer contactable?

Why couldn't a policy just mandate that ARIN staff verify,
annually, that Points Of Contact are indeed contactable
as advertised?

This type of micromanagement will kill the ARIN policy process 
because it draws attention away from things where a change in
policy could actually have a positive impact. Note that I am
in favor of mandating staff to verify POCs annually. I'm just 
not in favor of specifying any kind of detail in how they do
it. I trust that that the staff and the Board of Trustees can
understand plain English without having their workplans fed
to them in this level of detail.

--Michael Dillon


From cgrundemann at gmail.com  Sun Oct  5 10:37:54 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Sun, 5 Oct 2008 08:37:54 -0600
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation
	-Revised
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08697510@E03MVZ2-UKDY.domain1.systemhost.net>
References: <443de7ad0810031149m47b936fbqa750ea0f3cee3ab6@mail.gmail.com>
	<C0F2465B4F386241A58321C884AC7ECC08697510@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <443de7ad0810050737w3b3f7d69p3a8aba648dcdb124@mail.gmail.com>

So you would be more likely to support something along the lines of
the following?

ARIN will conduct WHOIS POC validation annually.  Unresponsive POC
email addresses should be marked as such in the database.  If ARIN
staff deems a POC to be completely and permanently abandoned or
otherwise illegitimate, the record should be locked or deleted.
Following this validation each year, a list of address blocks with
zero valid POCs should be made easily available to the community.

I wonder how others feel about this less operationally detailed verbiage?

~Chris


On Sun, Oct 5, 2008 at 2:47 AM,  <michael.dillon at bt.com> wrote:
>> <Summary of changes in Version 2>
>>
>> "...is not received within 's/14 days/the responce period/', every..."
>> Lets ARIN staff adjust the period year to year, based on the
>> number of false positives from the years before.
>
> While I like sensible processes such as your proposed change,
> I do not like the idea of ARIN policy containing such detailed
> instructions to staff on something which really is irrelevant
> to ARIN's mission.
>
> Who really cares how ARIN staff makes the determination that
> a Point Of Contact (POC) is no longer contactable?
>
> Why couldn't a policy just mandate that ARIN staff verify,
> annually, that Points Of Contact are indeed contactable
> as advertised?
>
> This type of micromanagement will kill the ARIN policy process
> because it draws attention away from things where a change in
> policy could actually have a positive impact. Note that I am
> in favor of mandating staff to verify POCs annually. I'm just
> not in favor of specifying any kind of detail in how they do
> it. I trust that that the staff and the Board of Trustees can
> understand plain English without having their workplans fed
> to them in this level of detail.
>
> --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.
>



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


From bonomi at mail.r-bonomi.com  Sun Oct  5 11:30:32 2008
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 5 Oct 2008 10:30:32 -0500 (CDT)
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation
	-Revised
Message-ID: <200810051530.m95FUW3K020295@mail.r-bonomi.com>

> Date: Sun, 5 Oct 2008 08:37:54 -0600
> From: "Chris Grundemann" <cgrundemann at gmail.com>
> Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation-Revised
>
> So you would be more likely to support something along the lines of
> the following?
>
> ARIN will conduct WHOIS POC validation annually.  Unresponsive POC
> email addresses should be marked as such in the database.  If ARIN
> staff deems a POC to be completely and permanently abandoned or
> otherwise illegitimate, the record should be locked or deleted.
> Following this validation each year, a list of address blocks with
> zero valid POCs should be made easily available to the community.
>
> I wonder how others feel about this less operationally detailed verbiage?

In broad, I like it a lot better.

I would, however, change the action verbs from advisory ("should") to
mandatory ("shall"), throughout.

I would also change the 1st statement to:

     Arin will validate each WHOIS POC at least annually.

Rationale: for a POC with which ARIN has had contact "recently", there is 
little to be gained by re-verifying the validity of that contact information.
Reducing the number of POCs that must be validated is obviously advantageous,
in that it reduces the workload.  

This proposed language also allows staff to verify _more_frequently_, if,
in their opinion, circumstances warrarnt it. And, those circumstances can
be evaluated on a case-by-case basis.




From sleibrand at internap.com  Sun Oct  5 12:23:06 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Sun, 05 Oct 2008 09:23:06 -0700
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC
	Validation	-Revised
In-Reply-To: <443de7ad0810050737w3b3f7d69p3a8aba648dcdb124@mail.gmail.com>
References: <443de7ad0810031149m47b936fbqa750ea0f3cee3ab6@mail.gmail.com>	<C0F2465B4F386241A58321C884AC7ECC08697510@E03MVZ2-UKDY.domain1.systemhost.net>
	<443de7ad0810050737w3b3f7d69p3a8aba648dcdb124@mail.gmail.com>
Message-ID: <48E8E9EA.30506@internap.com>

Chris,

I would be much more in favor of this sort of language than the more 
detailed requirements the current proposal.  If you have specific 
recommendations, you can always put those detailed examples in the 
Rationale as suggestions for implementation.  That makes sure they won't 
get lost amongst the PPML discussion, but also avoids cluttering up the 
policy manual.

Thanks,
Scott

Chris Grundemann wrote:
> So you would be more likely to support something along the lines of
> the following?
> 
> ARIN will conduct WHOIS POC validation annually.  Unresponsive POC
> email addresses should be marked as such in the database.  If ARIN
> staff deems a POC to be completely and permanently abandoned or
> otherwise illegitimate, the record should be locked or deleted.
> Following this validation each year, a list of address blocks with
> zero valid POCs should be made easily available to the community.
> 
> I wonder how others feel about this less operationally detailed verbiage?
> 
> ~Chris
> 
> 
> On Sun, Oct 5, 2008 at 2:47 AM,  <michael.dillon at bt.com> wrote:
>>> <Summary of changes in Version 2>
>>>
>>> "...is not received within 's/14 days/the responce period/', every..."
>>> Lets ARIN staff adjust the period year to year, based on the
>>> number of false positives from the years before.
>> While I like sensible processes such as your proposed change,
>> I do not like the idea of ARIN policy containing such detailed
>> instructions to staff on something which really is irrelevant
>> to ARIN's mission.
>>
>> Who really cares how ARIN staff makes the determination that
>> a Point Of Contact (POC) is no longer contactable?
>>
>> Why couldn't a policy just mandate that ARIN staff verify,
>> annually, that Points Of Contact are indeed contactable
>> as advertised?
>>
>> This type of micromanagement will kill the ARIN policy process
>> because it draws attention away from things where a change in
>> policy could actually have a positive impact. Note that I am
>> in favor of mandating staff to verify POCs annually. I'm just
>> not in favor of specifying any kind of detail in how they do
>> it. I trust that that the staff and the Board of Trustees can
>> understand plain English without having their workplans fed
>> to them in this level of detail.
>>
>> --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.
>>
> 
> 
> 


From michael.dillon at bt.com  Mon Oct  6 03:52:52 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 6 Oct 2008 08:52:52 +0100
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation
	-Revised
In-Reply-To: <443de7ad0810050737w3b3f7d69p3a8aba648dcdb124@mail.gmail.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC0869768C@E03MVZ2-UKDY.domain1.systemhost.net>

> So you would be more likely to support something along the 
> lines of the following?

Yes, and I tend to agree with Robert's comments on revised
wording as well.

--Michael Dillon


From jcurran at istaff.org  Mon Oct  6 09:25:19 2008
From: jcurran at istaff.org (John Curran)
Date: Mon, 6 Oct 2008 09:25:19 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>
	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>
	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>
	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
Message-ID: <B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>

On Oct 1, 2008, at 4:32 PM, Matthew Wilder wrote:
> ...
> 2) Externality:
> In economic terms, externality is the cost is incurred outside of a  
> closed transaction.  Liberalized IP Address Transfer would result in  
> considerable externality outside of the parties who transfer the  
> resources.  Not to mention that there are at least two transfers in  
> the case of successful brokerages who will firstly buy a resource,  
> then secondly sell that resource off.  Or what if they buy a single / 
> 16 and split it up into 16 /20 subnet, which results in 17  
> transactions from one original resource, not to mention the routing  
> table explosion it causes.  Will the bystanders be compensated for  
> their incurred cost?

Matthew -

    There's little doubt that in a perfect world, a free market will  
result in
    an efficient distribution of resources.  Of course, under such  
conditions,
    one could claim that a benevolent dictatorship or planned economy  
will also
    work just as well.

    The significant issue with straight free market approach to IP  
address
    distribution is precisely the externality point you cite above.   
At present,
    the actual cost incurred from making use of a particular address  
blocks is
    not clearly passed back to those receiving the benefit.  Making  
use of an
    IP address block in the public Internet requires routing it, and  
while this
    results in costs to every default-free network in the Internet,  
there is no
    system in place to provide settlement of these additional costs,  
and it is
    instead handled indirectly by providers through peering  
negotiations.

    Combine this with the underlying requirement of hierarchical  
assignment which
    allows Internet routing to work (to the extent that we call it  
"working" today)
    and we're got a system which can't survive deaggregation but lacks  
a working
    feedback mechanism back to those who wish to obtain (and route!) a  
very small
    but unique IPv4 address block.

    Turning on a free market for IPv4 address blocks requires some  
degrees of
    faith that the ISP community will either not allow use of smaller  
and smaller
    blocks or will quickly establish some corresponding system for  
settlement of
    resulting external routing costs.

/John
(my personal view only) 


From randy at psg.com  Mon Oct  6 09:27:56 2008
From: randy at psg.com (Randy Bush)
Date: Mon, 06 Oct 2008 06:27:56 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
Message-ID: <48EA125C.200@psg.com>

> The significant issue with straight free market approach to IP 
> address distribution is precisely the externality point you cite 
> above. At present, the actual cost incurred from making use of a 
> particular address blocks is not clearly passed back to those 
> receiving the benefit.  Making use of an IP address block in the 
> public Internet requires routing it, and while this results in costs 
> to every default-free network in the Internet, there is no system in 
> place to provide settlement of these additional costs, and it is 
> instead handled indirectly by providers through peering negotiations.

and this is not a problem if you get the space from an rir, only if you
buy it on an open market.  cool!

randy


From info at arin.net  Mon Oct  6 09:43:08 2008
From: info at arin.net (Member Services)
Date: Mon, 06 Oct 2008 09:43:08 -0400
Subject: [arin-ppml] Policy Proposal 2007-14 Discussed at ARIN Caribbean
	Sector Meeting
Message-ID: <48EA15EC.1040301@arin.net>

Policy Proposal 2007-14
Resource Review Process

On 17 September 2008 ARIN held a Public Policy Meeting at its Caribbean
Sector Meeting in Nassau, Bahamas, to discuss active policy proposals in
the ARIN region and gain a Caribbean perspective on ARIN policies and
procedures.

Leo Bicknell, as a representative of the ARIN Advisory Council,
presented the proposal and its rationale. Leo explained that this was a
recently revised version, incorporating feedback from previous ARIN
meetings. Leo explained that it clarified ARIN?s ability to do audits,
and at the same time limited ARIN to how often an audit could be
performed. A couple attendees expressed support for the proposal. The
Advisory Council received a report summarizing the policy discussion for
use in its deliberations.

Complete notes from the discussion about "Policy Proposal 2007-14:
Resource Review Process" are available at
http://www.arin.net/meetings/minutes/carib_fall_08/csm1_notes.html#anchor_7

The full report of that meeting, which includes presentations and
summary notes, is available on the ARIN website at
http://www.arin.net/meetings/minutes/carib_fall_08/csm.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From info at arin.net  Mon Oct  6 09:43:24 2008
From: info at arin.net (Member Services)
Date: Mon, 06 Oct 2008 09:43:24 -0400
Subject: [arin-ppml] Policy Proposal 2008-2 Discussed at ARIN Caribbean
	Sector Meeting
Message-ID: <48EA15FC.4060000@arin.net>

Policy Proposal 2008-2
IPv4 Transfer Policy Proposal

On 17 September 2008 ARIN held a Public Policy Meeting at its Caribbean
Sector Meeting in Nassau, Bahamas, to discuss active policy proposals in
the ARIN region and gain a Caribbean perspective on ARIN policies and
procedures.

Robert Seastrom, as a representative of the ARIN Advisory Council,
presented the proposal and its rationale. Robert provided background for
proposal. Meeting participants made comments about the pressure on the
routing table that this may cause and spoke about transition to IPv6.
Robert polled the attendees using the survey that was conducted on PPML.
The Advisory Council received a report summarizing the policy discussion
for use in its deliberations.

Complete notes from the discussion about " Policy Proposal 2008-2: IPv4
Transfer Policy Proposal" are available at
http://www.arin.net/meetings/minutes/carib_fall_08/csm1_notes.html#anchor_9

The full report of that meeting, which includes presentations and
summary notes, is available on the ARIN website at
http://www.arin.net/meetings/minutes/carib_fall_08/csm.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Mon Oct  6 09:43:39 2008
From: info at arin.net (Member Services)
Date: Mon, 06 Oct 2008 09:43:39 -0400
Subject: [arin-ppml] Policy Proposal 2008-3 Discussed at ARIN Caribbean
	Sector Meeting
Message-ID: <48EA160B.2040601@arin.net>

Policy Proposal 2008-3
Community Networks IPv6 Allocation

On 17 September 2008 ARIN held a Public Policy Meeting at its Caribbean
Sector Meeting in Nassau, Bahamas, to discuss active policy proposals in
the ARIN region and gain a Caribbean perspective on ARIN policies and
procedures.

Lea Roberts, as a representative of the ARIN Advisory Council, presented
the proposal and its rationale. Meeting participants pointed out that
the proposal text contains the term ?non-profit? which can have legal
consequences depending on the economy or country in question. After
being asked if the proposal text served the community networks in the
countries of the attendees, one attendee pointed out that ?200? can be a
very large number in regards to some of the islands in the Caribbean.
The Advisory Council received a report summarizing the policy discussion
for use in its deliberations.

Complete notes from the discussion about " Policy Proposal 2008-3:
Community Networks IPv6 Allocation" are available at
http://www.arin.net/meetings/minutes/carib_fall_08/csm1_notes.html#anchor_15

The full report of that meeting, which includes presentations and
summary notes, is available on the ARIN website at
http://www.arin.net/meetings/minutes/carib_fall_08/csm.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Mon Oct  6 09:44:03 2008
From: info at arin.net (Member Services)
Date: Mon, 06 Oct 2008 09:44:03 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 Discussed at ARIN Caribbean
	Sector Meeting
Message-ID: <48EA1623.9030504@arin.net>

Policy Proposal 2008-4
Minimum Allocation in the Caribbean Region

On 17 September 2008 ARIN held a Public Policy Meeting at its Caribbean
Sector Meeting in Nassau, Bahamas, to discuss active policy proposals in
the ARIN region and gain a Caribbean perspective on ARIN policies and
procedures.

Leo Bicknell, as a representative of the ARIN Advisory Council,
presented the proposal and its rationale. Meeting participants made
statements of support for the proposal. There was discussion about
allocations and assignments; most attendees were in favor of extending
the policy to include assignments. The Advisory Council received a
report summarizing the policy discussion for use in its deliberations.

Complete notes from the discussion about "Policy Proposal 2008-4:
Minimum Allocation in the Caribbean Region" are available at
http://www.arin.net/meetings/minutes/carib_fall_08/csm1_notes.html#anchor_16

The full report of that meeting, which includes presentations and
summary notes, is available on the ARIN website at
http://www.arin.net/meetings/minutes/carib_fall_08/csm.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Mon Oct  6 09:44:15 2008
From: info at arin.net (Member Services)
Date: Mon, 06 Oct 2008 09:44:15 -0400
Subject: [arin-ppml] Policy Proposal 2008-5 Discussed at ARIN Caribbean
	Sector Meeting
Message-ID: <48EA162F.80105@arin.net>

Policy Proposal 2008-5
Dedicated IPv4 block to facilitate IPv6 Deployment

On 17 September 2008 ARIN held a Public Policy Meeting at its Caribbean
Sector Meeting in Nassau, Bahamas, to discuss active policy proposals in
the ARIN region and gain a Caribbean perspective on ARIN policies and
procedures.

Stacy Hughes, as a representative of the ARIN Advisory Council,
presented the proposal and its rationale. Meeting participants suggested
that the /12 could come from any of ARIN?s address space (as opposed to
coming from the last /8). It was also suggested that the space for the
/12 should be identified and reserved now, instead of waiting for the
last /8. The Advisory Council received a report summarizing the policy
discussion for use in its deliberations.

Complete notes from the discussion about "Policy Proposal 2008-5:
Dedicated IPv4 block to facilitate IPv6 Deployment" are available at
http://www.arin.net/meetings/minutes/carib_fall_08/csm1_notes.html#anchor_6

The full report of that meeting, which includes presentations and
summary notes, is available on the ARIN website at
http://www.arin.net/meetings/minutes/carib_fall_08/csm.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Mon Oct  6 09:44:31 2008
From: info at arin.net (Member Services)
Date: Mon, 06 Oct 2008 09:44:31 -0400
Subject: [arin-ppml] Policy Proposal 2008-6 Discussed at ARIN Caribbean
	Sector Meeting
Message-ID: <48EA163F.8090209@arin.net>

Policy Proposal 2008-6
Emergency Transfer Policy for IPv4 Addresses

On 17 September 2008 ARIN held a Public Policy Meeting at its Caribbean
Sector Meeting in Nassau, Bahamas, to discuss active policy proposals in
the ARIN region and gain a Caribbean perspective on ARIN policies and
procedures.

Robert Seastrom, as a representative of the ARIN Advisory Council,
presented the proposal and its rationale. Robert explained how this
proposal is different from 2008-2. Several meeting participants made
statements of support for this more concise proposal over 2008-2. And
there was some discussion of address reclamation. The Advisory Council
received a report summarizing the policy discussion for use in its
deliberations.

Complete notes from the discussion about "Policy Proposal 2008-6:
Emergency Transfer Policy for IPv4 Addresses" are available at
http://www.arin.net/meetings/minutes/carib_fall_08/csm1_notes.html#anchor_10

The full report of that meeting, which includes presentations and
summary notes, is available on the ARIN website at
http://www.arin.net/meetings/minutes/carib_fall_08/csm.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)




From info at arin.net  Mon Oct  6 09:44:49 2008
From: info at arin.net (Member Services)
Date: Mon, 06 Oct 2008 09:44:49 -0400
Subject: [arin-ppml] Policy Proposal 2008-7 Discussed at ARIN Caribbean
	Sector Meeting
Message-ID: <48EA1651.30904@arin.net>

Policy Proposal 2008-7
Whois Integrity Policy Proposal

On 17 September 2008 ARIN held a Public Policy Meeting at its Caribbean
Sector Meeting in Nassau, Bahamas, to discuss active policy proposals in
the ARIN region and gain a Caribbean perspective on ARIN policies and
procedures.

Leo Bicknell, as a representative of the ARIN Advisory Council,
presented the proposal and its rationale. Some meeting participants
expressed statements of support for the proposal, saying that ARIN
should recoup costs for services, and in addition, ARIN should have
contracts with those it provides services to. Some meeting participants
stated their disfavor, saying that the intended outcome, better WHOIS
data, would not result. One attendee noted that the proposal seemed more
geared towards getting the RSA signed vs. WHOIS integrity. The Advisory
Council received a report summarizing the policy discussion for use in
its deliberations.

Complete notes from the discussion about "Policy Proposal 2008-7:
Whois Integrity Policy Proposal" are available at
http://www.arin.net/meetings/minutes/carib_fall_08/csm1_notes.html#anchor_11

The full report of that meeting, which includes presentations and
summary notes, is available on the ARIN website at
http://www.arin.net/meetings/minutes/carib_fall_08/csm.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)





From alain_durand at cable.comcast.com  Mon Oct  6 10:23:51 2008
From: alain_durand at cable.comcast.com (Alain Durand)
Date: Mon, 06 Oct 2008 10:23:51 -0400
Subject: [arin-ppml] Policy Proposal 2008-5 Discussed at ARIN
 CaribbeanSector Meeting
In-Reply-To: <48EA162F.80105@arin.net>
Message-ID: <C50F97B7.1B729%alain_durand@cable.comcast.com>

Clarification: 2008-5 proposes to set aside a /10, not a /12.

  - Alain.


On 10/6/08 9:44 AM, "Member Services" <info at arin.net> wrote:

> Policy Proposal 2008-5
> Dedicated IPv4 block to facilitate IPv6 Deployment
> 
> On 17 September 2008 ARIN held a Public Policy Meeting at its Caribbean
> Sector Meeting in Nassau, Bahamas, to discuss active policy proposals in
> the ARIN region and gain a Caribbean perspective on ARIN policies and
> procedures.
> 
> Stacy Hughes, as a representative of the ARIN Advisory Council,
> presented the proposal and its rationale. Meeting participants suggested
> that the /12 could come from any of ARIN?s address space (as opposed to
> coming from the last /8). It was also suggested that the space for the
> /12 should be identified and reserved now, instead of waiting for the
> last /8. The Advisory Council received a report summarizing the policy
> discussion for use in its deliberations.
> 
> Complete notes from the discussion about "Policy Proposal 2008-5:
> Dedicated IPv4 block to facilitate IPv6 Deployment" are available at
> http://www.arin.net/meetings/minutes/carib_fall_08/csm1_notes.html#anchor_6
> 
> The full report of that meeting, which includes presentations and
> summary notes, is available on the ARIN website at
> http://www.arin.net/meetings/minutes/carib_fall_08/csm.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> _______________________________________________
> 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  Mon Oct  6 10:25:59 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 6 Oct 2008 10:25:59 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <48EA125C.200@psg.com>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
Message-ID: <1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>




On Oct 6, 2008, at 9:27 AM, Randy Bush wrote:

>> The significant issue with straight free market approach to IP
>> address distribution is precisely the externality point you cite
>> above. At present, the actual cost incurred from making use of a
>> particular address blocks is not clearly passed back to those
>> receiving the benefit.  Making use of an IP address block in the
>> public Internet requires routing it, and while this results in costs
>> to every default-free network in the Internet, there is no system in
>> place to provide settlement of these additional costs, and it is
>> instead handled indirectly by providers through peering negotiations.
>
> and this is not a problem if you get the space from an rir, only if  
> you
> buy it on an open market.  cool!
>
> randy

That's right Randy. To recap from last week, what makes routing keep  
working under the current paradigm?

1. CIDR  -- which provides the basic tools.
2. Top-level aggregation -- which the RIR community-system provided,  
and kept flexible over time as technology improved and RIR community  
practices changed.
3. Filtering -- which was/is only commercially feasible because of the  
top-level aggregation made possible by the RIR community-system.
4. Open entry for new routing service providers, which the arms-length  
RIR processes also enabled, and which effectively made aggregation and  
filtering "justifiable" and thus palatable to most direct  
stakeholders, as well as to the few indirect stakeholders/outside  
observer who knew that the system existed and understood the basics of  
how it worked.

An uncoordinated market will eliminate (2), which will make (3,4)  
impossible, which will cause the current routing paradigm to fail in  
short order.

Maybe a routing cartel will emerge in time to solve the problem,  
without creating new problems for aspiring new entrants and the ever  
widening audience of attentive external stakeholders. But that's a big  
leap of faith...

TV










From randy at psg.com  Mon Oct  6 10:50:02 2008
From: randy at psg.com (Randy Bush)
Date: Mon, 06 Oct 2008 07:50:02 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
Message-ID: <48EA259A.3080705@psg.com>

crock.  whether i get the address space i need from an rir or the market
it's the same address space and i announce it.

and if you think that, three years from now, the rirs will have larger
blocks to sell than the open market, please share what you're smoking.

and perhaps you have not read any of the routing table analyses.  we
have already lost the routing table battle.  it's over 50% crap.

randy


From schnizlein at isoc.org  Mon Oct  6 11:12:32 2008
From: schnizlein at isoc.org (John Schnizlein)
Date: Mon, 6 Oct 2008 11:12:32 -0400
Subject: [arin-ppml] uncoordinated market for IPv4 addresses will cause
	routing failure
In-Reply-To: <1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
Message-ID: <FA22A142-2812-4AE5-B15F-9CF7BED78772@isoc.org>

Changed the subject because this applies to any transfer policy.

I have been looking for justification of a managed market specifically  
based on the need to preserve (somewhat) the hierarchy of addresses  
within the global route table.  If arbitrary transfers would  
significantly scramble the routing tables, that would seem to justify  
undertaking the challenge of operating a market maker.  In such an  
approach, asks and bids would be cleared so that the particular  
address block allocated would better fit the routing hierarchy than  
random (uncoordinated) allocations.  Setting up such a market maker is  
not a trivial undertaking, and would concentrate questions about  
fairness on the market operator, rather than distributing them among  
the parties involved in transfers.

What I have heard is that the fragmentation of global routing due to  
traffic engineering and multihoming has already scrambled things  
enough that random transfers is not likely to make much difference.   
It has been pointed out that transfers are likely to only gradually  
add to the complexity of the global route table, not cause a sharp  
spike.

In the context of similar discussion in RIPE, it seems that an impact  
on the global route table is not expected.
http://www.ripe.net/ripe/policies/proposals/2007-08.html
  "the RIPE NCC does not anticipate that any significant impact will  
be caused if this proposal is implemented"
Is there enough difference between ARIN addresses and RIPE addresses  
to think the conclusion for ARIN would be different?

Does somebody have experimental analysis that indicates a numerical  
estimate of how many random transfers would produce how much  
fragmentation (extra entries) in the global route table for ARIN  
addresses?

John

On 2008Oct6, at 10:25 AM, Tom Vest wrote:

> ... To recap from last week, what makes routing keep
> working under the current paradigm?
>
> 1. CIDR  -- which provides the basic tools.
> 2. Top-level aggregation -- which the RIR community-system provided,
> and kept flexible over time as technology improved and RIR community
> practices changed.
> 3. Filtering -- which was/is only commercially feasible because of the
> top-level aggregation made possible by the RIR community-system.
> 4. Open entry for new routing service providers, which the arms-length
> RIR processes also enabled, and which effectively made aggregation and
> filtering "justifiable" and thus palatable to most direct
> stakeholders, as well as to the few indirect stakeholders/outside
> observer who knew that the system existed and understood the basics of
> how it worked.
>
> An uncoordinated market will eliminate (2), which will make (3,4)
> impossible, which will cause the current routing paradigm to fail in
> short order.
>
> Maybe a routing cartel will emerge in time to solve the problem,
> without creating new problems for aspiring new entrants and the ever
> widening audience of attentive external stakeholders. But that's a big
> leap of faith...
>
> TV

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

From michael.dillon at bt.com  Mon Oct  6 11:21:30 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 6 Oct 2008 16:21:30 +0100
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <48EA259A.3080705@psg.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC087BF14A@E03MVZ2-UKDY.domain1.systemhost.net>

> and if you think that, three years from now, the rirs will 
> have larger blocks to sell than the open market, please share 
> what you're smoking.

It's called IPv6. You can get big blocks today and you will
still be able to get big blocks 3 years from now, and even
10 years from now.

> and perhaps you have not read any of the routing table 
> analyses.  we have already lost the routing table battle.  
> it's over 50% crap.

Seems to me like the battle was won. The routing table growth 
curve was kept below the curve of core routers' ability to
handle the table growth. And the vendors have all taken on
board the need to support that kind of table growth for
the foreseeable future so their equipment roadmaps leave
plenty of headroom. In a world where 99% of SMTP traffic is
crap, it seems to me that we are doing very well if only 
50% of the routing table is crap.

--Michael Dillon


From randy at psg.com  Mon Oct  6 11:23:32 2008
From: randy at psg.com (Randy Bush)
Date: Mon, 06 Oct 2008 08:23:32 -0700
Subject: [arin-ppml] uncoordinated market for IPv4 addresses will cause
	routing failure
In-Reply-To: <FA22A142-2812-4AE5-B15F-9CF7BED78772@isoc.org>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
	<FA22A142-2812-4AE5-B15F-9CF7BED78772@isoc.org>
Message-ID: <48EA2D74.3010208@psg.com>

> What I have heard is that the fragmentation of global routing due to
> traffic engineering and multihoming has already scrambled things enough
> that random transfers is not likely to make much difference.

let's not forget the folk slicing and dicing to /24s to compete with
others accidentally announcing their prefix.  why i mention this is
because, in the long run, we can actually do something about this,
routing security.

and a new factor we will see down the road which we don't really have
today.  it falls under multi-homing, but the more extreme end of the
sport.  folk are gonna need small bits of ipv4 space to front nats,
whether ipv4 or ipv6 is behind them.  i suspect that five years from now
we could see pressure to have /27s or whatever globally routed.
providing for this was one of the ideas behind apnic prop-062, see
<http://www.apnic.net/policy/proposals/prop-062-v002.html>.

randy


From tvest at pch.net  Mon Oct  6 11:43:52 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 6 Oct 2008 11:43:52 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <48EA259A.3080705@psg.com>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
	<48EA259A.3080705@psg.com>
Message-ID: <8345F531-BA03-42F6-8FD7-CA14C3D93F1F@pch.net>


On Oct 6, 2008, at 10:50 AM, Randy Bush wrote:

> crock.  whether i get the address space i need from an rir or the  
> market
> it's the same address space and i announce it.

Maybe that would be true, if it had any real-world referent -- but it  
doesn't.
You get what you "need" from the RIR community-system, by definition,  
the definition created and adopted and refined by *you* and your  
industry peers.

You don't get what you need from a market; you get whatever *you* can  
pay for.

Maybe that's nothing at all, maybe that's something that good enough  
for you, but will be punishing and non-sustainable for your peers --  
or maybe it'll be something that, purely by coincidence, is good for  
you and also sustainable in the aggregate. But no one's going to care  
about that -- because the "the community" is either a failure or a  
myth or a scam, right? That's why it doesn't even merit consideration  
in planning for address transfers, right?

> and if you think that, three years from now, the rirs will have larger
> blocks to sell than the open market, please share what you're smoking.

Randy, if you think anyone anywhere will have "large blocks" "to sell"  
in free pool exhaustion +3 years time, then I need a hit of whatever  
you're on.
And if you're willing to toss out the model of community self- 
governance for a paltry 2-3 years of extra profits and/or marginal  
convenience for the luckiest and/or best-bankrolled institutions of  
the moment, at the expense of everyone else for the rest of time, then  
I'll just say that I do not share your priorities.

> and perhaps you have not read any of the routing table analyses.  we
> have already lost the routing table battle.  it's over 50% crap.

You're suffering from the counterfactual fallacy. Maybe a /24 looked  
like certain crap a decade ago. Maybe the full routing table  
deaggregated to /24s would be unsustainable. Now ask yourself: why is  
it that we don't have a full routing table deaggregated to /24s or  
worse today -- and refer to prev. message (2), copied again below.

So we should all make that leap of faith? Why?

TV

> On Oct 6, 2008, at 9:27 AM, Tom Vest wrote:
>>
>
> That's right Randy. To recap from last week, what makes routing keep  
> working under the current paradigm?
>
> 1. CIDR  -- which provides the basic tools.
> 2. Top-level aggregation -- which the RIR community-system provided,  
> and kept flexible over time as technology improved and RIR community  
> practices changed.
> 3. Filtering -- which was/is only commercially feasible because of  
> the top-level aggregation made possible by the RIR community-system.
> 4. Open entry for new routing service providers, which the arms- 
> length RIR processes also enabled, and which effectively made  
> aggregation and filtering "justifiable" and thus palatable to most  
> direct stakeholders, as well as to the few indirect stakeholders/ 
> outside observer who knew that the system existed and understood the  
> basics of how it worked.
>
> An uncoordinated market will eliminate (2), which will make (3,4)  
> impossible, which will cause the current routing paradigm to fail in  
> short order.
>
> Maybe a routing cartel will emerge in time to solve the problem,  
> without creating new problems for aspiring new entrants and the ever  
> widening audience of attentive external stakeholders. But that's a  
> big leap of faith...
>
> TV


From owen at delong.com  Mon Oct  6 11:53:49 2008
From: owen at delong.com (Owen DeLong)
Date: Mon, 6 Oct 2008 08:53:49 -0700
Subject: [arin-ppml] Revision to 2007-14 -- Minor edits requested by ARIN
	Counsel and staff
Message-ID: <C3895585-9DB8-418C-B8D5-67D35890AEFB@delong.com>

Apologies for the late revision. Authors have been communicating with  
ARIN
counsel in an effort to refine language and try to achieve agreement  
on the content
of the policy proposal.

Changes in this revision:

	Minor edits to bring the language closer to compliance with requests  
from staff
	and legal.  Authors do not believe these edits constitute substantive  
change
	to the intent of the policy.

	Minor changes to language to improve clarity and sentence structure.
	Authors do not believe these edits constitute a substantive change to  
the
	intent of the policy.

	In fairness, not all of the requests from legal were addressed the  
way legal
	wanted.  There are limitations on ARIN contained in this proposal which
	counsel opposed. I'll leave it to legal to present those in their  
analysis
	which should come out shortly because I do not want to mis-characterize
	them.

	However, the authors have been in contact with legal and the places  
where
	we have agreed to disagree are not new to this version of the policy.


#################################################################
Policy Proposal 2007-14
Resource Review Process
Author: Owen DeLong, Stephen Sprunk
Proposal Version: 3.1
Date: 14 August 2008
Proposal type: modify
Policy term: permanent
Policy statement:
Add the following to the NRPM:
Resource Review
1. ARIN may review the current usage of any resources maintained in  
the ARIN database. The organization shall cooperate with any request  
from ARIN for reasonable related documentation.
2. ARIN may conduct such reviews:
a. when any new resource is requested,
b. whenever ARIN has reason to believe that the resources were  
originally obtained fraudulently or in contravention of existing  
policy, or
c. at any other time without having to establish cause unless a prior  
review has been completed in the preceding 24 months.
3. ARIN shall communicate the results of the review to the organization.
4. Organizations found by ARIN to be  materially out of compliance  
with current ARIN policy shall be requested or required to return  
resources as needed to bring them into (or reasonably close to)  
compliance.
4a. The degree to which an organization may remain out of compliance  
shall be based on the reasonable judgment of the ARIN staff and shall  
balance all facts known, including the organization?s utilization rate,
available address pool, and other factors as appropriate so as to  
avoid forcing returns which will result in near-term additional  
requests or unnecessary route de-aggregation.
4b. To the extent possible, entire blocks should be returned. Partial  
address blocks shall be returned in such a way that the portion  
retained will comprise a single aggregate block.
5. If the organization does not voluntarily return resources as  
requested, ARIN may revoke any resources issued by ARIN as required to  
bring the organization into overall compliance. ARIN shall follow the  
same guidelines for revocation that are required for voluntary return  
in the previous paragraph.
6. Except in cases of fraud, or violations of policy, an organization  
shall be given a minimum of six months to effect a return. ARIN shall  
negotiate a longer term with the organization if ARIN believes the  
organization is working in good faith to substantially restore  
compliance and has a valid need for additional time to renumber out of  
the affected blocks.
7. ARIN shall continue to provide services for the resource(s) while  
their return or revocation is pending, however, any maintenance fees  
assessed during that period shall be calculated as if the return or  
revocation was complete.
8. ARIN will not reclaim or revoke Legacy resources in active use,  
regardless of utilization. However, the utilization of legacy  
resources shall be considered during a review to assess overall  
compliance.
9. In considering compliance with policies which allow a timeframe  
(such as a requirement to assign some number of prefixes within 5  
years), failure to comply cannot be measured until after the timeframe  
specified in the applicable policy has elapsed. Blocks subject to such  
a policy shall be assumed in compliance with that policy until such  
time as the specified time since issuance has elapsed.

Delete NRPM sections 4.1.2, 4.1.3, 4.1.4

Remove the sentence "In extreme cases, existing allocations may be  
affected." from NRPM section 4.2.3.1.

Rationale:
Under current policy and existing RSAs, ARIN has an unlimited  
authority to audit or review a resource holder's utilization for  
compliance at any time and no requirement to communicate the results  
of any such review to the resource holder.

This policy attempts to balance the needs of the community and the  
potential for abuse of process by ARIN in a way that better clarifies  
the purpose, scope, and capabilities of ARIN and codifies some  
appropriate protections for resource holders while still preserving  
the ability for ARIN to address cases of fraud and abuse on an  
expedited basis.

The intended nature of the review is to be no more invasive than what  
usually happens when an organization applies for additional resources.  
Additionally, paragraph 2c prevents ARIN from doing excessive without- 
cause reviews.

The authors believe that this update addresses the majority of the  
feedback received from the community to date and addresses most of the  
concerns expressed.
#####

















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

From randy at psg.com  Mon Oct  6 12:39:09 2008
From: randy at psg.com (Randy Bush)
Date: Mon, 06 Oct 2008 09:39:09 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <8345F531-BA03-42F6-8FD7-CA14C3D93F1F@pch.net>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
	<48EA259A.3080705@psg.com>
	<8345F531-BA03-42F6-8FD7-CA14C3D93F1F@pch.net>
Message-ID: <48EA3F2D.2090908@psg.com>

> You get what you "need" from the RIR community-system, by definition

you may want to google "ipv4 free pool exhaustion."

randy


From tvest at pch.net  Mon Oct  6 12:50:25 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 6 Oct 2008 12:50:25 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <48EA3F2D.2090908@psg.com>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
	<48EA259A.3080705@psg.com>
	<8345F531-BA03-42F6-8FD7-CA14C3D93F1F@pch.net>
	<48EA3F2D.2090908@psg.com>
Message-ID: <5D646F4D-A245-4E4A-9F63-0C9ED9484EDE@pch.net>


On Oct 6, 2008, at 12:39 PM, Randy Bush wrote:

>> You get what you "need" from the RIR community-system, by definition
>
> you may want to google "ipv4 free pool exhaustion."
>
> randy

Let the record show that the witness is uncooperative ;-)

See you in LA,

TV



From randy at psg.com  Mon Oct  6 12:56:43 2008
From: randy at psg.com (Randy Bush)
Date: Mon, 06 Oct 2008 09:56:43 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <5D646F4D-A245-4E4A-9F63-0C9ED9484EDE@pch.net>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
	<48EA259A.3080705@psg.com>
	<8345F531-BA03-42F6-8FD7-CA14C3D93F1F@pch.net>
	<48EA3F2D.2090908@psg.com>
	<5D646F4D-A245-4E4A-9F63-0C9ED9484EDE@pch.net>
Message-ID: <48EA434B.1030302@psg.com>

>>> You get what you "need" from the RIR community-system, by definition
>> you may want to google "ipv4 free pool exhaustion."
> Let the record show that the witness is uncooperative ;-)

no.  it's just that when one actually has to deal with the network,
routers, ... reality stares one in the face on a daily basis.

> See you in LA,

let's see, good food or disfunctional meeting.  hmmmm.  tough choice. :)

rndy


From pschopis at oar.net  Mon Oct  6 13:53:44 2008
From: pschopis at oar.net (Paul Schopis)
Date: Mon, 6 Oct 2008 13:53:44 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
Message-ID: <66B37AC7-A506-47D2-88C5-8BE72E5C4A5A@oar.net>

OipEC?


On Oct 6, 2008, at 10:25 AM, Tom Vest wrote:

> Maybe a routing cartel will emerge in time to solve the problem,
> without creating new problems for aspiring new entrants and the ever
> widening audience of attentive external stakeholders. But that's a big
> leap of faith...



From info at arin.net  Mon Oct  6 14:34:57 2008
From: info at arin.net (Member Services)
Date: Mon, 06 Oct 2008 14:34:57 -0400
Subject: [arin-ppml] Revision to 2007-14 -- Minor edits requested by
 ARIN Counsel and staff
In-Reply-To: <C3895585-9DB8-418C-B8D5-67D35890AEFB@delong.com>
References: <C3895585-9DB8-418C-B8D5-67D35890AEFB@delong.com>
Message-ID: <48EA5A51.3000004@arin.net>

Policy Proposal 2007-14
Resource Review Process

This proposal has been revised. It is open for discussion on this
mailing list and will be on the agenda at the upcoming ARIN Public
Policy Meeting.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2007_14.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



Owen DeLong wrote:
>
> Apologies for the late revision. Authors have been communicating with ARIN
>
> counsel in an effort to refine language and try to achieve agreement 
> on the content
>
> of the policy proposal.
>
>
> Changes in this revision:
>
>
> Minor edits to bring the language closer to compliance with requests 
> from staff
>
> and legal. Authors do not believe these edits constitute substantive 
> change
>
> to the intent of the policy.
>
>
> Minor changes to language to improve clarity and sentence structure.
>
> Authors do not believe these edits constitute a substantive change to the
>
> intent of the policy.
>
>
> In fairness, not all of the requests from legal were addressed the way 
> legal
>
> wanted. There are limitations on ARIN contained in this proposal which
>
> counsel opposed. I'll leave it to legal to present those in their analysis
>
> which should come out shortly because I do not want to mis-characterize
>
> them.
>
>
> However, the authors have been in contact with legal and the places where
>
> we have agreed to disagree are not new to this version of the policy.
>
>
>
> #################################################################
>
> Policy Proposal 2007-14
> Resource Review Process
>
> Author: Owen DeLong, Stephen Sprunk
>
> Proposal Version: 3.1
>
> Date: 14 August 2008
>
> Proposal type: modify
>
> Policy term: permanent
>
> Policy statement:
>
> Add the following to the NRPM:
>
> Resource Review
>
> 1. ARIN may review the current usage of any resources maintained in 
> the ARIN database. The organization shall cooperate with any request 
> from ARIN for reasonable related documentation.
>
> 2. ARIN may conduct such reviews:
>
> a. when any new resource is requested,
>
> b. whenever ARIN has reason to believe that the resources were 
> originally obtained fraudulently *or in contravention of existing 
> policy*, or
>
> c. at any other time without having to establish cause unless a prior 
> review has been completed in the preceding 24 months.
>
> 3. ARIN shall communicate the results of the review to the organization.
>
> 4. Organizations found by ARIN to be * materially* out of compliance 
> with current ARIN policy shall be requested or required to return 
> resources as needed to bring them into (or reasonably close to) 
> compliance.
>
> 4a. The degree to which an organization may remain out of compliance 
> shall be based on the reasonable judgment of the ARIN staff and shall 
> balance all facts known, including the organization?s utilization rate,
> available address pool, and other factors as appropriate so as to 
> avoid forcing returns which will result in near-term additional 
> requests or unnecessary route de-aggregation.
>
> 4b. To the extent possible, entire blocks should be returned. Partial 
> address blocks shall be returned in such a way that the portion 
> retained will comprise a single aggregate block.
>
> 5. If the organization does not voluntarily return resources as 
> requested, ARIN may revoke any resources issued by ARIN as required to 
> bring the organization into overall compliance. ARIN shall follow the 
> same guidelines for revocation that are required for voluntary return 
> in the previous paragraph.
>
> 6. Except in cases of fraud, or violations of policy, an organization 
> shall be given a minimum of six months to effect a return. ARIN shall 
> negotiate a longer term with the organization if ARIN believes the 
> organization is working in good faith to substantially restore 
> compliance and has a valid need for additional time to renumber out of 
> the affected blocks.
>
> 7. ARIN shall continue to provide services for the resource(s) while 
> their return or revocation is pending,* however,* any maintenance fees 
> assessed during that period shall be calculated as if the return or 
> revocation was complete.
>
> 8. ARIN will not reclaim or revoke Legacy resources in active use, 
> regardless of utilization. However, the utilization of legacy 
> resources shall be considered during a review to assess overall 
> compliance.
>
> 9. In considering compliance with policies which allow a timeframe 
> (such as a requirement to assign some number of prefixes within 5 
> years), failure to comply cannot be measured until after the timeframe 
> specified in the applicable policy has elapsed. Blocks subject to such 
> a policy shall be assumed in compliance with that policy until such 
> time as the specified time since issuance has elapsed.
>
>
> Delete NRPM sections 4.1.2, 4.1.3, 4.1.4
>
>
> Remove the sentence "In extreme cases, existing allocations may be 
> affected." from NRPM section 4.2.3.1.
>
>
> Rationale:
>
> Under current policy and existing RSAs, ARIN has an unlimited 
> authority to audit or review a resource holder's utilization for 
> compliance at any time and no requirement to communicate the results 
> of any such review to the resource holder.
>
>
> This policy attempts to balance the needs of the community and the 
> potential for abuse of process by ARIN in a way that better clarifies 
> the purpose, scope, and capabilities of ARIN and codifies some 
> appropriate protections for resource holders while still preserving 
> the ability for ARIN to address cases of fraud and abuse on an 
> expedited basis.
>
>
> The intended nature of the review is to be no more invasive than what 
> usually happens when an organization applies for additional resources. 
> Additionally, paragraph 2c prevents ARIN from doing excessive 
> without-cause reviews.
>
>
> The authors believe that this update addresses the majority of the 
> feedback received from the community to date and addresses most of the 
> concerns expressed.
>
> #####
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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  Mon Oct  6 18:04:48 2008
From: farmer at umn.edu (David Farmer)
Date: Mon, 06 Oct 2008 17:04:48 -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: <48EA4530.12507.F10D5AB@farmer.umn.edu>

I've been reading up on the NRPM, and I have a few comments to add.

On 30 Sep 2008 Leo Bicknell wrote:

> 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.

Actually NRPM 4.1.2, 4.1.3, and 4.1.4 paraphrases much of this text, as it 
probably should.  However, 2007-14 proposes to delete these sections, and 
I'm not sure it replaces every thing it deletes, I'll make those comments in 
regard to 2007-14, but if this issue is important to you maybe you should 
look closely at 2007-14.

] 4.1.2. Validity
] 
] IP address allocations are valid as long as the utilization and other relevant
] criteria continue to be met, and the yearly fee is submitted.
] 
] 4.1.3. Invalidation
] 
] ARIN may invalidate any IP allocation if it determines that the requirement 
] for the address space no longer exists.
] 
] 4.1.4. Recall
] 
] In the event of address space recall, ARIN will make every reasonable
]  effort to inform the organization that the addresses are being returned to
]  the free pool of IPv4 address space.

So these with 4.1.7's reference to RFC 2050 cover the issue, however given 
that we are moving into a world with no IANA Free Pool more explicit 
language could probably be helpful.  The language here in the NRPM and 
RFC 2050 leave a lot to interpretation.

> 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/
 



=======================================================
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  Mon Oct  6 20:07:01 2008
From: farmer at umn.edu (David Farmer)
Date: Mon, 06 Oct 2008 19:07:01 -0500
Subject: [arin-ppml] Revision to 2007-14
In-Reply-To: <C3895585-9DB8-418C-B8D5-67D35890AEFB@delong.com>
References: <C3895585-9DB8-418C-B8D5-67D35890AEFB@delong.com>
Message-ID: <48EA61D5.28593.F80BA24@farmer.umn.edu>

Owen,

I support the goals of this proposal, and think these are important changes, 
but I'm concerned that you delete 4.1.2, 4.1.3, and 4.1.4 and I'm not sure 
you completely replace their functions.

1. NRPM 4.1.2 says "IP address allocations are valid as long as the 
utilization and other relevant criteria continue to be met, and the yearly fee is 
submitted."  I believe some place in NRPM we need to say if you no longer 
need IP address allocations then you should return them. NRPM 4.1.2 
comes the closest to saying that, and I don't see where you convey that idea 
in your proposal.  

This is motherhood and apple pie type stuff, but it needs to be said.  As Leo 
pointed out in another thread this is covered in RFC 2050, and by reference 
in NRPM 4.1.7, however I believe this is an important enough concept that it 
should be explicit in the NRPM some place.

I guess what I'm trying to say is that ARIN policy shouldn't imply that you can 
keep your IP allocations until ARIN asks you to return them.  Therefore 
there needs to be some kind of statement to that effect and in my opinion 
4.1.2 comes the closest to that in the NRPM now.  It would be better to have 
something that says that more directly, but 4.1.2 is better than nothing.  

2. NRPM 4.1.3 says "ARIN may invalidate any IP allocation if it determines 
that the requirement for the address space no longer exists."  Do you intend 
that the only way ARIN can recover IP allocations is through this Resource 
Review Process?  If not, then what policy gives ARIN the ability to do it, if 
this is no longer available?

3. NRPM 4.1.4 says "In the event of address space recall, ARIN will make 
every reasonable effort to inform the organization that the addresses are 
being returned to the free pool of IPv4 address space."  I guess if you intend 
that the only way ARIN can recover IP allocations is through this Resource 
Review Process then you can probably safely delete this.  Otherwise it is still 
probably needed or something similar.

4 Since  #1 states "ARIN may review the current usage of any resources 
maintained in the ARIN database."  I assume this means IPv4, IPv6, and 
ASN resources.  So I recommend this with become its own section, or it be 
duplicated as subsection under 4, 5, and 6.  Probably called "Resource 
Review"

5. #1. states  "... The organization shall cooperate with any request  from 
ARIN for reasonable related documentation."  What is the recourse if the 
organization fails to cooperate with ARIN, I feel this should be explicit.  Can 
ARIN assume they are "materially out of compliance with current ARIN 
policy"?  

There should probably be a response time frame specified too.  Something 
like "ARIN shall provide a minimum of 10 business days for a organization to 
produce the requested documentation.  ARIN may negotiate a response 
time with the organization, if ARIN believes the organization is working in 
good faith to produce the requested documentation."


On 6 Oct 2008 Owen DeLong wrote:

......

> #################################################################
> Policy Proposal 2007-14
> Resource Review Process
> Author: Owen DeLong, Stephen Sprunk
> Proposal Version: 3.1
> Date: 14 August 2008
> Proposal type: modify
> Policy term: permanent
> Policy statement:
> Add the following to the NRPM:
> Resource Review

.....

> Delete NRPM sections 4.1.2, 4.1.3, 4.1.4
 
......

=======================================================
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 filiz at ripe.net  Tue Oct  7 05:42:50 2008
From: filiz at ripe.net (Filiz Yilmaz)
Date: Tue, 7 Oct 2008 11:42:50 +0200
Subject: [arin-ppml] uncoordinated market for IPv4 addresses will cause
	routing failure
In-Reply-To: <FA22A142-2812-4AE5-B15F-9CF7BED78772@isoc.org>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
	<FA22A142-2812-4AE5-B15F-9CF7BED78772@isoc.org>
Message-ID: <99C391A6-E529-491A-B4C1-DE9EFC5CBA70@ripe.net>

Dear John,

I would like to make a clarification regarding:

On 6 Oct 2008, at 17:12, John Schnizlein wrote:

>
> In the context of similar discussion in RIPE, it seems that an  
> impact on the global route table is not expected.
> http://www.ripe.net/ripe/policies/proposals/2007-08.html
>  "the RIPE NCC does not anticipate that any significant impact will  
> be caused if this proposal is implemented"
> Is there enough difference between ARIN addresses and RIPE  
> addresses to think the conclusion for ARIN would be different?
>


The analysis for proposal 2007-08 (Enabling Methods for Reallocation  
of IPv4 Resources) in RIPE region has two parts:

A. Impact of Policy on Registry and Addressing System
       -- Address/Internet Number Resource Consumption
       -- Fragmentation/Aggregation

and

B. Impact of Policy on RIPE NCC Operations/Services

The quote above as  "the RIPE NCC does not anticipate that any  
significant impact will be caused if this proposal is implemented" is  
the information provided for part B, regarding the impact on RIPE NCC  
Operations and Services.

You can find the full analysis at http://www.ripe.net/ripe/policies/ 
proposals/2007-08.html,
which I copied below for your convenience.

Kind regards,

Filiz Yilmaz
Policy Development Officer
RIPE NCC


------------------------------------------------------------------------ 
--------------------------------------------------

[from http://www.ripe.net/ripe/policies/proposals/2007-08.html]

...

Additional Information:

Note: In order to provide additional information related to the  
proposal, details of an impact analysis carried out by the RIPE NCC  
are documented below. The projections presented in this analysis are  
based on existing data and should be viewed only as an indication of  
the possible impact that the policy may have if the proposal is  
accepted and implemented.

A. Impact of Policy on Registry and Addressing System

Address/Internet Number Resource Consumption:

After analysing the data that is currently available, the RIPE NCC  
does not anticipate any significant impact on address/Internet  
resource consumption if this proposal is implemented.

Fragmentation/Aggregation:

When this calculation was made, the RIPE NCC had made approximately  
11,100 IPv4 allocations. Today, the minimum allocation size is a /21,  
and according to the proposal this would be the minimum size possible  
for a block being transferred. If each of the 11,100 allocations were  
split into /21s to be transferred, there would eventually be 193,000  
allocations (about 17 times more than there currently are). This  
could have an impact on fragmentation and, therefore, on the routing  
system, assuming these transferable blocks are announced specifically.

So far, the different blocks that the RIPE NCC had allocated space  
from had different maximum prefix sizes, depending on the minimum  
allocation size the policy set at various times. These varying  
longest prefix sizes per /8 can be seen in the document ?Address  
Space Managed by the RIPE NCC?: http://www.ripe.net/ripe/docs/ 
ripe-415.html. Once this proposal is implemented, the longest prefix  
size for all blocks will need to be set to one size, a /21, which is  
the current minimum allocation size that the RIPE policy allows.

B. Impact of Policy on RIPE NCC Operations/Services
After analysing the data that is currently available, the RIPE NCC  
does not anticipate that any significant impact will be caused if  
this proposal is implemented.

------------------------------------------------------------------------ 
--------------------------------------------------




From schnizlein at isoc.org  Tue Oct  7 07:02:50 2008
From: schnizlein at isoc.org (John Schnizlein)
Date: Tue, 7 Oct 2008 07:02:50 -0400
Subject: [arin-ppml] uncoordinated market for IPv4 addresses will cause
	routing failure
In-Reply-To: <99C391A6-E529-491A-B4C1-DE9EFC5CBA70@ripe.net>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads>
	<B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org>
	<48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
	<FA22A142-2812-4AE5-B15F-9CF7BED78772@isoc.org>
	<99C391A6-E529-491A-B4C1-DE9EFC5CBA70@ripe.net>
Message-ID: <48EBE390-D842-4840-8D9B-ADAE798D2FD2@isoc.org>

Thank you for the clarification.  I had missed the worst-case estimate  
in the fragmentation section:

"This could have an impact on fragmentation and, therefore, on the  
routing system, assuming these transferable blocks are announced  
specifically."

Has there been any more analysis of how close or how quickly the  
"193,000 allocations" might be reached?

How does this worst cast compare to the number of routes already in  
the global route table for traffic engineering and hijack-prevention?

John

On 2008Oct7, at 5:42 AM, Filiz Yilmaz wrote:
>
> I would like to make a clarification regarding:
>
> The analysis for proposal 2007-08 (Enabling Methods for Reallocation  
> of IPv4 Resources) in RIPE region has two parts:
>
> A. Impact of Policy on Registry and Addressing System
>      -- Address/Internet Number Resource Consumption
>      -- Fragmentation/Aggregation
>
> and
>
> B. Impact of Policy on RIPE NCC Operations/Services
>
> The quote above as  "the RIPE NCC does not anticipate that any  
> significant impact will be caused if this proposal is implemented"  
> is the information provided for part B, regarding the impact on RIPE  
> NCC Operations and Services.
>
> You can find the full analysis at http://www.ripe.net/ripe/policies/proposals/2007-08.html 
> ,
> which I copied below for your convenience.
>
> Kind regards,
>
> Filiz Yilmaz
> Policy Development Officer
> RIPE NCC
>
>
> --------------------------------------------------------------------------------------------------------------------------
>
> [from http://www.ripe.net/ripe/policies/proposals/2007-08.html]
>
> ...
>
> Additional Information:
>
> Note: In order to provide additional information related to the  
> proposal, details of an impact analysis carried out by the RIPE NCC  
> are documented below. The projections presented in this analysis are  
> based on existing data and should be viewed only as an indication of  
> the possible impact that the policy may have if the proposal is  
> accepted and implemented.
>
> A. Impact of Policy on Registry and Addressing System
>
> Address/Internet Number Resource Consumption:
>
> After analysing the data that is currently available, the RIPE NCC  
> does not anticipate any significant impact on address/Internet  
> resource consumption if this proposal is implemented.
>
> Fragmentation/Aggregation:
>
> When this calculation was made, the RIPE NCC had made approximately  
> 11,100 IPv4 allocations. Today, the minimum allocation size is a / 
> 21, and according to the proposal this would be the minimum size  
> possible for a block being transferred. If each of the 11,100  
> allocations were split into /21s to be transferred, there would  
> eventually be 193,000 allocations (about 17 times more than there  
> currently are). This could have an impact on fragmentation and,  
> therefore, on the routing system, assuming these transferable blocks  
> are announced specifically.
>
> So far, the different blocks that the RIPE NCC had allocated space  
> from had different maximum prefix sizes, depending on the minimum  
> allocation size the policy set at various times. These varying  
> longest prefix sizes per /8 can be seen in the document ?Address  
> Space Managed by the RIPE NCC?: http://www.ripe.net/ripe/docs/ripe-415.html 
> . Once this proposal is implemented, the longest prefix size for all  
> blocks will need to be set to one size, a /21, which is the current  
> minimum allocation size that the RIPE policy allows.
>
> B. Impact of Policy on RIPE NCC Operations/Services
> After analysing the data that is currently available, the RIPE NCC  
> does not anticipate that any significant impact will be caused if  
> this proposal is implemented.
>
> --------------------------------------------------------------------------------------------------------------------------
>
>



From bicknell at ufp.org  Tue Oct  7 11:06:34 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 7 Oct 2008 11:06:34 -0400
Subject: [arin-ppml] Revision to 2007-14
In-Reply-To: <48EA61D5.28593.F80BA24@farmer.umn.edu>
References: <C3895585-9DB8-418C-B8D5-67D35890AEFB@delong.com>
	<48EA61D5.28593.F80BA24@farmer.umn.edu>
Message-ID: <20081007150634.GA60706@ussenterprise.ufp.org>

In a message written on Mon, Oct 06, 2008 at 07:07:01PM -0500, David Farmer wrote:
> This is motherhood and apple pie type stuff, but it needs to be said.  As Leo 
> pointed out in another thread this is covered in RFC 2050, and by reference 
> in NRPM 4.1.7, however I believe this is an important enough concept that it 
> should be explicit in the NRPM some place.
> 
> I guess what I'm trying to say is that ARIN policy shouldn't imply that you can 
> keep your IP allocations until ARIN asks you to return them.  Therefore 
> there needs to be some kind of statement to that effect and in my opinion 
> 4.1.2 comes the closest to that in the NRPM now.  It would be better to have 
> something that says that more directly, but 4.1.2 is better than nothing.  

Your issue raises a procedural question.  Our process allows us to
move forward the current proposal "as is" (there are some nuances
to that, but close enough for this discussion), or we can change
it and hold it back for another loop through the next meeting.

So if you feel strongly enough that this should be included, you have
basically two paths forward:

1) Lobby Owen to modify his proposal, and choose not to support it
   as-is.  This will require all changes to go through another meeting
   cycle.

2) Let this policy go as-is, and then submit an additional policy for
   the next meeting which clarifies the section of interest.  In this
   case we can get the benefits of most of the proposal now, and add
   some additional clarification in the next cycle.

Do you believe this issue is important enough that path #1 is necessary,
or would path #2 make you happy?

-- 
       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/20081007/e9ead345/attachment.sig>

From cgrundemann at gmail.com  Tue Oct  7 17:41:00 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 7 Oct 2008 15:41:00 -0600
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation
	-Revised
In-Reply-To: <200810051530.m95FUW3K020295@mail.r-bonomi.com>
References: <200810051530.m95FUW3K020295@mail.r-bonomi.com>
Message-ID: <443de7ad0810071441p7a87db0cm2e68172de69ec19d@mail.gmail.com>

Good catch on the should vs shall Robert, I also agree with your
change of the first statement.  Here is what I have now:

Arin will validate each WHOIS POC at least annually.  Unresponsive POC
email addresses shall be marked as such in the database.  If ARIN
staff deems a POC to be completely and permanently abandoned or
otherwise illegitimate, the record shall be locked or deleted.
Following this validation each year, a list of address blocks with
zero valid POCs shall be made easily available to the community.

Is there anyone who prefers the version with more detail over this
potential version?


On Sun, Oct 5, 2008 at 9:30 AM, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
>
> In broad, I like it a lot better.
>
> I would, however, change the action verbs from advisory ("should") to
> mandatory ("shall"), throughout.
>
> I would also change the 1st statement to:
>
>     Arin will validate each WHOIS POC at least annually.
>
> Rationale: for a POC with which ARIN has had contact "recently", there is
> little to be gained by re-verifying the validity of that contact information.
> Reducing the number of POCs that must be validated is obviously advantageous,
> in that it reduces the workload.
>
> This proposed language also allows staff to verify _more_frequently_, if,
> in their opinion, circumstances warrarnt it. And, those circumstances can
> be evaluated on a case-by-case basis.
>
>
> _______________________________________________
> 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 owen at delong.com  Wed Oct  8 15:14:23 2008
From: owen at delong.com (Owen DeLong)
Date: Wed, 8 Oct 2008 12:14:23 -0700
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation
	-Revised
In-Reply-To: <443de7ad0810050737w3b3f7d69p3a8aba648dcdb124@mail.gmail.com>
References: <443de7ad0810031149m47b936fbqa750ea0f3cee3ab6@mail.gmail.com>
	<C0F2465B4F386241A58321C884AC7ECC08697510@E03MVZ2-UKDY.domain1.systemhost.net>
	<443de7ad0810050737w3b3f7d69p3a8aba648dcdb124@mail.gmail.com>
Message-ID: <86569FC6-8DE5-44A9-9CCC-2B61174E1C78@delong.com>


On Oct 5, 2008, at 7:37 AM, Chris Grundemann wrote:

> So you would be more likely to support something along the lines of
> the following?
>
> ARIN will conduct WHOIS POC validation annually.  Unresponsive POC
> email addresses should be marked as such in the database.  If ARIN
> staff deems a POC to be completely and permanently abandoned or
> otherwise illegitimate, the record should be locked or deleted.
> Following this validation each year, a list of address blocks with
> zero valid POCs should be made easily available to the community.
>
> I wonder how others feel about this less operationally detailed  
> verbiage?
>
> ~Chris

I prefer this version.  Sorry for the late response.  I've been trying  
to
focus on the proposals which are being discussed at LA since there
is slightly more urgency there.

Owen



From info at arin.net  Wed Oct  8 16:19:09 2008
From: info at arin.net (Member Services)
Date: Wed, 08 Oct 2008 16:19:09 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
Message-ID: <48ED15BD.9060904@arin.net>

Policy Proposal: 2008-4
Title: Minimum Allocation in the Caribbean Region
Revised: 18 August 2008
Assessment: 8 October 2008

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I. Proposal

Policy Proposal is available below and at:
http://www.arin.net/policy/proposals/2008_4.html

II. Proposal Summary

ARIN staff understands that this policy would lower the minimum
allocation size to a /22 for ISPs in the Caribbean region. The ARIN
Caribbean service area consists of the locations listed at
http://www.arin.net/community/ARINcountries.html, with the exception of
the US, Canada, Antarctica, Bouvet Islands, US Minor Outlying Islands,
St Pierre and Miquelon, Heard and McDonald Islands and St Helena.

III. Comments

A. ARIN Staff

1. Staff foresees no implementation problems with this policy.
2. End-users are excluded from this policy which might be viewed as
offering an unfair advantage to ISPs in the region.

B. ARIN General Counsel

Counsel sees no significant legal or litigation risk regarding this policy.


IV. Resource Impact ? Minimal

The resource impact of implementing this policy is viewed as minimal.
Barring any unforeseen resource requirements, this policy could be
implemented within 30 ? 90 days from the date of the ratification of the
policy by the ARIN Board of Trustees. It will require the following:

? Updates to Guidelines will be required
? Staff training will be required
? Updates to the ARIN web page of the ?List of Countries in ARIN?s
Geographical Areas? to indicate which countries are considered part of
the Caribbean region will be required.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


Policy Proposal 2008-4
Minimum Allocation in the Caribbean Region

Author: Cathy Aronson and Paul Andersen

Date: 18 August 2008

Proposal type: new

Policy term: renewable

Policy statement:

Add the following as section 4.8 of NRPM:

4.8. Minimum Allocation. The minimum IPv4 allocation size for ISPs from
the Caribbean portion of the ARIN region is /22.

    4.8.1. Allocation Criteria.

        * The requesting organization must show the efficient
        utilization of an entire previously allocated /22 from their
        upstream ISP. This allocation (/22) may have been provided
        by an ISP's upstream provider(s), and does not have to be
        contiguous address space. The organization must meet the
        requirement of efficient use of 4 /24s.

        * A multi-homed organization must show the efficient
        utilization of an entire previously allocated /23 from their
        upstream ISP. This allocation (/23) may have been provided
        by an ISP's upstream provider(s), and does not have to be
        contiguous address space. The organization must meet the
        requirement of efficient use of 2 /24s.

        * Utilization Reporting and Justification. All other ARIN
        policies regarding the reporting of justification information
        for the allocation of IPv4 and IPv6 address space will remain
        in effect.

Rationale:

ARIN staff have noted that organizations in the Caribbean region have
problems meeting the current criteria due to the fact that the
population in the region is smaller than that of Canada and the US.
There is also a lack of competition with many countries in the region
faced with a monopoly or duopoly situation in terms of transport providers.

To spur development in the region a similar proposal was passed in this
region for the portion of the African region that ARIN administered
prior to the formation of AfriNIC. This proposal seeks a similar outcome.

Timetable for implementation: immediate

Revisions Made:

* 2008-4.02 - Minor edit to specify proposed NRPM section number





From info at arin.net  Wed Oct  8 16:20:07 2008
From: info at arin.net (Member Services)
Date: Wed, 08 Oct 2008 16:20:07 -0400
Subject: [arin-ppml] Policy Proposal 2007-14 - Staff Assessment
Message-ID: <48ED15F7.7090702@arin.net>

Policy Proposal 2007-14
Title: Resource Review Process
Revised: 6 October 2008
Assessment: 8 October 2008

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I. Proposal

Policy Proposal is available below and at:
http://www.arin.net/policy/proposals/2007_14.html

II. Proposal Summary

This policy proposal provides clear policy authority to audit or reclaim
resources, guidelines for how it shall be done, and a guarantee of a
(minimum) six-month grace period so that the current user shall have
time to stop using any resources that will be reclaimed due to
non-compliance.

III. Comments

A. ARIN Staff

1. Section 2c does not reconcile with the RSA, which grants ARIN
authority to request any data necessary and does not specify any sort of
limitation to frequency.

2. Section 3 requires staff to share the results of an audit of an
organization?s resources. Staff often reviews an organization?s
transaction history and resources during fraud or suspicious activity
investigations and feels that it is not always prudent to share those
results.

3. Section 4b uses the term ?single aggregate block? Does this refer to
a single CIDR prefix, or to ?a contiguous range of addresses??

4. Section 7 states that ?no new maintenance fees will be assessed?
while a return or revocation of resources is pending. Fee discussions
are not policy and should be considered separately.

B. ARIN General Counsel

This policy seeks to codify and define those instances where ARIN has
the right to demand data, or seeks to terminate and revoke resources
previously granted. It will guide ARIN, and any reviewing arbitration
required to evaluate a resulting dispute, or revocation, or refusal to
provide data. Writing down the terms of such policies and authorities
may provide greater clarity as well as support for ARIN's application of
such policies. However, this writing can become a serious legal concern
if the language is not carefully constructed or conflicts with the RSA.
Counsel shared some of these concerns with the authors. To date, counsel
has significant legal concerns regarding paragraphs 7 and 8 of the
current draft. Paragraph 7 is a broad and ambiguous description which
could contradict rights and obligations in 12,000 current RSA?s.
Paragraph 8 contains ambiguous language that is potentially overbroad
that addresses legally hazardous rights. Both need careful review.

7. ARIN shall continue to maintain the resource(s) while their return or
revocation is pending, except any maintenance fees assessed during that
period shall be calculated as if the return or revocation was complete.

In Section 8, replace the first sentence, ?ARIN will not reclaim or
revoke Legacy resources in active use, regardless of utilization? with
?This policy does not create any additional authority for ARIN to revoke
legacy address space.?

IV. Resource Impact ? Minimal

The resource impact of implementing this policy is viewed as minimal.
Barring any unforeseen resource requirements, this policy could be
implemented within 30 ? 90 days from the date of the ratification of the
policy by the ARIN Board of Trustees. Depending on the impact to RSD
this may require additional staff. It will require the following:

    * Guidelines Changes
    * Registration System Changes
    * Staff training
    * May increase RSD workload which could slow down response times

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


Policy Proposal 2007-14
Resource Review Process

Author: Owen DeLong, Stephen Sprunk

Proposal Version: 3.1

Date: 6 October 2008

Proposal type: modify

Policy term: permanent

Policy statement:

Add the following to the NRPM:

Resource Review

1. ARIN may review the current usage of any resources maintained in the
ARIN database. The organization shall cooperate with any request from
ARIN for reasonable related documentation.

2. ARIN may conduct such reviews:

a. when any new resource is requested,

b. whenever ARIN has reason to believe that the resources were
originally obtained fraudulently or in contravention of existing policy, or

c. at any other time without having to establish cause unless a prior
review has been completed in the preceding 24 months.

3. ARIN shall communicate the results of the review to the organization.

4. Organizations found by ARIN to be materially out of compliance with
current ARIN policy shall be requested or required to return resources
as needed to bring them into (or reasonably close to) compliance.

4a. The degree to which an organization may remain out of compliance
shall be based on the reasonable judgment of the ARIN staff and shall
balance all facts known, including the organization?s utilization rate,
available address pool, and other factors as appropriate so as to avoid
forcing returns which will result in near-term additional requests or
unnecessary route de-aggregation.

4b. To the extent possible, entire blocks should be returned. Partial
address blocks shall be returned in such a way that the portion retained
will comprise a single aggregate block.

5. If the organization does not voluntarily return resources as
requested, ARIN may revoke any resources issued by ARIN as required to
bring the organization into overall compliance. ARIN shall follow the
same guidelines for revocation that are required for voluntary return in
the previous paragraph.

6. Except in cases of fraud, or violations of policy, an organization
shall be given a minimum of six months to effect a return. ARIN shall
negotiate a longer term with the organization if ARIN believes the
organization is working in good faith to substantially restore
compliance and has a valid need for additional time to renumber out of
the affected blocks.

7. ARIN shall continue to provide services for the resource(s) while
their return or revocation is pending, however, any maintenance fees
assessed during that period shall be calculated as if the return or
revocation was complete.

8. ARIN will not reclaim or revoke Legacy resources in active use,
regardless of utilization. However, the utilization of legacy resources
shall be considered during a review to assess overall compliance.

9. In considering compliance with policies which allow a timeframe (such
as a requirement to assign some number of prefixes within 5 years),
failure to comply cannot be measured until after the timeframe specified
in the applicable policy has elapsed. Blocks subject to such a policy
shall be assumed in compliance with that policy until such time as the
specified time since issuance has elapsed.

Delete NRPM sections 4.1.2, 4.1.3, 4.1.4

Remove the sentence "In extreme cases, existing allocations may be
affected." from NRPM section 4.2.3.1.

Rationale:

Under current policy and existing RSAs, ARIN has an unlimited authority
to audit or review a resource holder's utilization for compliance at any
time and no requirement to communicate the results of any such review to
the resource holder.

This policy attempts to balance the needs of the community and the
potential for abuse of process by ARIN in a way that better clarifies
the purpose, scope, and capabilities of ARIN and codifies some
appropriate protections for resource holders while still preserving the
ability for ARIN to address cases of fraud and abuse on an expedited basis.

The intended nature of the review is to be no more invasive than what
usually happens when an organization applies for additional resources.
Additionally, paragraph 2c prevents ARIN from doing excessive
without-cause reviews.

The authors believe that this update addresses the majority of the
feedback received from the community to date and addresses most of the
concerns expressed.







From info at arin.net  Wed Oct  8 16:20:38 2008
From: info at arin.net (Member Services)
Date: Wed, 08 Oct 2008 16:20:38 -0400
Subject: [arin-ppml] Policy Proposal 2008-2 - Staff Assessment
Message-ID: <48ED1616.3000005@arin.net>

Policy Proposal 2008-2
Title:  IPv4 Transfer Policy (authors ARIN AC)
Revised:  18 September 2008	
Revised Assessment:  8 October 2008

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.      Proposal

Policy Proposal is available below and at:
http://www.arin.net/policy/proposals/2008_2.html

II.      Proposal Summary

ARIN staff understands that this proposal introduces a new set of
criteria to justify transfers of IPv4 address space. Specifically, the
existing Transfer Policy sections are consolidated from three sections
to two (8.1 and 8.2) and a new section 8.3 is added that defines
criteria for ?Simple Transfers?, which allow an organization with excess
IPv4 addresses to transfer those addresses to an organization with a
need for additional IPv4 addresses, and creates a listing service to
bring the two parties together.

III.     Issues and Concerns

A.      ARIN Staff Comments:

1.	The second paragraph of 8.1 states that ?number resources are
assigned to an organization for its exclusive use for the purpose stated
in the request, provided the terms of the Registration Services
Agreement continue to be met?.  Not all number resources involved in a
transfer are covered under an ARIN RSA.  If this is the intent of this
policy, it should be explicitly stated.

2.	In addition, ?the stated purpose? for the original allocation may be
difficult for an organization to provide given the requester may not be
the original holder of the number resources.

3.	The newly proposed title for section 8.2 ?Transfers as an Artifact of
Change in Resource Holder Ownership? is overly complex and may be
difficult for readers to discern what this section pertains to which may
result in them bypassing this section altogether.

4.	 In addition, this title refers to ?resource holder ownership? ? this
directly conflicts with the existing transfer policy text and the RSA
which both state that number resources are not ?owned?.  Staff suggests
that the existing title for this section ?Transfer Requirements? be
retained for clarity and consistency.

5.	 The newly proposed title for section 8.2 .1 ?Documentation
Requirement for Transfers as an Artifact of Change in Resource Holder
Ownership? is overly complex and may be difficult for readers to discern
what this section pertains to, which may result in them bypassing this
section altogether.

6.	 In addition, the title refers to ?resource holder ownership? - this
directly conflicts with the existing transfer policy text and the RSA
which state that number resources are not ?owned?.  Staff suggests that
the existing title for this section ?Document Requirements? be retained
for clarity and consistency.

7.	In section 8.3.3 the statement ?The IPv4 block must currently be
registered for use within the ARIN service area? is unclear and should
be further defined by the author so that staff has a clear understanding
of how to apply this criteria.

8.	This policy proposal addresses the same subject matter as 2008-2.
They both specify requirements that Transferor and address space be
recognized by ARIN, Transferee demonstrate need and Transferee sign an
RSA. Additionally, they both include provisions on deaggregation,
minimum prefix size and directory services. They differ  in that this
policy is not limited in duration and it does provide criteria on
matters such as facilitating and establishing eligibility for the transfer.



B.    ARIN General Counsel

Counsel believes passage of 2008-2 is better for ARIN than continuing
its current policy that is highly restrictive in the right of parties to
transfer number resources.

Notes:

This policy is a major departure from existing ARIN policy which has
generally prohibited transfers except in specific, limited
circumstances. We therefore address the overall intent of the policy
from a legal perspective.

No matter what transfer policy ARIN implements, it seems likely that
there will be more disputes, and hence more legal risk, once ARIN can no
longer satisfy requests for v4 resources.  But if ARIN continues its
existing community created policy to prohibit most transfers, counsel
anticipates that widespread transfers in conflict with ARIN?s current
policy would nonetheless occur -- imposing significant future legal
costs including the costs of investigation, revocation, arbitration, and
litigation.  A more permissive transfer policy would likely relieve ARIN
of legal risks and costs.  We therefore seek to balance risks created by
the community?s adoption of the proposed policy compared to the risks of
retaining the current policy.

By creating a well understood set of rules for transfer of v4 resources,
the transfer of which are currently prohibited, the policy arguably
advances competition.

The final wording of any transfer policy will have to be carefully
reviewed to ensure it supports to the bedrock legal theory of the
Internet community that numbers are not "owned."  In particular, ARIN
must be able to demonstrate that what is being transferred is the right
to make beneficial use of number resources consistent with applicable
policy, but not ownership. We currently have no concerns in this regard
about the language of this proposal.  The current draft of 2008-2 is
sufficiently ?built out? to provide guidance on many issues.


IV. Resource Impact ? High

The resource impact of implementing this policy is high. Barring any
unforeseen resource requirements, this policy could be implemented in
excess of 180 days from the date of the ratification of the policy by
the ARIN Board of Trustees.  It will require the following:
? Significant staff training, particularly in relation to maintaining a
listing service
? A new template
? Updates to guidelines
? New hardware may be required
? A new set of processes and procedures regarding pre-qualification,
certification, transfer and the listing service will need to be
developed and all corresponding software/ tools will need to be developed.
? A system for maintaining a log of all ?simple? transfers will need to
be developed
? The mechanism and access restrictions for the listing service will
need to be developed.

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: 18 September 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 De-aggregation 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
de-aggregation.

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 info at arin.net  Wed Oct  8 16:21:07 2008
From: info at arin.net (Member Services)
Date: Wed, 08 Oct 2008 16:21:07 -0400
Subject: [arin-ppml] Policy Proposal 2008-3 - Staff Assessment
Message-ID: <48ED1633.2020601@arin.net>

Policy Proposal 2008-3
Title: Community Networks IPv6 Allocation
Revised: 16 September 2008
Revised Assessment: 8 October 2008


ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I. Proposal

Policy Proposal is available below and at:
http://www.arin.net/policy/proposals/2008_3.html

II. Proposal Summary

ARIN staff understands this policy would provide an IPv6 assignment of a
/48 or larger to any community network that has at least 100 users and,
if it has less than 200 users, projects to double its user base within
one year.


III. Issues and concerns

A. ARIN Staff Comments

No modification to section 6.5.8.1b is necessary. The new section 6.5.9
contains all necessary policy information.

The policy text for 6.5.9.3 requires the community network to provide a
plan for doubling its user base within one year if it currently has less
than 200 users. This would penalize networks that are close to the 200
user requirement. For example, a network with 199 users would need to
show a plan for 398 users within one year, while a network with 100
users would need to show a plan for 200 users within a year. A network
with 200 users wouldn?t need to provide any plan to double its user
base, even though it has just one more user than the network with 199.
Is this intended? If not, the requirement should be converted to a hard
target, such as ?must show a plan to provide service to at least 200
users within one year?.

For clarity, 6.5.9 should follow the format established by current
section 6.5.8.

Section 6.5.9.1 should be entitled "Qualification Criteria" and contain
the text in 6.5.9.3. A suggested wording based on the concerns expressed
in #2 above is:
6.5.9.1 Qualification Criteria
To qualify for a direct assignment, a community network must demonstrate
it will immediately provide service to at least 100 users and must
demonstrate a plan to provide service to at least 200 users within one year.

Section 6.5.9.2 ("Initial assignment size") should have the text
currently listed as 6.5.9.1 with the first sentence removed.

Section 6.5.9.3 ("Subsequent assignment size") should have the text
currently listed as 6.5.9.2.

B. ARIN General Counsel

Counsel sees no significant legal or litigation risk regarding this policy.

IV. Resource Impact - Minimal

The resource impact of implementing this policy is minimal. Barring any
unforeseen resource requirements, this policy could be implemented
within 120 days from the date of the ratification of the policy by the
ARIN Board of Trustees. It will require the following:

- New template
- Registration software changes
- New set of guidelines
- Staff training

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  Wed Oct  8 16:21:57 2008
From: info at arin.net (Member Services)
Date: Wed, 08 Oct 2008 16:21:57 -0400
Subject: [arin-ppml] Policy Proposal: 2008-5 - Staff Assessment
Message-ID: <48ED1665.7020805@arin.net>

Policy Proposal: 2008-5
Title: Dedicated IPv4 block to facilitate IPv6 deployment
Submitted: 6 June 2008
Assessment: 8 October 2008


ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I. Proposal

Policy Proposal is available below and at:
http://www.arin.net/policy/proposals/2008_5.html

II. Proposal Summary

ARIN staff understands that this policy would set aside a contiguous /10
to facilitate IPv6 deployment when ARIN receives its last /8 from IANA.

III. Comments

A. ARIN Staff

1. The timeframe for ?immediate IPv6 deployment requirements? is not
defined anywhere within this policy. It is unclear whether staff would
issue a 30 day supply of addresses or a 6 month supply.

2. In section 3 of this policy, the author says ?previous
allocations/assignments under this policy must meet the utilization
requirements of end user assignments. Is the author saying that for
subsequent allocations under this policy, the requestor must be at 80%
utilization? If so, then this needs to be stated explicitly rather than
referring to the current end user policy which is subject to change over
time.

3. Section 6 says that ?recipient organizations must be members in good
standing of ARIN ? Membership isn't currently required to request new
resources from ARIN and end users who currently hold resources from ARIN
are generally not members of ARIN unless they pay a separate $500
membership fee. If the intent of this item is to ensure that all
organizations requesting resources under this policy have no outstanding
bills due to ARIN, then this is not needed because it is a current ARIN
business practice. ARIN will continue to issue resources only to
organizations that have paid their bills.

4. The policy proposal will affect DNS operations for independent
allocations made that are longer than a /24.


B. ARIN General Counsel

Counsel sees no significant legal or litigation risk regarding this policy.

IV. Resource Impact ? Moderate

The resource impact of implementing this policy is viewed as minimal.
Barring any unforeseen resource requirements, this policy could be
implemented within 120-180 days from the date of the ratification of the
policy by the ARIN Board of Trustees. It will require the following:

? Updates to Guidelines will be required.
? Staff training will be required.
? The minimum/maximum block sizes, defined range, and sparse allocation
required by this policy would require software changes to registration
software.
? Operational modifications and guidelines for managing reverse DNS for
allocations longer than a /24 will be required.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


Policy Proposal 2008-5
Dedicated IPv4 block to facilitate IPv6 deployment

Author: Alain Durand

Date: 6 June 2008

Proposal type: New

Policy term: Permanent

Policy statement:

When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
or NAT464 translators. ARIN staff will use their discretion when
evaluating justifications.

This block will be subject to a minimum size allocation of /28 and a
maximum size allocation of /24. ARIN should use sparse allocation when
possible within that /10 block.

In order to receive an allocation or assignment under this policy:

   1. the applicant may not have received resources under this policy in
      the preceding six months;
   2. previous allocations/assignments under this policy must continue
      to meet the justification requirements of this policy;
   3. previous allocations/assignments under this policy must meet the
      utilization requirements of end user assignments;
   4. the applicant must demonstrate that no other allocations or
      assignments will meet this need;
   5. on subsequent allocation under this policy, ARIN staff may require
      applicants to renumber out of previously allocated / assigned
      space under this policy in order to minimize non-contiguous
      allocations;
   6. recipient organizations must be members in good standing of ARIN.

Rationale for reserving IPv4 space:

This policy provides predictability on how the end game of IPv4 is going
to be played after IANA completion. It will facilitate IPv6 deployment
by ensuring that some small chunks of IPv4 space will remain available
for a long time to ease the co-existence of IPv4 & IPv6.

Rationale for reserving a contiguous /10

This is a balance between setting aside too much space and not having
enough to facilitate IPv6 deployment for many years. Out of the last /8,
that would leave the equivalent of 3 /10 to ARIN either for business as
usual or for other policies in the spirit of this one.

A /10 represents 4,194,304 IP addresses, If all of them were to be used
in NAT-PT or NAT464 type devices with a consolidation factor of 100
users behind each IP address, that would represent about 400 million users.

Most networks today filter IPv4 announcements more specific than /24.
This policy creates allocations & assignment prefixes as long as /28.
Allocating out of a contiguous block will mitigate the impact of this
policy on filter lists.

Rationale for minimum size allocation of /28

This minimum size allocation will put a cap at 250k additional entries
in the global IPv4 routing table.

Rationale for maximum size allocation of /24 and for the 6 month delay
between allocations

This maximum allocation size coupled with the requirement of a 6 months
delay between allocations will prevent hoarding and make sure this pool
will last several years.

Rationale for forced renumbering for further allocation

The minimum allocation size of /28 may create a huge increase in the
IPv4 routing table size. Forcing renumbering for subsequent allocations
under this policy will somehow limit the growth of the routing table
size by enabling the announcement of aggregated space. It is expected
that the savings in routing table entries will outweigh the pain of
forced renumbering.

However, renumbering is never an easy task, so it should only be
considered as last resort. it is expected that sparse allocation
techniques will prevent the need of force renumbering for a fairly long
time.

Note: This policy proposal hints that the /10 should come out of the
last /8 received by ARIN from IANA. However, it does not say so
explicitly, leaving the final decision up to the ARIN staff.

Timetable for implementation:

As soon as ARIN gets its last /8 allocation from IANA.





From info at arin.net  Wed Oct  8 16:22:23 2008
From: info at arin.net (Member Services)
Date: Wed, 08 Oct 2008 16:22:23 -0400
Subject: [arin-ppml] Policy Proposal 2008-6 - Staff Assessment
Message-ID: <48ED167F.5050000@arin.net>

Policy Proposal 2008-6
Title: Emergency Transfer Policy for IPv4 Addresses
Submitted: 15 August 2008
Assessment: 8 October 2008


ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I. Proposal

Policy Proposal is available below and at:
http://www.arin.net/policy/proposals/2008_6.html

II. Proposal Summary

ARIN staff understands that this policy would create a second set of
transfer requirements when implemented. A resource holder deemed
legitimate by ARIN may transfer IPv4 addresses to a recipient that
qualifies for IPv4 addresses as long as the original block isn't broken
into more than four blocks.


III. Comments

A. ARIN Staff

1. The meaning of "without the active involvement of ARIN" in the first
sentence is unclear and should be further defined by the author.

2. Section 1 indicates the transfer must be done by the "legitimate and
exclusive holder of those resources". The term ?legitimate and exclusive
holder? is vague and must be clearly defined with accompanying criteria
to help staff determine who is eligible to transfer resources under this
policy.


3. Section 2 says that the recipient must have ?documented operational
need in accordance with current ARIN policy?. Current ARIN policies do
not allow the issuance of /23s and /24s with the exception of the
micro-allocation policy. This would indicate that no organization would
be allowed to transfer /23s and /24s under this policy unless they could
qualify under the micro-allocation policy which has very limited
eligibility.

4. This policy would become 8.4 in the NRPM and not 8.2.1 as indicated.

5. This policy proposal addresses the same subject matter as 2008-2.
They both specify requirements that Transferor and address space be
recognized by ARIN, Transferee demonstrate need and Transferee sign an
RSA. Additionally, they both include provisions on deaggregation,
minimum prefix size and directory services. They are distinguishable in
a number of other respects: for example, this policy would only be in
effect for three (3) years from its implementation, unlike 2008-2, and
it does not include specific criteria on matters such as facilitating
and establishing eligibility for the transfer. For a complete list of
differences, see comparison attached.



B. ARIN General Counsel

Counsel believes passage of an additional, more permissive transfer
policy would reduce potential legal risks and costs to ARIN arising from
transfer disputes as available IPv4 address space is depleted.
Specifically, counsel believes passage of 2008-2 or 2008-6 is better for
ARIN than continuing its current policy that is highly restrictive in
the right of parties to transfer number resources.

We now turn to more specific concerns of this particular transfer policy.

This policy is a major departure from existing ARIN policy which has
generally prohibited transfers except in specific, limited
circumstances. We therefore address the overall intent of the policy
from a legal perspective.

The first legal concern in evaluating the specifics of any transfer
policy is whether it is consistent with antitrust law. Currently, this
policy does not create concerns. By creating a white market for transfer
of v4 resources, the policy arguably advances competition. In this
regard, there is no difference between 2008-2 and 2008-6.

Second, any new policy should be consistent with the legal theory of the
Internet community that numbers are not "owned." We have no concerns
about the language of this proposal in this regard. In this regard,
there is no difference between 2008-2 and 2008-6.

No matter what transfer policy ARIN implements, it seems likely that
there will be more disputes, and hence more legal risk, once ARIN can no
longer satisfy requests for v4 resources. But if ARIN continues its
existing community created policy to prohibit most transfers, counsel
anticipates that widespread transfers in conflict with ARIN?s current
policy would nonetheless occur ? imposing significant future legal costs
including the costs of investigation, revocation, arbitration, and
litigation. A carefully drafted but more permissive transfer policy
would likely relieve ARIN of legal risks and cost. We therefore seek to
balance risks created by the community?s adoption of the proposed policy
compared to the risks of retaining the current policy. This policy could
lead to future legal costs due to disputes arising from the lack of
specific criteria on transfer eligibility and other matters, which ARIN
staff would need to supply, and which would not have a community
consensus as a standards defense. Choosing between 2008-2 and 2008-6
should reflect the community evaluation of whether the additional issues
addressed in 2008-2 are correctly stated, or those issues are best left
to future policy development or staff interpretation. If a court were to
construe an application of 2008-6 if adopted, the court might find any
issue explicitly addressed in 2008-2 and not in 2008-6 cannot be applied
as interpretive policy.


IV. Resource Impact ? Minimal

The resource impact of implementing this policy is viewed as minimal.
Barring any unforeseen resource requirements, this policy could be
implemented within 90 days from the date of the ratification of the
policy by the ARIN Board of Trustees. It will require the following:

? Updates to Guidelines will be required
? Staff training will be required

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


Policy Proposal 2008-6
Emergency Transfer Policy for IPv4 Addresses

Author: Bill Darte

Date: 26 August 2008

Proposal type: New

Policy term: Temporary

Policy statement:

8.2.1 Emergency Transfer Policy for IPv4 Addresses

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:

1. Transfer takes place from a holder of IPv4 addresses recognized by
ARIN as the legitimate and exclusive holder of those resources.

2. Transfer takes place to a recipient that has documented operational
need in accordance with current ARIN policy and that signs an RSA with
ARIN covering those resources in advance of transfer.

3. Transfer of addresses takes place in such a way that the original
contiguous block(s) are not disaggregated into more than 4 resultant
network blocks each being greater than or equal to the current minimum
sizes specified in applicable ARIN policy.

4. Transfer is complete and unrestricted and is supported by
documentation that ARIN deems satisfactory.

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.

Timetable for implementation:

This policy, once ratified by the ARIN Board of Trustees, would be
implemented when either the free-pool of IANA addresses is exhausted or
IPv4 address resources in the ARIN Region reaches a threshold of
scarcity recognized by the ARIN Board of Trustees as requiring this
policy implementation.

#######################################################

2008-6 and 2008-2 Compared


1. Issues Addressed in Both Policies:

? Transferor and address space recognized by ARIN

? Transferee demonstrates need

? Transferee signs RSA

? Deaggregation

	o 8-2: Unlimited

	o 8-6: Not more than 4 pieces (each greater than minimum prefix size)

? Minimum prefix size

	o 8-2: /24

	o 8-6: Based on current policy.

? Directory Services

	o WHOIS updated

2. Policy Guidance is included in 2008-2, but not found in 2008-6:

? Conditions on the transferor (source)

	o No outstanding balance

	o Has not received space from ARIN in preceding 12 months

	o If retains portion of space, must sign SA

? Conditions on the transferee (recipient)

	o Intent to use space in ARIN service area

	o No outstanding balance

	o Not more than a 12-month supply

	o Not more often than once per 6 months

? Safe harbor text

	o Availability for transfer does not give okay to ARIN to take it back.

? Organizations under Common Ownership or Control

	o ARIN may consider this during requests.

? Listing Service

	o Voluntary

? Directory Services

	o Log of transfers

<end>





From info at arin.net  Wed Oct  8 16:22:48 2008
From: info at arin.net (Member Services)
Date: Wed, 08 Oct 2008 16:22:48 -0400
Subject: [arin-ppml] Policy Proposal 2008-7 - Staff Assessment
Message-ID: <48ED1698.4030006@arin.net>

Policy Proposal 2008-7
Title: Whois Integrity Policy Proposal
Submitted: 15 August 2008
Assessment: 8 October 2008


ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I. Proposal

Policy Proposal is available below and at:
http://www.arin.net/policy/proposals/2008_7.html

II. Proposal Summary

ARIN staff understands that this policy would require that a resource be
covered by a valid ARIN RSA before it can be updated.


III. Comments

A. ARIN Staff

1. Requiring all requestors to have a signed RSA (Legacy or Standard)
prior to ARIN making any updates to their records could cause a serious
delay in the completion of the update which could negatively affect an
organization?s business.
2. This policy may cause additional information to become stale in Whois
since non-RSA/LRSA signatories will no longer be able to update their
information.
3. Since reverse DNS data is part of WHOIS data, a delay in processing
or a refusal to process delegation update requests could negatively
impact requestor?s DNS operations even if the contact information in
WHOIS is correct.



B. ARIN General Counsel

Clearly protecting or enhancing the accuracy of Whois data is an
appropriate goal of standard setting, and if that creates collateral
requirements, they are likely to be upheld by any reviewing legal authority.

ARIN currently provides free services to legacy holders, including those
who have no written agreement with ARIN for specific legacy resources,
and makes changes for them in Whois that conform to other policies. ARIN
has never adopted a policy requiring such free services be provided by
ARIN but has customarily done this for legacy holders. This policy would
change ARIN?s customary practice by requiring such a written agreement
before ARIN would continue to provide such free services as changing
Whois data. From the standpoint of legal obligations, counsel is not
aware of any legal theory that would require ARIN to continue to provide
free services if it chose to discontinue providing such services for free.

It is likely enactment of the current draft may result in litigation
testing why the policy was enacted and whether it is reasonably related
to achievement of an appropriate standard setting objective.

One or more legacy holder(s) might object to this new requirement for a
written agreement that requires a series of contractual promises by the
legacy holder claiming such a step violates antitrust or other aspects
of legally protected commerce policies. They may also argue that since
ARIN could charge a fee for service as one alternative to requiring a
more comprehensive written agreement, the requirement for the more
extensive agreement is legally impermissible.

IV. Resource Impact ?Major
The resource impact of implementing this policy is viewed as major.
Barring any unforeseen resource requirements, this policy could take
over 180 days to be implemented from the date of the ratification of the
policy by the ARIN Board of Trustees. It will require the following:

? Updates to Guidelines
? Staff training
? New software tools will need to be developed that will identify
whether a resource is covered under a RSA.
? Existing software tools will need to be modified to flag those
resources that are not covered by a RSA for analysis by staff.
? May require additional staff to handle increased number of manually
processed requests.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


Policy Proposal 2008-7
Whois Integrity Policy Proposal

Author: Heather Schiller

Date: 26 August 2008

Policy statement:

To ensure the integrity of information in the ARIN WHOIS Database a
resource must be under an RSA (either legacy or traditional) in order to
update the WHOIS record. ARIN will not update historical information in
the ARIN Whois Database until the resource holder can prove the
organization's right to the resource.

Rationale:

ARIN currently maintains WHOIS and in-addr.arpa delegation records in a
best-effort fashion. In many cases ARIN does not have a formal agreement
with the legacy resource holders. Legacy records are frequently out of
date and have become an increasingly popular target for hijackers.
Having up to date contact information and a formal
relationship with legacy record holders would assist ARIN and ISP's in
ensuring these records are maintained accurately. A similar policy was
successfully adopted in the APNIC region.
(http://www.apnic.net/policy/proposals/prop-018-v001.html)

Timetable for implementation:

Within sixty (60) days of approval - with notification to current POC
email addresses listed on historical assignments, or as soon as
reasonable for ARIN staff.





From sleibrand at internap.com  Wed Oct  8 17:07:45 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 08 Oct 2008 14:07:45 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48ED15BD.9060904@arin.net>
References: <48ED15BD.9060904@arin.net>
Message-ID: <48ED2121.4090901@internap.com>

Does staff's understanding of the geographic applicability of this policy 
proposal match the intent of the authors and supporters?  I'm not sure 
whether the Bouvet Islands, US Minor Outlying Islands, St Pierre and 
Miquelon, Heard and McDonald Islands and/or St Helena fit within the 
intended scope or not...

-Scott

Member Services wrote:
> Policy Proposal: 2008-4
> Title: Minimum Allocation in the Caribbean Region
> Revised: 18 August 2008
> Assessment: 8 October 2008
> 
> ARIN Staff Assessment
> 
> The assessment of this proposal includes comments from ARIN staff and
> the ARIN General Counsel. It contains analysis of procedural, legal, and
> resource concerns regarding the implementation of this policy proposal
> as it is currently stated. Any changes to the language of the proposal
> may necessitate further analysis by staff and Counsel.
> 
> I. Proposal
> 
> Policy Proposal is available below and at:
> http://www.arin.net/policy/proposals/2008_4.html
> 
> II. Proposal Summary
> 
> ARIN staff understands that this policy would lower the minimum
> allocation size to a /22 for ISPs in the Caribbean region. The ARIN
> Caribbean service area consists of the locations listed at
> http://www.arin.net/community/ARINcountries.html, with the exception of
> the US, Canada, Antarctica, Bouvet Islands, US Minor Outlying Islands,
> St Pierre and Miquelon, Heard and McDonald Islands and St Helena.
> 
> III. Comments
> 
> A. ARIN Staff
> 
> 1. Staff foresees no implementation problems with this policy.
> 2. End-users are excluded from this policy which might be viewed as
> offering an unfair advantage to ISPs in the region.
> 
> B. ARIN General Counsel
> 
> Counsel sees no significant legal or litigation risk regarding this policy.
> 
> 
> IV. Resource Impact ? Minimal
> 
> The resource impact of implementing this policy is viewed as minimal.
> Barring any unforeseen resource requirements, this policy could be
> implemented within 30 ? 90 days from the date of the ratification of the
> policy by the ARIN Board of Trustees. It will require the following:
> 
> ? Updates to Guidelines will be required
> ? Staff training will be required
> ? Updates to the ARIN web page of the ?List of Countries in ARIN?s
> Geographical Areas? to indicate which countries are considered part of
> the Caribbean region will be required.
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> #####
> 
> 
> Policy Proposal 2008-4
> Minimum Allocation in the Caribbean Region
> 
> Author: Cathy Aronson and Paul Andersen
> 
> Date: 18 August 2008
> 
> Proposal type: new
> 
> Policy term: renewable
> 
> Policy statement:
> 
> Add the following as section 4.8 of NRPM:
> 
> 4.8. Minimum Allocation. The minimum IPv4 allocation size for ISPs from
> the Caribbean portion of the ARIN region is /22.
> 
>     4.8.1. Allocation Criteria.
> 
>         * The requesting organization must show the efficient
>         utilization of an entire previously allocated /22 from their
>         upstream ISP. This allocation (/22) may have been provided
>         by an ISP's upstream provider(s), and does not have to be
>         contiguous address space. The organization must meet the
>         requirement of efficient use of 4 /24s.
> 
>         * A multi-homed organization must show the efficient
>         utilization of an entire previously allocated /23 from their
>         upstream ISP. This allocation (/23) may have been provided
>         by an ISP's upstream provider(s), and does not have to be
>         contiguous address space. The organization must meet the
>         requirement of efficient use of 2 /24s.
> 
>         * Utilization Reporting and Justification. All other ARIN
>         policies regarding the reporting of justification information
>         for the allocation of IPv4 and IPv6 address space will remain
>         in effect.
> 
> Rationale:
> 
> ARIN staff have noted that organizations in the Caribbean region have
> problems meeting the current criteria due to the fact that the
> population in the region is smaller than that of Canada and the US.
> There is also a lack of competition with many countries in the region
> faced with a monopoly or duopoly situation in terms of transport providers.
> 
> To spur development in the region a similar proposal was passed in this
> region for the portion of the African region that ARIN administered
> prior to the formation of AfriNIC. This proposal seeks a similar outcome.
> 
> Timetable for implementation: immediate
> 
> Revisions Made:
> 
> * 2008-4.02 - Minor edit to specify proposed NRPM section number
> 
> 
> 
> _______________________________________________
> 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  Wed Oct  8 17:21:53 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 8 Oct 2008 17:21:53 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48ED2121.4090901@internap.com>
References: <48ED15BD.9060904@arin.net> <48ED2121.4090901@internap.com>
Message-ID: <20081008212153.GA74653@ussenterprise.ufp.org>

In a message written on Wed, Oct 08, 2008 at 02:07:45PM -0700, Scott Leibrand wrote:
> Does staff's understanding of the geographic applicability of this policy 
> proposal match the intent of the authors and supporters?  I'm not sure 
> whether the Bouvet Islands, US Minor Outlying Islands, St Pierre and 
> Miquelon, Heard and McDonald Islands and/or St Helena fit within the 
> intended scope or not...

I had to research.  With the exception of the US Minor Outlying
Islands I think the rest would be rather surprised to find that
they were "Caribbean", at least if climate has anything to do with
it.  :)

That said, there is still an interesting question here if they
should be included in the policy for the same general reasons as
the Caribbean islands, some info, and my take below.


http://en.wikipedia.org/wiki/Bouvet_Island

  "Despite being uninhabited, ..."

  My take: Doesn't really matter.

http://en.wikipedia.org/wiki/US_Minor_Outlying_Islands

  "The United States Minor Outlying Islands, a statistical designation
   defined by the International Organization for Standardization's ISO
   3166-1 code, consists of nine United States insular areas.

   Palmyra Atoll is the only incorporated territory. As of 2008, none of
   the islands has any permanent residents. The only population are
   temporarily stationed scientific and military personnel..."

  My take: Doesn't really matter.

http://en.wikipedia.org/wiki/Saint_Pierre_and_Miquelon

  "The population of Saint-Pierre and Miquelon at the 2006 local census
   was 6,125 inhabitants."

  My take: Seems like they would likely have the same issues as the
           Caribbean.

http://en.wikipedia.org/wiki/Heard_Island_and_McDonald_Islands

  "Heard Island and McDonald Islands (abbreviated as HIMI[1]) are barren
   islands located in the Southern Ocean, about two-thirds of the way from
   Madagascar to Antarctica, 7718 km due south of Rajapur, Maharashtra,
   India[2] and approximately 4099 km west of Perth.[3] They have been
   territories of Australia since 1947..."

  My take: Why isn't this in APNIC?  It's been an Australia territory
           since before the RIR system.  I'd like a history lesson as
           to why this stayed with ARIN.

http://en.wikipedia.org/wiki/St_Helena

  "Saint Helena has a small population of about 4,250 inhabitants,..."

  My take: Seems like they would likely have the same issues as the
           Caribbean.  LACNIC / AfriNIC would seem to make more sense
           from a geographic point of view, but RIPE from a geopolitical
           point of view.  Seems a bit odd this one stayed with ARIN as
           well.

That was an educational diversion.

-- 
       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/20081008/a77225e5/attachment.sig>

From sleibrand at internap.com  Wed Oct  8 17:28:01 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 08 Oct 2008 14:28:01 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081008212153.GA74653@ussenterprise.ufp.org>
References: <48ED15BD.9060904@arin.net> <48ED2121.4090901@internap.com>
	<20081008212153.GA74653@ussenterprise.ufp.org>
Message-ID: <48ED25E1.3010204@internap.com>

Interesting stuff.  As all of these are either uninhabited or are 
territories of RIPE and APNIC countries, it sounds to me like no changes 
to the policy are needed.  If anyone representing these locations 
disagrees, please speak up: you'll be the most authoritative one here.  :)

-Scott

Leo Bicknell wrote:
> In a message written on Wed, Oct 08, 2008 at 02:07:45PM -0700, Scott Leibrand wrote:
>> Does staff's understanding of the geographic applicability of this policy 
>> proposal match the intent of the authors and supporters?  I'm not sure 
>> whether the Bouvet Islands, US Minor Outlying Islands, St Pierre and 
>> Miquelon, Heard and McDonald Islands and/or St Helena fit within the 
>> intended scope or not...
> 
> I had to research.  With the exception of the US Minor Outlying
> Islands I think the rest would be rather surprised to find that
> they were "Caribbean", at least if climate has anything to do with
> it.  :)
> 
> That said, there is still an interesting question here if they
> should be included in the policy for the same general reasons as
> the Caribbean islands, some info, and my take below.
> 
> 
> http://en.wikipedia.org/wiki/Bouvet_Island
> 
>   "Despite being uninhabited, ..."
> 
>   My take: Doesn't really matter.
> 
> http://en.wikipedia.org/wiki/US_Minor_Outlying_Islands
> 
>   "The United States Minor Outlying Islands, a statistical designation
>    defined by the International Organization for Standardization's ISO
>    3166-1 code, consists of nine United States insular areas.
> 
>    Palmyra Atoll is the only incorporated territory. As of 2008, none of
>    the islands has any permanent residents. The only population are
>    temporarily stationed scientific and military personnel..."
> 
>   My take: Doesn't really matter.
> 
> http://en.wikipedia.org/wiki/Saint_Pierre_and_Miquelon
> 
>   "The population of Saint-Pierre and Miquelon at the 2006 local census
>    was 6,125 inhabitants."
> 
>   My take: Seems like they would likely have the same issues as the
>            Caribbean.
> 
> http://en.wikipedia.org/wiki/Heard_Island_and_McDonald_Islands
> 
>   "Heard Island and McDonald Islands (abbreviated as HIMI[1]) are barren
>    islands located in the Southern Ocean, about two-thirds of the way from
>    Madagascar to Antarctica, 7718 km due south of Rajapur, Maharashtra,
>    India[2] and approximately 4099 km west of Perth.[3] They have been
>    territories of Australia since 1947..."
> 
>   My take: Why isn't this in APNIC?  It's been an Australia territory
>            since before the RIR system.  I'd like a history lesson as
>            to why this stayed with ARIN.
> 
> http://en.wikipedia.org/wiki/St_Helena
> 
>   "Saint Helena has a small population of about 4,250 inhabitants,..."
> 
>   My take: Seems like they would likely have the same issues as the
>            Caribbean.  LACNIC / AfriNIC would seem to make more sense
>            from a geographic point of view, but RIPE from a geopolitical
>            point of view.  Seems a bit odd this one stayed with ARIN as
>            well.
> 
> That was an educational diversion.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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  Wed Oct  8 18:16:35 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 8 Oct 2008 22:16:35 +0000
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48ED25E1.3010204@internap.com>
References: <48ED15BD.9060904@arin.net> <48ED2121.4090901@internap.com>
	<20081008212153.GA74653@ussenterprise.ufp.org>
	<48ED25E1.3010204@internap.com>
Message-ID: <20081008221635.GB23930@vacation.karoshi.com.>


	the staff recommendation was to -exclude- these from
	the specific proposals dealing w/ caribbean issues on
	minimum allocation sizes.

--bill


On Wed, Oct 08, 2008 at 02:28:01PM -0700, Scott Leibrand wrote:
> Interesting stuff.  As all of these are either uninhabited or are 
> territories of RIPE and APNIC countries, it sounds to me like no changes 
> to the policy are needed.  If anyone representing these locations 
> disagrees, please speak up: you'll be the most authoritative one here.  :)
> 
> -Scott
> 
> Leo Bicknell wrote:
> > In a message written on Wed, Oct 08, 2008 at 02:07:45PM -0700, Scott Leibrand wrote:
> >> Does staff's understanding of the geographic applicability of this policy 
> >> proposal match the intent of the authors and supporters?  I'm not sure 
> >> whether the Bouvet Islands, US Minor Outlying Islands, St Pierre and 
> >> Miquelon, Heard and McDonald Islands and/or St Helena fit within the 
> >> intended scope or not...
> > 
> > I had to research.  With the exception of the US Minor Outlying
> > Islands I think the rest would be rather surprised to find that
> > they were "Caribbean", at least if climate has anything to do with
> > it.  :)
> > 
> > That said, there is still an interesting question here if they
> > should be included in the policy for the same general reasons as
> > the Caribbean islands, some info, and my take below.
> > 
> > 
> > http://en.wikipedia.org/wiki/Bouvet_Island
> > 
> >   "Despite being uninhabited, ..."
> > 
> >   My take: Doesn't really matter.
> > 
> > http://en.wikipedia.org/wiki/US_Minor_Outlying_Islands
> > 
> >   "The United States Minor Outlying Islands, a statistical designation
> >    defined by the International Organization for Standardization's ISO
> >    3166-1 code, consists of nine United States insular areas.
> > 
> >    Palmyra Atoll is the only incorporated territory. As of 2008, none of
> >    the islands has any permanent residents. The only population are
> >    temporarily stationed scientific and military personnel..."
> > 
> >   My take: Doesn't really matter.
> > 
> > http://en.wikipedia.org/wiki/Saint_Pierre_and_Miquelon
> > 
> >   "The population of Saint-Pierre and Miquelon at the 2006 local census
> >    was 6,125 inhabitants."
> > 
> >   My take: Seems like they would likely have the same issues as the
> >            Caribbean.
> > 
> > http://en.wikipedia.org/wiki/Heard_Island_and_McDonald_Islands
> > 
> >   "Heard Island and McDonald Islands (abbreviated as HIMI[1]) are barren
> >    islands located in the Southern Ocean, about two-thirds of the way from
> >    Madagascar to Antarctica, 7718 km due south of Rajapur, Maharashtra,
> >    India[2] and approximately 4099 km west of Perth.[3] They have been
> >    territories of Australia since 1947..."
> > 
> >   My take: Why isn't this in APNIC?  It's been an Australia territory
> >            since before the RIR system.  I'd like a history lesson as
> >            to why this stayed with ARIN.
> > 
> > http://en.wikipedia.org/wiki/St_Helena
> > 
> >   "Saint Helena has a small population of about 4,250 inhabitants,..."
> > 
> >   My take: Seems like they would likely have the same issues as the
> >            Caribbean.  LACNIC / AfriNIC would seem to make more sense
> >            from a geographic point of view, but RIPE from a geopolitical
> >            point of view.  Seems a bit odd this one stayed with ARIN as
> >            well.
> > 
> > That was an educational diversion.
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > 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  Wed Oct  8 18:44:48 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 08 Oct 2008 15:44:48 -0700
Subject: [arin-ppml] Policy Proposal 2008-2 - Staff Assessment
In-Reply-To: <48ED1616.3000005@arin.net>
References: <48ED1616.3000005@arin.net>
Message-ID: <48ED37E0.1030606@internap.com>

Member Services wrote:
> Policy Proposal 2008-2
> Title:  IPv4 Transfer Policy (authors ARIN AC)
> Revised:  18 September 2008	
> Revised Assessment:  8 October 2008
> 
> ARIN Staff Assessment
> 
<snip>
> A.      ARIN Staff Comments:
> 
> 1.	The second paragraph of 8.1 states that ?number resources are
> assigned to an organization for its exclusive use for the purpose stated
> in the request, provided the terms of the Registration Services
> Agreement continue to be met?.  Not all number resources involved in a
> transfer are covered under an ARIN RSA.  If this is the intent of this
> policy, it should be explicitly stated.
> 
> 2.	In addition, ?the stated purpose? for the original allocation may be
> difficult for an organization to provide given the requester may not be
> the original holder of the number resources.

We have chosen not to change existing transfer policy as part of this 
proposal, except where it directly contradicts the new policy.  I would be 
happy to work with staff, legal, and the community to clean up 8.1, but I 
think that's out of scope here.

> 3.	The newly proposed title for section 8.2 ?Transfers as an Artifact of
> Change in Resource Holder Ownership? is overly complex and may be
> difficult for readers to discern what this section pertains to which may
> result in them bypassing this section altogether.

Apparently so ...

> 4.	 In addition, this title refers to ?resource holder ownership? ? this
> directly conflicts with the existing transfer policy text and the RSA
> which both state that number resources are not ?owned?.  Staff suggests
> that the existing title for this section ?Transfer Requirements? be
> retained for clarity and consistency.

The intent was to refer to "ownership" of the "resource holder", not the 
"resource".  But we obviously need a simpler title, since its meaning is 
unclear even to ARIN staff.  :)

The problem with the existing title "Transfer Requirements" for section 
8.2 is that it could be construed to apply to section 8.3 as well.  The 
change in title was an attempt to make clear that the two sections are 
completely separate and unrelated.

At one point we considered using the title "M&A Transfers", but folks 
(including staff) didn't like that, since M&A wasn't defined, and its 
common usage (Mergers & Acquisitions) doesn't fully cover all the 
situations this section applies to.

Does anyone have any other suggestions for how to retitle the existing 
transfer policy, to make clear it's distinct from the new "Simple 
Transfer" policy?

> 5.	 The newly proposed title for section 8.2 .1 ?Documentation
> Requirement for Transfers as an Artifact of Change in Resource Holder
> Ownership? is overly complex and may be difficult for readers to discern
> what this section pertains to, which may result in them bypassing this
> section altogether.
> 
> 6.	 In addition, the title refers to ?resource holder ownership? - this
> directly conflicts with the existing transfer policy text and the RSA
> which state that number resources are not ?owned?.  Staff suggests that
> the existing title for this section ?Document Requirements? be retained
> for clarity and consistency.

If we can agree on a better title for 8.2, then 8.2.1 can inherit that as 
well.

> 7.	In section 8.3.3 the statement ?The IPv4 block must currently be
> registered for use within the ARIN service area? is unclear and should
> be further defined by the author so that staff has a clear understanding
> of how to apply this criteria.

This was discussed on PPML, and the general sentiment seemed to be that we 
should replace this with: "The IPv4 block 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." 
Would that language be sufficiently clear?

As we're so close to the meeting, I don't want to push a new version of 
the policy out, but if there's consensus for the policy, and for this 
change, I intend to the propose that the AC adopt this clarified wording 
as a minor edit after the meeting.

> 8.	This policy proposal addresses the same subject matter as 2008-2.

I think you mean 2008-6.

> They both specify requirements that Transferor and address space be
> recognized by ARIN, Transferee demonstrate need and Transferee sign an
> RSA. Additionally, they both include provisions on deaggregation,
> minimum prefix size and directory services. They differ  in that this
> policy is not limited in duration and it does provide criteria on
> matters such as facilitating and establishing eligibility for the transfer.

Agreed.  The intent is that we'll consider 2008-2 first.  If there's 
consensus there, Bill will withdraw 2008-6.  If 2008-2 fails to get 
consensus, we'll consider 2008-6.

Thanks,
Scott


From bicknell at ufp.org  Wed Oct  8 19:49:34 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 8 Oct 2008 19:49:34 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081008221635.GB23930@vacation.karoshi.com.>
References: <48ED15BD.9060904@arin.net> <48ED2121.4090901@internap.com>
	<20081008212153.GA74653@ussenterprise.ufp.org>
	<48ED25E1.3010204@internap.com>
	<20081008221635.GB23930@vacation.karoshi.com.>
Message-ID: <20081008234933.GA83884@ussenterprise.ufp.org>

In a message written on Wed, Oct 08, 2008 at 10:16:35PM +0000, bmanning at vacation.karoshi.com wrote:
> 	the staff recommendation was to -exclude- these from
> 	the specific proposals dealing w/ caribbean issues on
> 	minimum allocation sizes.

Yes, however at least one person raised the issue at the Nassau
meeting asking if they should be included, that is, rather than
Caribbean should the language be "ARIN Serivce Region not including
the US and Canada."

As worded, it is Caribbean specific, and I think staff's interpretation
matches the policy.

-- 
       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/20081008/698ad3bb/attachment.sig>

From sleibrand at internap.com  Wed Oct  8 19:55:37 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 08 Oct 2008 16:55:37 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081008234933.GA83884@ussenterprise.ufp.org>
References: <48ED15BD.9060904@arin.net>
	<48ED2121.4090901@internap.com>	<20081008212153.GA74653@ussenterprise.ufp.org>	<48ED25E1.3010204@internap.com>	<20081008221635.GB23930@vacation.karoshi.com.>
	<20081008234933.GA83884@ussenterprise.ufp.org>
Message-ID: <48ED4879.20808@internap.com>

Leo Bicknell wrote:
> In a message written on Wed, Oct 08, 2008 at 10:16:35PM +0000, bmanning at vacation.karoshi.com wrote:
>> 	the staff recommendation was to -exclude- these from
>> 	the specific proposals dealing w/ caribbean issues on
>> 	minimum allocation sizes.
> 
> Yes, however at least one person raised the issue at the Nassau
> meeting asking if they should be included, that is, rather than
> Caribbean should the language be "ARIN Serivce Region not including
> the US and Canada."
> 
> As worded, it is Caribbean specific, and I think staff's interpretation
> matches the policy.

Do you know whether that person was concerned about a narrower staff 
interpretation?  Or were they advocating that one of the excluded islands 
be included?  (If the latter, do you know which one?)

-Scott


From BillD at cait.wustl.edu  Wed Oct  8 20:06:42 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 8 Oct 2008 19:06:42 -0500
Subject: [arin-ppml] Policy Proposal 2008-6 - Staff Assessment
References: <48ED167F.5050000@arin.net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531C7E@ex1.cait.wustl.edu>

For completeness, I believe an additional distinction worthy of comment between 2008-6 and 2008-2 is that the trigger for implementation is at the discretion of the BoT in 2008-6 rather than being immediate.

Bill Darte
ARIN AC and Author, 2008-6


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Member Services
Sent: Wed 10/8/2008 3:22 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Policy Proposal 2008-6 - Staff Assessment
 
Policy Proposal 2008-6
Title: Emergency Transfer Policy for IPv4 Addresses
Submitted: 15 August 2008
Assessment: 8 October 2008


ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I. Proposal

Policy Proposal is available below and at:
http://www.arin.net/policy/proposals/2008_6.html

II. Proposal Summary

ARIN staff understands that this policy would create a second set of
transfer requirements when implemented. A resource holder deemed
legitimate by ARIN may transfer IPv4 addresses to a recipient that
qualifies for IPv4 addresses as long as the original block isn't broken
into more than four blocks.


III. Comments

A. ARIN Staff

1. The meaning of "without the active involvement of ARIN" in the first
sentence is unclear and should be further defined by the author.

2. Section 1 indicates the transfer must be done by the "legitimate and
exclusive holder of those resources". The term "legitimate and exclusive
holder" is vague and must be clearly defined with accompanying criteria
to help staff determine who is eligible to transfer resources under this
policy.


3. Section 2 says that the recipient must have "documented operational
need in accordance with current ARIN policy". Current ARIN policies do
not allow the issuance of /23s and /24s with the exception of the
micro-allocation policy. This would indicate that no organization would
be allowed to transfer /23s and /24s under this policy unless they could
qualify under the micro-allocation policy which has very limited
eligibility.

4. This policy would become 8.4 in the NRPM and not 8.2.1 as indicated.

5. This policy proposal addresses the same subject matter as 2008-2.
They both specify requirements that Transferor and address space be
recognized by ARIN, Transferee demonstrate need and Transferee sign an
RSA. Additionally, they both include provisions on deaggregation,
minimum prefix size and directory services. They are distinguishable in
a number of other respects: for example, this policy would only be in
effect for three (3) years from its implementation, unlike 2008-2, and
it does not include specific criteria on matters such as facilitating
and establishing eligibility for the transfer. For a complete list of
differences, see comparison attached.



B. ARIN General Counsel

Counsel believes passage of an additional, more permissive transfer
policy would reduce potential legal risks and costs to ARIN arising from
transfer disputes as available IPv4 address space is depleted.
Specifically, counsel believes passage of 2008-2 or 2008-6 is better for
ARIN than continuing its current policy that is highly restrictive in
the right of parties to transfer number resources.

We now turn to more specific concerns of this particular transfer policy.

This policy is a major departure from existing ARIN policy which has
generally prohibited transfers except in specific, limited
circumstances. We therefore address the overall intent of the policy
from a legal perspective.

The first legal concern in evaluating the specifics of any transfer
policy is whether it is consistent with antitrust law. Currently, this
policy does not create concerns. By creating a white market for transfer
of v4 resources, the policy arguably advances competition. In this
regard, there is no difference between 2008-2 and 2008-6.

Second, any new policy should be consistent with the legal theory of the
Internet community that numbers are not "owned." We have no concerns
about the language of this proposal in this regard. In this regard,
there is no difference between 2008-2 and 2008-6.


No matter what transfer policy ARIN implements, it seems likely that
there will be more disputes, and hence more legal risk, once ARIN can no
longer satisfy requests for v4 resources. But if ARIN continues its
existing community created policy to prohibit most transfers, counsel
anticipates that widespread transfers in conflict with ARIN's current
policy would nonetheless occur - imposing significant future legal costs
including the costs of investigation, revocation, arbitration, and
litigation. A carefully drafted but more permissive transfer policy
would likely relieve ARIN of legal risks and cost. We therefore seek to
balance risks created by the community's adoption of the proposed policy
compared to the risks of retaining the current policy. This policy could
lead to future legal costs due to disputes arising from the lack of
specific criteria on transfer eligibility and other matters, which ARIN
staff would need to supply, and which would not have a community
consensus as a standards defense. Choosing between 2008-2 and 2008-6
should reflect the community evaluation of whether the additional issues
addressed in 2008-2 are correctly stated, or those issues are best left
to future policy development or staff interpretation. If a court were to
construe an application of 2008-6 if adopted, the court might find any
issue explicitly addressed in 2008-2 and not in 2008-6 cannot be applied
as interpretive policy.


IV. Resource Impact - Minimal

The resource impact of implementing this policy is viewed as minimal.
Barring any unforeseen resource requirements, this policy could be
implemented within 90 days from the date of the ratification of the
policy by the ARIN Board of Trustees. It will require the following:

? Updates to Guidelines will be required
? Staff training will be required

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


Policy Proposal 2008-6
Emergency Transfer Policy for IPv4 Addresses

Author: Bill Darte

Date: 26 August 2008

Proposal type: New

Policy term: Temporary

Policy statement:

8.2.1 Emergency Transfer Policy for IPv4 Addresses

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:

1. Transfer takes place from a holder of IPv4 addresses recognized by
ARIN as the legitimate and exclusive holder of those resources.

2. Transfer takes place to a recipient that has documented operational
need in accordance with current ARIN policy and that signs an RSA with
ARIN covering those resources in advance of transfer.

3. Transfer of addresses takes place in such a way that the original
contiguous block(s) are not disaggregated into more than 4 resultant
network blocks each being greater than or equal to the current minimum
sizes specified in applicable ARIN policy.

4. Transfer is complete and unrestricted and is supported by
documentation that ARIN deems satisfactory.

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.

Timetable for implementation:

This policy, once ratified by the ARIN Board of Trustees, would be
implemented when either the free-pool of IANA addresses is exhausted or
IPv4 address resources in the ARIN Region reaches a threshold of
scarcity recognized by the ARIN Board of Trustees as requiring this
policy implementation.

#######################################################

2008-6 and 2008-2 Compared


1. Issues Addressed in Both Policies:

? Transferor and address space recognized by ARIN

? Transferee demonstrates need

? Transferee signs RSA

? Deaggregation

	o 8-2: Unlimited

	o 8-6: Not more than 4 pieces (each greater than minimum prefix size)

? Minimum prefix size

	o 8-2: /24

	o 8-6: Based on current policy.

? Directory Services

	o WHOIS updated

2. Policy Guidance is included in 2008-2, but not found in 2008-6:

? Conditions on the transferor (source)

	o No outstanding balance

	o Has not received space from ARIN in preceding 12 months

	o If retains portion of space, must sign SA

? Conditions on the transferee (recipient)

	o Intent to use space in ARIN service area

	o No outstanding balance

	o Not more than a 12-month supply

	o Not more often than once per 6 months

? Safe harbor text

	o Availability for transfer does not give okay to ARIN to take it back.

? Organizations under Common Ownership or Control

	o ARIN may consider this during requests.

? Listing Service

	o Voluntary

? Directory Services

	o Log of transfers

<end>



_______________________________________________
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/20081008/34b3c238/attachment.htm>

From plzak at arin.net  Thu Oct  9 07:37:14 2008
From: plzak at arin.net (Ray Plzak)
Date: Thu, 9 Oct 2008 07:37:14 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48ED2121.4090901@internap.com>
References: <48ED15BD.9060904@arin.net> <48ED2121.4090901@internap.com>
Message-ID: <FEA070315E40A3489D38398C35FE7BB2357377025A@EDAMAME.arin.net>

None of these islands are in the Caribbean area or members of any Caribbean related organization and thus this policy would not apply to them.

Ray

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Scott Leibrand
> Sent: Wednesday, October 08, 2008 17:08
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
>
> Does staff's understanding of the geographic applicability of this
> policy
> proposal match the intent of the authors and supporters?  I'm not sure
> whether the Bouvet Islands, US Minor Outlying Islands, St Pierre and
> Miquelon, Heard and McDonald Islands and/or St Helena fit within the
> intended scope or not...
>
> -Scott
>
> Member Services wrote:
> > Policy Proposal: 2008-4
> > Title: Minimum Allocation in the Caribbean Region
> > Revised: 18 August 2008
> > Assessment: 8 October 2008
> >
> > ARIN Staff Assessment
> >
> > The assessment of this proposal includes comments from ARIN staff and
> > the ARIN General Counsel. It contains analysis of procedural, legal,
> and
> > resource concerns regarding the implementation of this policy
> proposal
> > as it is currently stated. Any changes to the language of the
> proposal
> > may necessitate further analysis by staff and Counsel.
> >
> > I. Proposal
> >
> > Policy Proposal is available below and at:
> > http://www.arin.net/policy/proposals/2008_4.html
> >
> > II. Proposal Summary
> >
> > ARIN staff understands that this policy would lower the minimum
> > allocation size to a /22 for ISPs in the Caribbean region. The ARIN
> > Caribbean service area consists of the locations listed at
> > http://www.arin.net/community/ARINcountries.html, with the exception
> of
> > the US, Canada, Antarctica, Bouvet Islands, US Minor Outlying
> Islands,
> > St Pierre and Miquelon, Heard and McDonald Islands and St Helena.
> >
> > III. Comments
> >
> > A. ARIN Staff
> >
> > 1. Staff foresees no implementation problems with this policy.
> > 2. End-users are excluded from this policy which might be viewed as
> > offering an unfair advantage to ISPs in the region.
> >
> > B. ARIN General Counsel
> >
> > Counsel sees no significant legal or litigation risk regarding this
> policy.
> >
> >
> > IV. Resource Impact - Minimal
> >
> > The resource impact of implementing this policy is viewed as minimal.
> > Barring any unforeseen resource requirements, this policy could be
> > implemented within 30 - 90 days from the date of the ratification of
> the
> > policy by the ARIN Board of Trustees. It will require the following:
> >
> > * Updates to Guidelines will be required
> > * Staff training will be required
> > * Updates to the ARIN web page of the "List of Countries in ARIN's
> > Geographical Areas" to indicate which countries are considered part
> of
> > the Caribbean region will be required.
> >
> > Regards,
> >
> > Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > #####
> >
> >
> > Policy Proposal 2008-4
> > Minimum Allocation in the Caribbean Region
> >
> > Author: Cathy Aronson and Paul Andersen
> >
> > Date: 18 August 2008
> >
> > Proposal type: new
> >
> > Policy term: renewable
> >
> > Policy statement:
> >
> > Add the following as section 4.8 of NRPM:
> >
> > 4.8. Minimum Allocation. The minimum IPv4 allocation size for ISPs
> from
> > the Caribbean portion of the ARIN region is /22.
> >
> >     4.8.1. Allocation Criteria.
> >
> >         * The requesting organization must show the efficient
> >         utilization of an entire previously allocated /22 from their
> >         upstream ISP. This allocation (/22) may have been provided
> >         by an ISP's upstream provider(s), and does not have to be
> >         contiguous address space. The organization must meet the
> >         requirement of efficient use of 4 /24s.
> >
> >         * A multi-homed organization must show the efficient
> >         utilization of an entire previously allocated /23 from their
> >         upstream ISP. This allocation (/23) may have been provided
> >         by an ISP's upstream provider(s), and does not have to be
> >         contiguous address space. The organization must meet the
> >         requirement of efficient use of 2 /24s.
> >
> >         * Utilization Reporting and Justification. All other ARIN
> >         policies regarding the reporting of justification information
> >         for the allocation of IPv4 and IPv6 address space will remain
> >         in effect.
> >
> > Rationale:
> >
> > ARIN staff have noted that organizations in the Caribbean region have
> > problems meeting the current criteria due to the fact that the
> > population in the region is smaller than that of Canada and the US.
> > There is also a lack of competition with many countries in the region
> > faced with a monopoly or duopoly situation in terms of transport
> providers.
> >
> > To spur development in the region a similar proposal was passed in
> this
> > region for the portion of the African region that ARIN administered
> > prior to the formation of AfriNIC. This proposal seeks a similar
> outcome.
> >
> > Timetable for implementation: immediate
> >
> > Revisions Made:
> >
> > * 2008-4.02 - Minor edit to specify proposed NRPM section number
> >
> >
> >
> > _______________________________________________
> > 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 farmer at umn.edu  Thu Oct  9 10:12:14 2008
From: farmer at umn.edu (David Farmer)
Date: Thu, 09 Oct 2008 09:12:14 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <FEA070315E40A3489D38398C35FE7BB2357377025A@EDAMAME.arin.net>
References: <48ED15BD.9060904@arin.net>, <48ED2121.4090901@internap.com>,
	<FEA070315E40A3489D38398C35FE7BB2357377025A@EDAMAME.arin.net>
Message-ID: <48EDCAEE.15993.2A299C1@farmer.umn.edu>

Yes, they are not part of the Caribbean, anyone with the slightest grasp of 
geography gets that thanks to Leo's interesting tidbits.

I guess the important question is, does anyone believe that the population 
and economic rationale used to justify this policy wouldn't apply equally to 
these islands just as much, if not more, than the Caribbean Region? 

These couple handfuls of islands are not going to cause am implosion of the 
route table.  Why would we want to have to come back later to add them?  
How would we explain to anyone form one of these islands why the 
Caribbean Region qualifies and they don't?  

There are probably even regions of the US and Canada that could qualify, 
the near attic for instance, but crossing that line will require a much more 
careful definition that would likely bog down an important policy.  Therefore 
let's not do that.  But, I think it is fairly easy to craft a definition that would 
include this assortment of islands without much danger of abuse. 

I support this important policy and call for the inclusion of these other 
miscellaneous islands. 

David Farmer

On 9 Oct 2008 Ray Plzak wrote:

> None of these islands are in the Caribbean area or members of any
> Caribbean related organization and thus this policy would not apply to
> them. 
> 
> Ray
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of Scott Leibrand
> > Sent: Wednesday, October 08, 2008 17:08
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
> >
> > Does staff's understanding of the geographic applicability of this
> > policy
> > proposal match the intent of the authors and supporters?  I'm not sure
> > whether the Bouvet Islands, US Minor Outlying Islands, St Pierre and
> > Miquelon, Heard and McDonald Islands and/or St Helena fit within the
> > intended scope or not...
> >
> > -Scott
> >
> > Member Services wrote:
> > > Policy Proposal: 2008-4
> > > Title: Minimum Allocation in the Caribbean Region
> > > Revised: 18 August 2008
> > > Assessment: 8 October 2008
> > >
> > > ARIN Staff Assessment
> > >
> > > The assessment of this proposal includes comments from ARIN staff and
> > > the ARIN General Counsel. It contains analysis of procedural, legal,
> > and
> > > resource concerns regarding the implementation of this policy
> > proposal
> > > as it is currently stated. Any changes to the language of the
> > proposal
> > > may necessitate further analysis by staff and Counsel.
> > >
> > > I. Proposal
> > >
> > > Policy Proposal is available below and at:
> > > http://www.arin.net/policy/proposals/2008_4.html
> > >
> > > II. Proposal Summary
> > >
> > > ARIN staff understands that this policy would lower the minimum
> > > allocation size to a /22 for ISPs in the Caribbean region. The ARIN
> > > Caribbean service area consists of the locations listed at
> > > http://www.arin.net/community/ARINcountries.html, with the exception
> > of
> > > the US, Canada, Antarctica, Bouvet Islands, US Minor Outlying
> > Islands,
> > > St Pierre and Miquelon, Heard and McDonald Islands and St Helena.
> > >
> > > III. Comments
> > >
> > > A. ARIN Staff
> > >
> > > 1. Staff foresees no implementation problems with this policy.
> > > 2. End-users are excluded from this policy which might be viewed as
> > > offering an unfair advantage to ISPs in the region.
> > >
> > > B. ARIN General Counsel
> > >
> > > Counsel sees no significant legal or litigation risk regarding this
> > policy.
> > >
> > >
> > > IV. Resource Impact - Minimal
> > >
> > > The resource impact of implementing this policy is viewed as minimal.
> > > Barring any unforeseen resource requirements, this policy could be
> > > implemented within 30 - 90 days from the date of the ratification of
> > the
> > > policy by the ARIN Board of Trustees. It will require the following:
> > >
> > > * Updates to Guidelines will be required
> > > * Staff training will be required
> > > * Updates to the ARIN web page of the "List of Countries in ARIN's
> > > Geographical Areas" to indicate which countries are considered part
> > of
> > > the Caribbean region will be required.
> > >
> > > Regards,
> > >
> > > Member Services
> > > American Registry for Internet Numbers (ARIN)
> > >
> > >
> > > #####
> > >
> > >
> > > Policy Proposal 2008-4
> > > Minimum Allocation in the Caribbean Region
> > >
> > > Author: Cathy Aronson and Paul Andersen
> > >
> > > Date: 18 August 2008
> > >
> > > Proposal type: new
> > >
> > > Policy term: renewable
> > >
> > > Policy statement:
> > >
> > > Add the following as section 4.8 of NRPM:
> > >
> > > 4.8. Minimum Allocation. The minimum IPv4 allocation size for ISPs
> > from
> > > the Caribbean portion of the ARIN region is /22.
> > >
> > >     4.8.1. Allocation Criteria.
> > >
> > >         * The requesting organization must show the efficient
> > >         utilization of an entire previously allocated /22 from their
> > >         upstream ISP. This allocation (/22) may have been provided
> > >         by an ISP's upstream provider(s), and does not have to be
> > >         contiguous address space. The organization must meet the
> > >         requirement of efficient use of 4 /24s.
> > >
> > >         * A multi-homed organization must show the efficient
> > >         utilization of an entire previously allocated /23 from their
> > >         upstream ISP. This allocation (/23) may have been provided
> > >         by an ISP's upstream provider(s), and does not have to be
> > >         contiguous address space. The organization must meet the
> > >         requirement of efficient use of 2 /24s.
> > >
> > >         * Utilization Reporting and Justification. All other ARIN
> > >         policies regarding the reporting of justification information
> > >         for the allocation of IPv4 and IPv6 address space will remain
> > >         in effect.
> > >
> > > Rationale:
> > >
> > > ARIN staff have noted that organizations in the Caribbean region have
> > > problems meeting the current criteria due to the fact that the
> > > population in the region is smaller than that of Canada and the US.
> > > There is also a lack of competition with many countries in the region
> > > faced with a monopoly or duopoly situation in terms of transport
> > providers.
> > >
> > > To spur development in the region a similar proposal was passed in
> > this
> > > region for the portion of the African region that ARIN administered
> > > prior to the formation of AfriNIC. This proposal seeks a similar
> > outcome.
> > >
> > > Timetable for implementation: immediate
> > >
> > > Revisions Made:
> > >
> > > * 2008-4.02 - Minor edit to specify proposed NRPM section number
> > >
> > >
> > >
> > > _______________________________________________
> > > 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.



=======================================================
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  Thu Oct  9 10:35:29 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 9 Oct 2008 15:35:29 +0100
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48EDCAEE.15993.2A299C1@farmer.umn.edu>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>

> I guess the important question is, does anyone believe that 
> the population and economic rationale used to justify this 
> policy wouldn't apply equally to these islands just as much, 
> if not more, than the Caribbean Region? 

> There are probably even regions of the US and Canada that 
> could qualify, the near Arctic for instance,

I suggest that the AC consider rewording this policy to refer
to "Sparsely Populated Regions" rather than the Caribbean. Also
include a clause that states:

    X.1) Sparsely Populated Regions referred to in section X
    of the policy, include the following:

      X.1.1) The countries A, B, C and D,
      X.1.2) The territories G and H

Then at some future time you could add lines like:
      
      X.1.3) Alaska outside the city and borough of Juneau
      X.1.4) Nunavut Territory
      X.1.5) Labrador Peninsula defined as Labrador Region, NF,
             and the regions Saguenay-Lac-Saint-Jean, C?te-Nord, 
             and Nord-du-Qu?bec in the province of Qu?bec
      X.1.6) Mountainous areas west of the Great Plains which
             lie more than 150 km from an incorporated city
             whose population is over 250,000 as of the 
             U.S census of 2000 or the Canadian census of 2001

Leaving aside the suggested definitions of additional territory,
I don't think that this would materially change the meaning and
effect of the policy. And being able to discuss adding a sentence
or two to an existing policy, might make things easier in the
future.

--Michael Dillon

P.S. In favor of this policy.




From bicknell at ufp.org  Thu Oct  9 11:15:10 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 9 Oct 2008 11:15:10 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48ED4879.20808@internap.com>
References: <48ED15BD.9060904@arin.net> <48ED2121.4090901@internap.com>
	<20081008212153.GA74653@ussenterprise.ufp.org>
	<48ED25E1.3010204@internap.com>
	<20081008221635.GB23930@vacation.karoshi.com.>
	<20081008234933.GA83884@ussenterprise.ufp.org>
	<48ED4879.20808@internap.com>
Message-ID: <20081009151510.GB41010@ussenterprise.ufp.org>

In a message written on Wed, Oct 08, 2008 at 04:55:37PM -0700, Scott Leibrand wrote:
> Do you know whether that person was concerned about a narrower staff 
> interpretation?  Or were they advocating that one of the excluded islands 
> be included?  (If the latter, do you know which one?)

My vague memory is that someone stood up and said something like:

   conditions in the us and canada are xyz, and the rest of the arin
   region has different conditions

To which someone (I think Ray) said something like:

   This policy applies to the Caribbean, we also have some other islands
   like....

Basically in an attempt to correct the speaker that the policy was not
"non-us non-canada" but rather Caribbean.

To which someone else added something like:

   It seems like they would have similar issues.

I don't recall anything that sounded like "advocating" to me.

The transcript is at
http://www.arin.net/meetings/minutes/carib_fall_08/csm_transcript.html#anchor_16
but I see nothing of this conversation there.  It may well have
happened in an open mike, or at the social.

Truthfully (and part of why I posed the Wikipedia links) I'm not sure
many people in the US, Canada, or the Caribbean know ARIN is providing
IPs for a small uninhabited island near antarctica, for instance.  Id
doubt many people have considered the issue at all.


-- 
       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/20081009/a16e1a4e/attachment.sig>

From mueller at syr.edu  Thu Oct  9 12:39:00 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 9 Oct 2008 12:39:00 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads><B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org><48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9023C98D9@SUEXCL-02.ad.syr.edu>


> On Oct 6, 2008, at 9:27 AM, Randy Bush wrote:
> 
> > and this is not a problem if you get the space from an rir, only if
> > you buy it on an open market.  cool!
> >
> > randy
> 
> That's right Randy. To recap from last week, what makes routing keep
> working under the current paradigm?
> 
> 1. CIDR  -- which provides the basic tools.

Which still exists if there are transfers...

> 2. Top-level aggregation -- which the RIR community-system provided,
> and kept flexible over time as technology improved and RIR community
> practices changed.

Which still exists if there are transfers...

> 3. Filtering -- which was/is only commercially feasible because of the
> top-level aggregation made possible by the RIR community-system.

Which still exists if there are transfers...

> 4. Open entry for new routing service providers, which the arms-length

Which becomes more limited due to ipv4 scarcity with or without
transfers

C'mon Tom, Randy nailed it.



From owen at delong.com  Thu Oct  9 12:44:41 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 9 Oct 2008 09:44:41 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <F24EC748-B10D-45A1-BDC7-278F6CA2B94E@delong.com>


On Oct 9, 2008, at 7:35 AM, <michael.dillon at bt.com> wrote:

>> I guess the important question is, does anyone believe that
>> the population and economic rationale used to justify this
>> policy wouldn't apply equally to these islands just as much,
>> if not more, than the Caribbean Region?
>
>> There are probably even regions of the US and Canada that
>> could qualify, the near Arctic for instance,
>
> I suggest that the AC consider rewording this policy to refer
> to "Sparsely Populated Regions" rather than the Caribbean. Also
> include a clause that states:
>
>    X.1) Sparsely Populated Regions referred to in section X
>    of the policy, include the following:
>
>      X.1.1) The countries A, B, C and D,
>      X.1.2) The territories G and H
>
> Then at some future time you could add lines like:
>
>      X.1.3) Alaska outside the city and borough of Juneau
FYI, Juneau is more sparsely populated than much of Jamaica
and I would think that including Fairbanks or Anchorage would
be about like including San Francisco while excluding the rest
of urban California.
>
>      X.1.4) Nunavut Territory

What about Yukon, Northwest Territories, and PEI which are
nearly as sparse?
>
>      X.1.5) Labrador Peninsula defined as Labrador Region, NF,
>             and the regions Saguenay-Lac-Saint-Jean, C?te-Nord,
>             and Nord-du-Qu?bec in the province of Qu?bec

The proper abbreviation for Newfoundland is NL.

>
>      X.1.6) Mountainous areas west of the Great Plains which
>             lie more than 150 km from an incorporated city
>             whose population is over 250,000 as of the
>             U.S census of 2000 or the Canadian census of 2001
>
Why not just define it as any area more than 100km from an
incorporated city or metropolitan area with a population greater
than 250,000 and eliminate ALL of the above oddities?

Owen



From owen at delong.com  Thu Oct  9 13:12:46 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 9 Oct 2008 10:12:46 -0700
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9023C98D9@SUEXCL-02.ad.syr.edu>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads><B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org><48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD9023C98D9@SUEXCL-02.ad.syr.edu>
Message-ID: <FD54C13C-94D1-4BE9-8792-85BE15D7C7E0@delong.com>


On Oct 9, 2008, at 9:39 AM, Milton L Mueller wrote:

>
>> On Oct 6, 2008, at 9:27 AM, Randy Bush wrote:
>>
>>> and this is not a problem if you get the space from an rir, only if
>>> you buy it on an open market.  cool!
>>>
>>> randy
>>
>> That's right Randy. To recap from last week, what makes routing keep
>> working under the current paradigm?
>>
>> 1. CIDR  -- which provides the basic tools.
>
> Which still exists if there are transfers...
>
But becomes SIGNIFICANTLY less effective and virtually ineffective
under the proposals being considered in APNIC and RIPE.

>> 2. Top-level aggregation -- which the RIR community-system provided,
>> and kept flexible over time as technology improved and RIR community
>> practices changed.
>
> Which still exists if there are transfers...
>
But is SIGNIFICANTLY eroded by de-aggregation created by partial  
transfers.

>> 3. Filtering -- which was/is only commercially feasible because of  
>> the
>> top-level aggregation made possible by the RIR community-system.
>
> Which still exists if there are transfers...
>
But renders many transferred addresses potentially useless.

>> 4. Open entry for new routing service providers, which the arms- 
>> length
>
> Which becomes more limited due to ipv4 scarcity with or without
> transfers
>

Yep.

Owen



From bicknell at ufp.org  Thu Oct  9 13:34:28 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 9 Oct 2008 13:34:28 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>
	<C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20081009173427.GA55511@ussenterprise.ufp.org>

In a message written on Thu, Oct 09, 2008 at 03:35:29PM +0100, michael.dillon at bt.com wrote:
> I suggest that the AC consider rewording this policy to refer
> to "Sparsely Populated Regions" rather than the Caribbean. Also
> include a clause that states:

I'm not sure "sparely populated" captures the problems in the
Caribbean.

For instance, http://en.wikipedia.org/wiki/New_Providence has a
density of 966 people per square kilometer.  Kansas,
http://en.wikipedia.org/wiki/Kansas, has a density of 12.7 people
per square kilometer.

The issue is geography.  Kansas has fiber in it, from multiple
providers.  Kansas can connect to one of 10's if not 100's of
networks in the US relatively cheaply.

http://www.columbus-networks.com/images/columbusnetworksmap.jpg

Many islands have only one cable system.  A few are fortunate enough
to have two.  As you might guess, the cost of 1000 miles of undersea
cable to get to an island is orders of magnitude more than 500 miles
of terrestrial fiber across Kansas along a railroad or gas pipeline.

Often, even where there are two systems providers use things like
the distribution of IP addresses to create competitive advantage.

So I don't believe population density has anything to do with the
problem, and I would not support taking the definition in a direction
that uses population density as a metric.

-- 
       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/20081009/38c7938d/attachment.sig>

From tvest at pch.net  Thu Oct  9 14:03:00 2008
From: tvest at pch.net (Tom Vest)
Date: Thu, 9 Oct 2008 14:03:00 -0400
Subject: [arin-ppml] 2008-6: Emergency Transfer Policy for IPv4 Addresses
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9023C98D9@SUEXCL-02.ad.syr.edu>
References: <20080929210436.GG1271@shell02.cell.sv2.tellme.com><70DE64CEFD6E9A4EB7FAF3A063141066A10B66@mail><20080929212313.GJ1271@shell02.cell.sv2.tellme.com>	<70DE64CEFD6E9A4EB7FAF3A063141066A10B67@mail>	<7663C7E01D8E094989CA62F0B0D21CD9023C979F@SUEXCL-02.ad.syr.edu>	<DE229826F48ABD4CBF754E5AA6CFC14B1AA2E88B12@WP40044.corp.ads><B81E435D-0C6F-4B1B-BECC-3D9581E10165@istaff.org><48EA125C.200@psg.com>
	<1AF19DD5-B9A8-429F-AFF4-44187119EDE6@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD9023C98D9@SUEXCL-02.ad.syr.edu>
Message-ID: <3F890556-C698-4E22-A71F-307023C05B71@pch.net>


On Oct 9, 2008, at 12:39 PM, Milton L Mueller wrote:

>
>> On Oct 6, 2008, at 9:27 AM, Randy Bush wrote:
>>
>>> and this is not a problem if you get the space from an rir, only if
>>> you buy it on an open market.  cool!
>>>
>>> randy
>>
>> That's right Randy. To recap from last week, what makes routing keep
>> working under the current paradigm?
>>
>> 1. CIDR  -- which provides the basic tools.
>
> Which still exists if there are transfers...

Hi Milton,

Perhaps you misunderstood something(s).
"Open market" means that IPv4 address resources obtained for use after  
the exhaustion of the RIR-administered reserves can come from a wide  
variety of sources. That's the *opposite* of "top-level aggregation."  
CIDR was designed to manage the task of routing system capacity  
conservation using the inputs that top-level aggregation permitted.  
CIDR does indeed still exist with or without those inputs, but without  
them it's of no further use as a check on the ever-growing demand for  
routing system capacity.

Maybe individual IPv4 dealers will attempt to optimize their future  
IPv4 sales to maximize aggregation potential -- i.e., public benefit  
-- rather than profit/private benefit, but widespread assumptions  
about the inevitability of IPv4 sales regardless of rules or policies  
doesn't exactly support that assumption. Even if they did try, and  
even succeeded, the growth trend under a single centrally administered  
"top-level aggregation" is already alarming to some operator. *That*  
was the basic gist of Randy's oft-repeated critique of the RIR system.  
Multiply that trend by a thousand, or a hundred, or maybe just a  
handful of new top-level address resource suppliers, each with strong  
incentives may often conflict with aggregation, and you can see how  
that demand trend might change a bit.

Buggy whips still exist too, but I find that my car's accelerator  
pedal works better.

>> 2. Top-level aggregation -- which the RIR community-system provided,
>> and kept flexible over time as technology improved and RIR community
>> practices changed.
>
> Which still exists if there are transfers...
>
>> 3. Filtering -- which was/is only commercially feasible because of  
>> the
>> top-level aggregation made possible by the RIR community-system.
>
> Which still exists if there are transfers...

This one you clearly misunderstood.
Sure, large service providers can filter long prefixes, but the only  
way they can do that without voluntarily losing visibility to/from  
some parts of the Internet is if all of those long prefixes are  
"covered" by  larger routing table entries -- which is what the  
combination of top-level aggregation plus CIDR makes possible. Without  
that, they can still use filtering to protect their own routing  
subsystem investments, but only at the expense of foregoing new  
customers that arrive with nothing but a small quantity of purchased  
IPv4. In addition, as more growth is accommodated by such small  
prefixes, a filtering service provider will not only miss out on new  
business, they'll probably start lose some of the existing customers,  
who would also be losing visibility to everything new that's coming  
online. On top of that, they'll also be pissing off their peers who do  
not filter, because the filterers will be indirectly degrading the  
connectivity of the non-filterers' new resource transfer recipient  
customers.

The best way to handle this will be a routing cartel of some kind, at  
least until the DOJ steps in.
After that, the best way to handle it will be somebody else's problem.

>> 4. Open entry for new routing service providers, which the arms- 
>> length
>
> Which becomes more limited due to ipv4 scarcity with or without
> transfers

More limited, asymptotically approaching absolutely impossible,  
forever -- that's the future that a self-regulating, privatized IPv4- 
based Internet promises.
I admit that it's in an improbable one, but improbable only because  
the "self-regulating" aspect will be the first to to go.

Frankly, given your long advocacy for expanding the supply of TLDs,  
I'm a little surprised that you've chosen to support artificial  
scarcity when it comes to number resources. When confronted with a  
hard choice between the means (competition, the profit motive, the  
prospect of "cornering the market" once and for all) and the  
hypothetical ends of market-based allocation regimes (e.g., relative  
abundance, the prospect of winners as well as losers being better off  
than under any other arrangement), you've made your own preferences  
abundantly clear. And so have I.

Now the community (or of you prefer, the "community") will have to  
decide.

TV


From david.kessens at nsn.com  Thu Oct  9 14:15:53 2008
From: david.kessens at nsn.com (David Kessens)
Date: Thu, 9 Oct 2008 11:15:53 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <F24EC748-B10D-45A1-BDC7-278F6CA2B94E@delong.com>
References: <C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
	<F24EC748-B10D-45A1-BDC7-278F6CA2B94E@delong.com>
Message-ID: <20081009181553.GE4140@nsn.com>


Owen,

On Thu, Oct 09, 2008 at 09:44:41AM -0700, Owen DeLong wrote:
>
> Why not just define it as any area more than 100km from an
> incorporated city or metropolitan area with a population greater
> than 250,000 and eliminate ALL of the above oddities?

What data is going to be used ? Who is going to verify this "simple"
definition ?

David Kessens
---


From owen at delong.com  Thu Oct  9 15:21:21 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 9 Oct 2008 12:21:21 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081009181553.GE4140@nsn.com>
References: <C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
	<F24EC748-B10D-45A1-BDC7-278F6CA2B94E@delong.com>
	<20081009181553.GE4140@nsn.com>
Message-ID: <4B18DD8E-4AEB-4011-B83C-5E18B6DB84CA@delong.com>


On Oct 9, 2008, at 11:15 AM, David Kessens wrote:

>
> Owen,
>
> On Thu, Oct 09, 2008 at 09:44:41AM -0700, Owen DeLong wrote:
>>
>> Why not just define it as any area more than 100km from an
>> incorporated city or metropolitan area with a population greater
>> than 250,000 and eliminate ALL of the above oddities?
>
> What data is going to be used ? Who is going to verify this "simple"
> definition ?
>
The same problem applies to Michael's much more elaborate effort
at the same statement.

As to what data would be used, I would suppose the official government
population figures for the applicable national government in question.

However, I think Leo did a better job of directly expressing what I was
attempting to express indirectly.  The problem is not population  
density,
it is geography.

The reality is that I think the policy could apply as follows:

Any nation where 70% or more of their land mass consists of islands.

Owen



From david.kessens at nsn.com  Thu Oct  9 16:41:15 2008
From: david.kessens at nsn.com (David Kessens)
Date: Thu, 9 Oct 2008 13:41:15 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <4B18DD8E-4AEB-4011-B83C-5E18B6DB84CA@delong.com>
References: <C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
	<F24EC748-B10D-45A1-BDC7-278F6CA2B94E@delong.com>
	<20081009181553.GE4140@nsn.com>
	<4B18DD8E-4AEB-4011-B83C-5E18B6DB84CA@delong.com>
Message-ID: <20081009204115.GF4140@nsn.com>


Owen,

On Thu, Oct 09, 2008 at 12:21:21PM -0700, Owen DeLong wrote:
>
> The same problem applies to Michael's much more elaborate effort
> at the same statement.

Correct. Attempts to define special areas are bound to be wrong,
complicated or unfair. That is why I don't support policies for
special geographical areas.

Let's have a minimum allocation boundary that works for everybody in
the ARIN region (or better yet all RIRs) and be done with this.

David Kessens
---


From dlw+arin at tellme.com  Thu Oct  9 16:45:57 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Thu, 9 Oct 2008 13:45:57 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081009173427.GA55511@ussenterprise.ufp.org>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>
	<C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
	<20081009173427.GA55511@ussenterprise.ufp.org>
Message-ID: <20081009204557.GQ5704@shell02.cell.sv2.tellme.com>

On Thu, Oct 09, 2008 at 01:34:28PM -0400, Leo Bicknell wrote:
> So I don't believe population density has anything to do with the
> problem, and I would not support taking the definition in a direction
> that uses population density as a metric.

I agree that population density isn't the relevant point, but I don't
think it's as simple as geography either.  If it is, what about
something like Catalina Island off of LA?  That's clearly not in scope
for this proposal.

I think the challenges in the Caribbean stem from a combination of
geographic isolation *and* separate political (and regulatory)
environments.

That said, the proposal is a bit odd geographically.  It doesn't
actually contain a definition of who is (and isn't) part of that
region.  I assume Bermuda is included, even though it is not notably
close the Caribbean.  Politically, Bermuda has much in common with St.
Pierre and Miquelon, although the populations are of different scale.
I couldn't find a definition of "Caribbean region" in a quick search of
the ARIN website either, so this proposal is a bit ambiguous.  Does an
ISP in the Florida Keys qualify under this policy?  The intent is
clearly to not allow that.

I support the intent of this policy.  I'd prefer to see a policy that
either listed the relevant countries and territories (directly or be
reference to some other document within ARIN), or simply said non-US
and non-Canada portions of the ARIN region.

-David


From sleibrand at internap.com  Thu Oct  9 16:55:14 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 09 Oct 2008 13:55:14 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081009204557.GQ5704@shell02.cell.sv2.tellme.com>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>	<C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>	<20081009173427.GA55511@ussenterprise.ufp.org>
	<20081009204557.GQ5704@shell02.cell.sv2.tellme.com>
Message-ID: <48EE6FB2.8050804@internap.com>

Didn't this whole thread start from a staff assessment of which countries 
and territories would be included?  If that definition is accurate and 
reflects what we want from the policy, then it doesn't seem that any 
further changes are necessary...

-Scott

David Williamson wrote:
> On Thu, Oct 09, 2008 at 01:34:28PM -0400, Leo Bicknell wrote:
>> So I don't believe population density has anything to do with the
>> problem, and I would not support taking the definition in a direction
>> that uses population density as a metric.
> 
> I agree that population density isn't the relevant point, but I don't
> think it's as simple as geography either.  If it is, what about
> something like Catalina Island off of LA?  That's clearly not in scope
> for this proposal.
> 
> I think the challenges in the Caribbean stem from a combination of
> geographic isolation *and* separate political (and regulatory)
> environments.
> 
> That said, the proposal is a bit odd geographically.  It doesn't
> actually contain a definition of who is (and isn't) part of that
> region.  I assume Bermuda is included, even though it is not notably
> close the Caribbean.  Politically, Bermuda has much in common with St.
> Pierre and Miquelon, although the populations are of different scale.
> I couldn't find a definition of "Caribbean region" in a quick search of
> the ARIN website either, so this proposal is a bit ambiguous.  Does an
> ISP in the Florida Keys qualify under this policy?  The intent is
> clearly to not allow that.
> 
> I support the intent of this policy.  I'd prefer to see a policy that
> either listed the relevant countries and territories (directly or be
> reference to some other document within ARIN), or simply said non-US
> and non-Canada portions of the ARIN region.
> 
> -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 bicknell at ufp.org  Thu Oct  9 17:38:45 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 9 Oct 2008 17:38:45 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48EE6FB2.8050804@internap.com>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>
	<C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
	<20081009173427.GA55511@ussenterprise.ufp.org>
	<20081009204557.GQ5704@shell02.cell.sv2.tellme.com>
	<48EE6FB2.8050804@internap.com>
Message-ID: <20081009213845.GA77092@ussenterprise.ufp.org>

In a message written on Thu, Oct 09, 2008 at 01:55:14PM -0700, Scott Leibrand wrote:
> Didn't this whole thread start from a staff assessment of which countries 
> and territories would be included?  If that definition is accurate and 
> reflects what we want from the policy, then it doesn't seem that any 
> further changes are necessary...

Given the discussion I might like to see Caribbean Region replaced
with the list of countries, since "Caribbean Region" isn't firmly
defined anywhere, but the list of countries is defined.  As long
as the list is the same as what we've already agreeed are the
Caribbean Region Countries I don't see that as a material change,
just making sure the defintion is clear in the final form.

It wouldn't change my opinion on the policy though.

-- 
       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/20081009/c916a8c9/attachment.sig>

From packetgrrl at gmail.com  Thu Oct  9 18:19:25 2008
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 9 Oct 2008 16:19:25 -0600
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48EE6FB2.8050804@internap.com>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>
	<C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>
	<20081009173427.GA55511@ussenterprise.ufp.org>
	<20081009204557.GQ5704@shell02.cell.sv2.tellme.com>
	<48EE6FB2.8050804@internap.com>
Message-ID: <c3227e9e0810091519w45996867qbb4994a5f73a6bbe@mail.gmail.com>

Scott this proposal came via the staff as a request from the folks of the
Caribbean region.  ARIN does have a definition that they're working from for
this region.  I feel fairly certain that the ARIN staff knows the ARIN
service area. I am not sure why this is such an issue.  The staff doesn't
seem to have an issue with it.  We did this exact same thing for Africa and
that seemed to work out just fine.

----Cathy

On Thu, Oct 9, 2008 at 2:55 PM, Scott Leibrand <sleibrand at internap.com>wrote:

> Didn't this whole thread start from a staff assessment of which countries
> and territories would be included?  If that definition is accurate and
> reflects what we want from the policy, then it doesn't seem that any
> further changes are necessary...
>
> -Scott
>
> David Williamson wrote:
> > On Thu, Oct 09, 2008 at 01:34:28PM -0400, Leo Bicknell wrote:
> >> So I don't believe population density has anything to do with the
> >> problem, and I would not support taking the definition in a direction
> >> that uses population density as a metric.
> >
> > I agree that population density isn't the relevant point, but I don't
> > think it's as simple as geography either.  If it is, what about
> > something like Catalina Island off of LA?  That's clearly not in scope
> > for this proposal.
> >
> > I think the challenges in the Caribbean stem from a combination of
> > geographic isolation *and* separate political (and regulatory)
> > environments.
> >
> > That said, the proposal is a bit odd geographically.  It doesn't
> > actually contain a definition of who is (and isn't) part of that
> > region.  I assume Bermuda is included, even though it is not notably
> > close the Caribbean.  Politically, Bermuda has much in common with St.
> > Pierre and Miquelon, although the populations are of different scale.
> > I couldn't find a definition of "Caribbean region" in a quick search of
> > the ARIN website either, so this proposal is a bit ambiguous.  Does an
> > ISP in the Florida Keys qualify under this policy?  The intent is
> > clearly to not allow that.
> >
> > I support the intent of this policy.  I'd prefer to see a policy that
> > either listed the relevant countries and territories (directly or be
> > reference to some other document within ARIN), or simply said non-US
> > and non-Canada portions of the ARIN region.
> >
> > -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.
> _______________________________________________
> 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/20081009/a62087f0/attachment.htm>

From farmer at umn.edu  Thu Oct  9 18:20:21 2008
From: farmer at umn.edu (David Farmer)
Date: Thu, 09 Oct 2008 17:20:21 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48EE6FB2.8050804@internap.com>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>,
	<20081009204557.GQ5704@shell02.cell.sv2.tellme.com>,
	<48EE6FB2.8050804@internap.com>
Message-ID: <48EE3D55.16597.4617C09@farmer.umn.edu>

I really liked Michael's Dillon's editorial suggestions from earlier, that I'll 
summarize, and maybe change slightly here;  

1. Find a different name for it, "Caribbean Region", at least by itself, doesn't 
work, maybe "Caribbean Region and assorted islands".

2. Add the other assorted islands that are part of the ARIN Region, probably 
Antarctica too.  Basically anything not US and Canada.  If this is justified for 
the Caribbean, it is justified for these other islands and Antarctica too.

3. Explicitly define the Countries and Territories included by official  
destinations.

I brought up that maybe even the Arctic Regions of the US and Canada 
could be included in the future, but that they should not be included now 
because of the difficulty of finding a workable definition and consensus for it.  
Honestly, please lets not even talk about including any part of the US and 
Canada for now.  I regret even mentioning the idea earlier, even if it was to 
only to say not to do it as it would bog things down.

So back to what to call this thing;  I'm really not sure what the term is we are 
talking about here, but it includes factors of Remoteness, Sparsity of 
Population, and Sparsity of Infrastructure. It is really the product of the all 
these factors.  It is one of those things where I think you know it when you 
see it, but you really can't explain it.  I haven't found a name for it, but maybe 
you could call it an Internet Desert, just a thought, but it doesn't work for the 
title of this policy.

As I said earlier, I support this important policy and call for the inclusion of 
these other miscellaneous islands, and including them isn't really a material 
change to the concept here.

David Farmer

On 9 Oct 2008 Scott Leibrand wrote:

> Didn't this whole thread start from a staff assessment of which countries 
> and territories would be included?  If that definition is accurate and 
> reflects what we want from the policy, then it doesn't seem that any 
> further changes are necessary...
> 
> -Scott
> 
> David Williamson wrote:
> > On Thu, Oct 09, 2008 at 01:34:28PM -0400, Leo Bicknell wrote:
> >> So I don't believe population density has anything to do with the
> >> problem, and I would not support taking the definition in a direction
> >> that uses population density as a metric.
> > 
> > I agree that population density isn't the relevant point, but I don't
> > think it's as simple as geography either.  If it is, what about
> > something like Catalina Island off of LA?  That's clearly not in scope
> > for this proposal.
> > 
> > I think the challenges in the Caribbean stem from a combination of
> > geographic isolation *and* separate political (and regulatory)
> > environments.
> > 
> > That said, the proposal is a bit odd geographically.  It doesn't
> > actually contain a definition of who is (and isn't) part of that
> > region.  I assume Bermuda is included, even though it is not notably
> > close the Caribbean.  Politically, Bermuda has much in common with St.
> > Pierre and Miquelon, although the populations are of different scale.
> > I couldn't find a definition of "Caribbean region" in a quick search of
> > the ARIN website either, so this proposal is a bit ambiguous.  Does an
> > ISP in the Florida Keys qualify under this policy?  The intent is
> > clearly to not allow that.
> > 
> > I support the intent of this policy.  I'd prefer to see a policy that
> > either listed the relevant countries and territories (directly or be
> > reference to some other document within ARIN), or simply said non-US
> > and non-Canada portions of the ARIN region.
> > 
> > -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.
> _______________________________________________
> 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 mksmith at adhost.com  Thu Oct  9 18:25:03 2008
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Thu, 9 Oct 2008 15:25:03 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48EE3D55.16597.4617C09@farmer.umn.edu>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>,
	<20081009204557.GQ5704@shell02.cell.sv2.tellme.com>,
	<48EE6FB2.8050804@internap.com> <48EE3D55.16597.4617C09@farmer.umn.edu>
Message-ID: <17838240D9A5544AAA5FF95F8D52031604BE32F4@ad-exh01.adhost.lan>

> 
> I really liked Michael's Dillon's editorial suggestions from earlier, that
> I'll
> summarize, and maybe change slightly here;
> 
> 1. Find a different name for it, "Caribbean Region", at least by itself,
> doesn't
> work, maybe "Caribbean Region and assorted islands".
> 
> 2. Add the other assorted islands that are part of the ARIN Region, probably
> Antarctica too.  Basically anything not US and Canada.  If this is justified
> for
> the Caribbean, it is justified for these other islands and Antarctica too.
> 
How about rolling up (1) and (2) into "territories in the ARIN region not specifically part of the Continental United States and Canada?

> 
> So back to what to call this thing;  I'm really not sure what the term is we
> are
> talking about here, but it includes factors of Remoteness, Sparsity of
> Population, and Sparsity of Infrastructure. It is really the product of the
> all
> these factors.  It is one of those things where I think you know it when you
> see it, but you really can't explain it.  I haven't found a name for it, but
> maybe
> you could call it an Internet Desert, just a thought, but it doesn't work for
> the
> title of this policy.
> 

Non-continental ARIN participants?

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/20081009/4c0775ca/attachment.sig>

From farmer at umn.edu  Thu Oct  9 18:32:39 2008
From: farmer at umn.edu (David Farmer)
Date: Thu, 09 Oct 2008 17:32:39 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081009204115.GF4140@nsn.com>
References: <C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>,
	<4B18DD8E-4AEB-4011-B83C-5E18B6DB84CA@delong.com>,
	<20081009204115.GF4140@nsn.com>
Message-ID: <48EE4037.30792.46CBDA0@farmer.umn.edu>

On 9 Oct 2008 David Kessens wrote:

> Owen,
> 
> On Thu, Oct 09, 2008 at 12:21:21PM -0700, Owen DeLong wrote:
> >
> > The same problem applies to Michael's much more elaborate effort
> > at the same statement.
> 
> Correct. Attempts to define special areas are bound to be wrong,
> complicated or unfair. That is why I don't support policies for
> special geographical areas.

I disagree, I believe we can define region, I don't think we can define one 
that includes any part of the US or Canada at this time, that is where things 
get hard.

> Let's have a minimum allocation boundary that works for everybody in
> the ARIN region (or better yet all RIRs) and be done with this.

This is like saying that there should be one and only one global set of Zoning 
laws.  And, I don't believe in a one size fits all world.    

(And, anyone who says that by referring to Zoning laws, that I'm trying to say 
that IP addresses are property, POX on you.  I just could come up with a 
better analogy at this moment.) 

> David Kessens
> ---
> _______________________________________________
> 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 owen at delong.com  Thu Oct  9 19:34:01 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 9 Oct 2008 16:34:01 -0700
Subject: [arin-ppml] Revised Policy Proposal 2007-14
Message-ID: <E6BA7842-FF32-4DD7-8537-3238D828636B@delong.com>

Some last minute changes to address concerns raised by staff and legal.

These changes do not change the intent of the policy.


Changes include:
	Paragraph 3 replaced with language proposed by staff
	Paragraph 8 replaced with language proposed by counsel

I apologize for the last minute nature of these changes, however,
the staff, counsel, and the authors have been working diligently
over the last several days to address these issues as a result of
the information in the recent staff/legal assessments posted to the
list.

Thanks,

Owen

Policy statement:

Add the following to the NRPM:

Resource Review

1. ARIN may review the current usage of any resources issued by ARIN  
to an organization. The organization shall furnish whatever records  
are necessary to perform this review.

2. ARIN may conduct such reviews:

a. when any new resource is requested,
b. whenever ARIN has cause to believe that the resources had  
originally been obtained fraudulently, or
c. at any other time without cause unless a prior review has been  
completed in the preceding 24 months.

3. At the conclusion of a review in which ARIN has solicited  
information from the resource holder,  ARIN shall communicate to the  
resource holder that the review has been concluded and what, if any,  
further actions are required of said resource holder.

4. Organizations shown to be substantially out of compliance with  
current ARIN policy shall return resources as needed to bring them  
into (or reasonably close to) compliance.

4a. The extent to which an organization may remain out of compliance  
shall be based on the best judgment of the ARIN staff and shall  
balance the organizations utilization rate, available address pool,  
and other factors as appropriate so as to avoid forcing returns which  
will result in near-term additional requests or unnecessary route de- 
aggregation.

4b. To the extent possible, entire blocks should be returned. Partial  
address blocks shall be returned in such a way that the portion  
retained will comprise a single aggregate block.

5. If the organization does not voluntarily return resources as  
required, ARIN may revoke any resources issued by ARIN as required to  
bring the organization into overall compliance. ARIN shall follow the  
same guidelines for revocation that are required for voluntary return  
in the previous paragraph.

6. Except in cases of fraud, an organization shall be given a minimum  
of six months to effect a return. ARIN shall negotiate a longer term  
with the organization if ARIN believes the organization is working in  
good faith to substantially restore compliance and has a valid need  
for additional time to renumber out of the affected blocks.

7. ARIN shall continue to maintain the resource(s) while their return  
or revocation is pending, except no new maintenance fees shall be  
assessed for the resource(s).

8. This policy does not create any additional authority for ARIN to  
revoke legacy address space. However, the utilization of legacy  
resources shall be considered during a review to assess overall  
compliance.

9. In considering compliance with policies which allow a timeframe  
(such as a requirement to assign some number of prefixes within 5  
years) failure to comply cannot be measured until after the timeframe  
specified in the applicable policy has elapsed. Blocks subject to such  
a policy shall be assumed in compliance with that policy until such  
time as the specified time since issuance has elapsed.



Delete NRPM sections 4.1.2, 4.1.3, 4.1.4

Remove the sentence "In extreme cases, existing allocations may be  
affected." from NRPM section 4.2.3.1.

Rationale:

ARIN feels that current policy does not give them the power to review  
or reclaim resources except in cases of fraud, despite this being  
mentioned in the Registration Services Agreement. This policy proposal  
provides clear policy authority to do so, guidelines for how and under  
what conditions it shall be done, and a guarantee of a (minimum) six- 
month grace period so that the current user shall have time to  
renumber out of any resources to be reclaimed.

The nature of the "review" is to be of the same form as is currently  
done when an organization requests new resources, i.e. the  
documentation required and standards should be the same.

The intent of paragraph 2c is to prevent ARIN from doing more than one  
without-cause review in a 24 month period.

The renumbering period does not affect any "hold" period that ARIN may  
apply after return or revocation of resources is complete.

The deleted sections/text would be redundant with the adoption of this  
proposal.

Timetable for implementation: Immediate





From bonomi at mail.r-bonomi.com  Thu Oct  9 20:34:03 2008
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Thu, 9 Oct 2008 19:34:03 -0500 (CDT)
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
Message-ID: <200810100034.m9A0Y37w002433@mail.r-bonomi.com>


> Date: Thu, 9 Oct 2008 15:25:03 -0700
> From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
> Subject: Re: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
>
> > 
> > I really liked Michael's Dillon's editorial suggestions from earlier, that
> > I'll
> > summarize, and maybe change slightly here;
> > 
> > 1. Find a different name for it, "Caribbean Region", at least by itself,
> > doesn't
> > work, maybe "Caribbean Region and assorted islands".
> > 
> > 2. Add the other assorted islands that are part of the ARIN Region, proba
> bly
> > Antarctica too.  Basically anything not US and Canada.  If this is justif
> ied
> > for
> > the Caribbean, it is justified for these other islands and Antarctica too.
> > 
> How about rolling up (1) and (2) into "territories in the ARIN region not s
> pecifically part of the Continental United States and Canada?
>
> > 
> > So back to what to call this thing;  I'm really not sure what the term is
>  we
> > are
> > talking about here, but it includes factors of Remoteness, Sparsity of
> > Population, and Sparsity of Infrastructure. It is really the product of t
> he
> > all
> > these factors.  It is one of those things where I think you know it when 
> you
> > see it, but you really can't explain it.  I haven't found a name for it, 
> but
> > maybe
> > you could call it an Internet Desert, just a thought, but it doesn't work
>  for
> > the
> > title of this policy.
> > 
>
> Non-continental ARIN participants?
>

Doesn't _that_ include somebody in ....
  Hawaii, 
  Prince Edward Island, 
  Nova Scotia, 
  Catalina Island,
  Chincoteague Island, 
  Florida Keys, 
  Puerto Rico, 
  U.S. virgin Islands,
  Governor's Island,
  etc.

<*evil* grin>


There are only four viable ways to make a policy like this:
  1) explicitly list all the geopolitical divisions that are to be covered 
     by the policy
  2) explicitly list all the geopolitical divisions that are *NOT* to be 
     covered by the policy
  3) provide a sufficiently precise/detailed 'rule' to identify the desired
     areas of coverage.
  4) give staff "discretion' to make exceptions "as they deem appropriate".


I favor "codification" (i.e. 'in the NPRM') of the 4th option -- with some
language describing the 'intent' of the policy, for non-binding guidance.





From mksmith at adhost.com  Thu Oct  9 21:27:40 2008
From: mksmith at adhost.com (Michael K. Smith)
Date: Thu, 09 Oct 2008 18:27:40 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <200810100034.m9A0Y37w002433@mail.r-bonomi.com>
Message-ID: <C513FD9C.1CE12%mksmith@adhost.com>


>> 
>> Non-continental ARIN participants?
>> 
> 
> Doesn't _that_ include somebody in ....
>   Hawaii, 
>   Prince Edward Island,
>   Nova Scotia, 
>   Catalina Island,
>   Chincoteague Island,
>   Florida Keys, 
>   Puerto Rico, 
>   U.S. virgin Islands,
>   Governor's Island,
>   etc.
> 
> <*evil* grin>
> 
Foiled again, but you could actually make an argument for the Keys.  :)

> 
> There are only four viable ways to make a policy like this:
>   1) explicitly list all the geopolitical divisions that are to be covered
>      by the policy
>   2) explicitly list all the geopolitical divisions that are *NOT* to be
>      covered by the policy
>   3) provide a sufficiently precise/detailed 'rule' to identify the desired
>      areas of coverage.
>   4) give staff "discretion' to make exceptions "as they deem appropriate".
> 
> 
> I favor "codification" (i.e. 'in the NPRM') of the 4th option -- with some
> language describing the 'intent' of the policy, for non-binding guidance.

Can a visual representation suffice? (seriously, I don't know what the legal
ramifications are).  So, if you are in a "blue" region as shown on a map,
you qualify.  If you're in the red, you don't.

Mike



From packetgrrl at gmail.com  Thu Oct  9 21:35:46 2008
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 9 Oct 2008 19:35:46 -0600
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48EE3D55.16597.4617C09@farmer.umn.edu>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>
	<20081009204557.GQ5704@shell02.cell.sv2.tellme.com>
	<48EE6FB2.8050804@internap.com>
	<48EE3D55.16597.4617C09@farmer.umn.edu>
Message-ID: <c3227e9e0810091835r7c8c9321qab25888e36177836@mail.gmail.com>

David,

Although I get what you're saying currently the Arctic Regions aren't asking
for a change in ARIN policy.   This proposal was asked for by a specific
subset of our community and it was written in an effort to serve the needs
of that community.    I personally feel that the ARIN staff has defined that
region in their response to this proposal.  I am not wedded to its name and
if we want to call this policy something else that's fine.  I object to
making it a kitchen sink proposal (which will definitely delay this proposal
from approval) that includes segments of the community that didn't ask for
and don't necessarily need this policy.

----Cathy

On Thu, Oct 9, 2008 at 4:20 PM, David Farmer <farmer at umn.edu> wrote:

> I really liked Michael's Dillon's editorial suggestions from earlier, that
> I'll
> summarize, and maybe change slightly here;
>
> 1. Find a different name for it, "Caribbean Region", at least by itself,
> doesn't
> work, maybe "Caribbean Region and assorted islands".
>
> 2. Add the other assorted islands that are part of the ARIN Region,
> probably
> Antarctica too.  Basically anything not US and Canada.  If this is
> justified for
> the Caribbean, it is justified for these other islands and Antarctica too.
>
> 3. Explicitly define the Countries and Territories included by official
> destinations.
>
> I brought up that maybe even the Arctic Regions of the US and Canada
> could be included in the future, but that they should not be included now
> because of the difficulty of finding a workable definition and consensus
> for it.
> Honestly, please lets not even talk about including any part of the US and
> Canada for now.  I regret even mentioning the idea earlier, even if it was
> to
> only to say not to do it as it would bog things down.
>
> So back to what to call this thing;  I'm really not sure what the term is
> we are
> talking about here, but it includes factors of Remoteness, Sparsity of
> Population, and Sparsity of Infrastructure. It is really the product of the
> all
> these factors.  It is one of those things where I think you know it when
> you
> see it, but you really can't explain it.  I haven't found a name for it,
> but maybe
> you could call it an Internet Desert, just a thought, but it doesn't work
> for the
> title of this policy.
>
> As I said earlier, I support this important policy and call for the
> inclusion of
> these other miscellaneous islands, and including them isn't really a
> material
> change to the concept here.
>
> David Farmer
>
> On 9 Oct 2008 Scott Leibrand wrote:
>
> > Didn't this whole thread start from a staff assessment of which countries
> > and territories would be included?  If that definition is accurate and
> > reflects what we want from the policy, then it doesn't seem that any
> > further changes are necessary...
> >
> > -Scott
> >
> > David Williamson wrote:
> > > On Thu, Oct 09, 2008 at 01:34:28PM -0400, Leo Bicknell wrote:
> > >> So I don't believe population density has anything to do with the
> > >> problem, and I would not support taking the definition in a direction
> > >> that uses population density as a metric.
> > >
> > > I agree that population density isn't the relevant point, but I don't
> > > think it's as simple as geography either.  If it is, what about
> > > something like Catalina Island off of LA?  That's clearly not in scope
> > > for this proposal.
> > >
> > > I think the challenges in the Caribbean stem from a combination of
> > > geographic isolation *and* separate political (and regulatory)
> > > environments.
> > >
> > > That said, the proposal is a bit odd geographically.  It doesn't
> > > actually contain a definition of who is (and isn't) part of that
> > > region.  I assume Bermuda is included, even though it is not notably
> > > close the Caribbean.  Politically, Bermuda has much in common with St.
> > > Pierre and Miquelon, although the populations are of different scale.
> > > I couldn't find a definition of "Caribbean region" in a quick search of
> > > the ARIN website either, so this proposal is a bit ambiguous.  Does an
> > > ISP in the Florida Keys qualify under this policy?  The intent is
> > > clearly to not allow that.
> > >
> > > I support the intent of this policy.  I'd prefer to see a policy that
> > > either listed the relevant countries and territories (directly or be
> > > reference to some other document within ARIN), or simply said non-US
> > > and non-Canada portions of the ARIN region.
> > >
> > > -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.
> > _______________________________________________
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081009/208dff4d/attachment.htm>

From bicknell at ufp.org  Thu Oct  9 21:48:55 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 9 Oct 2008 21:48:55 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48ED15BD.9060904@arin.net>
References: <48ED15BD.9060904@arin.net>
Message-ID: <20081010014855.GA91405@ussenterprise.ufp.org>

In a message written on Wed, Oct 08, 2008 at 04:19:09PM -0400, Member Services wrote:
> II. Proposal Summary
> 
> ARIN staff understands that this policy would lower the minimum
> allocation size to a /22 for ISPs in the Caribbean region. The ARIN
> Caribbean service area consists of the locations listed at
> http://www.arin.net/community/ARINcountries.html, with the exception of
> the US, Canada, Antarctica, Bouvet Islands, US Minor Outlying Islands,
> St Pierre and Miquelon, Heard and McDonald Islands and St Helena.
[snip]
> 4.8. Minimum Allocation. The minimum IPv4 allocation size for ISPs from
> the Caribbean portion of the ARIN region is /22.

My proposed revised text (I am not the author):

   4.8 Minimum Allocation.  The minimum IPv4 allocation size for ISPs from
   the following countries ("the Caribbean Region") is /22:
   
   ANGUILLA
   ANTIGUA AND BARBUDA
   BAHAMAS
   BARBADOS
   BERMUDA
   CAYMAN ISLANDS
   DOMINICA
   GRENADA
   GUADELOUPE
   JAMAICA
   MARTINIQUE
   MONTSERRAT
   PUERTO RICO
   SAINT BARTHELEMY
   SAINT KITTS AND NEVIS
   SAINT LUCIA
   SAINT VINCENT AND THE GRENADINES
   ST. MARTIN
   TURKS AND CAICOS ISLANDS
   VIRGIN ISLANDS (BRITISH AND U.S.)

Note they are only all caps because that's how they cut and paste
from the ARIN web site.

I believe that 100% matches the staff assment, doesn't change the
intent of the proposal at all, and removes any possible confusion
about what may, or may not be in "The Caribbean 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/20081009/50415da5/attachment.sig>

From packetgrrl at gmail.com  Thu Oct  9 21:51:04 2008
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 9 Oct 2008 19:51:04 -0600
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081010014855.GA91405@ussenterprise.ufp.org>
References: <48ED15BD.9060904@arin.net>
	<20081010014855.GA91405@ussenterprise.ufp.org>
Message-ID: <c3227e9e0810091851p3c21e357k8a9257e3506a7f98@mail.gmail.com>

That's fine with me.  I don't see why we can't still refer to the proposal
being for the Caribbean region and then list these.

If the Arctic Region wants to be added we can do that at a later date.

----Cathy

On Thu, Oct 9, 2008 at 7:48 PM, Leo Bicknell <bicknell at ufp.org> wrote:

> In a message written on Wed, Oct 08, 2008 at 04:19:09PM -0400, Member
> Services wrote:
> > II. Proposal Summary
> >
> > ARIN staff understands that this policy would lower the minimum
> > allocation size to a /22 for ISPs in the Caribbean region. The ARIN
> > Caribbean service area consists of the locations listed at
> > http://www.arin.net/community/ARINcountries.html, with the exception of
> > the US, Canada, Antarctica, Bouvet Islands, US Minor Outlying Islands,
> > St Pierre and Miquelon, Heard and McDonald Islands and St Helena.
> [snip]
>
> > the Caribbean portion of the ARIN region is /22.
>
> My proposed revised text (I am not the author):
>
>   4.8 Minimum Allocation.  The minimum IPv4 allocation size for ISPs from
>    the following countries ("the Caribbean Region") is /22:
>
>   ANGUILLA
>   ANTIGUA AND BARBUDA
>   BAHAMAS
>   BARBADOS
>   BERMUDA
>   CAYMAN ISLANDS
>   DOMINICA
>   GRENADA
>   GUADELOUPE
>   JAMAICA
>   MARTINIQUE
>   MONTSERRAT
>   PUERTO RICO
>   SAINT BARTHELEMY
>   SAINT KITTS AND NEVIS
>   SAINT LUCIA
>   SAINT VINCENT AND THE GRENADINES
>   ST. MARTIN
>   TURKS AND CAICOS ISLANDS
>   VIRGIN ISLANDS (BRITISH AND U.S.)
>
> Note they are only all caps because that's how they cut and paste
> from the ARIN web site.
>
> I believe that 100% matches the staff assment, doesn't change the
> intent of the proposal at all, and removes any possible confusion
> about what may, or may not be in "The Caribbean Region".
>
> --
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/<http://www.ufp.org/%7Ebicknell/>
>
> _______________________________________________
> 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/20081009/075bc537/attachment.htm>

From dlw+arin at tellme.com  Thu Oct  9 23:34:26 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Thu, 9 Oct 2008 20:34:26 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081010014855.GA91405@ussenterprise.ufp.org>
References: <48ED15BD.9060904@arin.net>
	<20081010014855.GA91405@ussenterprise.ufp.org>
Message-ID: <20081010033426.GT5704@shell02.cell.sv2.tellme.com>

On Thu, Oct 09, 2008 at 09:48:55PM -0400, Leo Bicknell wrote:
> My proposed revised text (I am not the author):
>
>[...]
> 
> I believe that 100% matches the staff assment, doesn't change the
> intent of the proposal at all, and removes any possible confusion
> about what may, or may not be in "The Caribbean Region".

I'd support that.  There's certainly no harm in being explicit.

-David


From david.kessens at nsn.com  Thu Oct  9 23:53:29 2008
From: david.kessens at nsn.com (David Kessens)
Date: Thu, 9 Oct 2008 20:53:29 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48EE4037.30792.46CBDA0@farmer.umn.edu>
References: <20081009204115.GF4140@nsn.com>
	<48EE4037.30792.46CBDA0@farmer.umn.edu>
Message-ID: <20081010035329.GA31463@nsn.com>


David,

On Thu, Oct 09, 2008 at 05:32:39PM -0500, David Farmer wrote:
>
> On 9 Oct 2008 David Kessens wrote:
> 
> > Let's have a minimum allocation boundary that works for everybody in
> > the ARIN region (or better yet all RIRs) and be done with this.
> 
> This is like saying that there should be one and only one global set
> of Zoning laws. And, I don't believe in a one size fits all world.

Good policies are as simple as possible. You don't give any argument
why a smaller uniform allocation size would not work for the whole
ARIN region.

It would be great if the ARIN staff could research for us what they
expect what the impact would be on the routing table when changing the
minimum allocation size for everybody. In fact, this might make even
more sense in the context of the soon to be expected exhaustion of
IPv4 address space.

David Kessens
---


From bmanning at vacation.karoshi.com  Thu Oct  9 23:59:24 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 10 Oct 2008 03:59:24 +0000
Subject: [arin-ppml] Policy Proposal 2008-4 - a consensus opinion?
In-Reply-To: <48EE4037.30792.46CBDA0@farmer.umn.edu>
References: <20081009204115.GF4140@nsn.com>
	<48EE4037.30792.46CBDA0@farmer.umn.edu>
Message-ID: <20081010035924.GA3266@vacation.karoshi.com.>

On Thu, Oct 09, 2008 at 05:32:39PM -0500, David Farmer wrote:
> > Let's have a minimum allocation boundary that works for everybody in
> > the ARIN region (or better yet all RIRs) and be done with this.
> 
> This is like saying that there should be one and only one global set of Zoning 
> laws.  And, I don't believe in a one size fits all world.    
> 

	well, not to toss cold H2O on the fire, but routing is either
	bilateral or global in scope... if one takes the view that 
	minalloc size affects global routing, then one-size does fit
	the whole world...

	that said, perhaps it is time to re-animate -MICRO-ALLOCATION GRRL- (tm)
	and argue that the correct minium allocation for now should be
	a /32, regardless of address family.  

	Cathy, are you up for it?

--bill


From farmer at umn.edu  Fri Oct 10 01:08:37 2008
From: farmer at umn.edu (David Farmer)
Date: Fri, 10 Oct 2008 00:08:37 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - a consensus opinion?
In-Reply-To: <20081010035924.GA3266@vacation.karoshi.com.>
References: <20081009204115.GF4140@nsn.com>,
	<48EE4037.30792.46CBDA0@farmer.umn.edu>,
	<20081010035924.GA3266@vacation.karoshi.com.>
Message-ID: <48EE9D05.20909.5D744C1@farmer.umn.edu>

On 10 Oct 2008 bmanning at vacation.karoshi.com wrote:

> On Thu, Oct 09, 2008 at 05:32:39PM -0500, David Farmer wrote:
> > > Let's have a minimum allocation boundary that works for everybody in
> > > the ARIN region (or better yet all RIRs) and be done with this.
> > 
> > This is like saying that there should be one and only one global set of Zoning 
> > laws.  And, I don't believe in a one size fits all world.    
> > 
> 
> 	well, not to toss cold H2O on the fire, but routing is either
> 	bilateral or global in scope... if one takes the view that 
> 	minalloc size affects global routing, then one-size does fit
> 	the whole world...

Bill if you say so, then the magic number is /29, see the following looking at 
193/8 and 194/7;

https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html

I've been digging in and looking at stuff, I didn't realize any RIR were or did 
allocate /29s.

> 	that said, perhaps it is time to re-animate -MICRO-ALLOCATION GRRL- (tm)
> 	and argue that the correct minium allocation for now should be
> 	a /32, regardless of address family.  
> 
> 	Cathy, are you up for it?
> 
> --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  Fri Oct 10 03:54:44 2008
From: farmer at umn.edu (David Farmer)
Date: Fri, 10 Oct 2008 02:54:44 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <c3227e9e0810091835r7c8c9321qab25888e36177836@mail.gmail.com>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>,
	<48EE3D55.16597.4617C09@farmer.umn.edu>,
	<c3227e9e0810091835r7c8c9321qab25888e36177836@mail.gmail.com>
Message-ID: <48EEC3F4.8308.66F5837@farmer.umn.edu>

On 9 Oct 2008 cja at daydream.com wrote:

> David,
> 
> Although I get what you're saying currently the Arctic Regions aren't asking
> for a change in ARIN policy.   This proposal was asked for by a specific
> subset of our community and it was written in an effort to serve the needs
> of that community.    I personally feel that the ARIN staff has defined that
> region in their response to this proposal.  I am not wedded to its name and
> if we want to call this policy something else that's fine.  I object to
> making it a kitchen sink proposal (which will definitely delay this proposal
> from approval) that includes segments of the community that didn't ask for
> and don't necessarily need this policy.
>
> ----Cathy

I here you saying that this should only apply to the "Caribbean Region" 
because they are the ones that asked for it. 

However, the rational states that; "ARIN staff have noted that organizations 
in the Caribbean region have problems...",  This make it sound like this was 
initiated by ARIN noticing problems.  If this is the case then I'm asking why 
the issue is only limited to the Caribbean region.  If ARIN is going to initiate a 
change then why shouldn't it be more broadly defined.  

If it is truly the case that you state above "this proposal was asked for by a 
specific subset of our community (the Caribbean region)" then the rational 
should say that, and not start out with "ARIN staff have noted that 
organizations in the Caribbean region have problems..."  

I believe the currently stated rationale equally applies to "Antarctica, Bouvet 
Islands, US Minor Outlying Islands, St Pierre and Miquelon, Heard and 
McDonald Islands and St Helena" and If this is an ARIN initiate change it 
should include these too.  If you don't believe the rational equally applies to 
these, then help me understand why?  Or, if this was truly initiated by the 
Caribbean region, provide a more accurate Rationale.

As I have said, I think this is an important policy, and call for the inclusion of
these 7other countries within the ARIN Region to the 21 countries you are 
saying make up the Caribbean region.


=======================================================
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  Fri Oct 10 04:00:40 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 10 Oct 2008 09:00:40 +0100
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <F24EC748-B10D-45A1-BDC7-278F6CA2B94E@delong.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC0892095F@E03MVZ2-UKDY.domain1.systemhost.net>


> The proper abbreviation for Newfoundland is NL.

Yeah, they changed it while I was away.

> Why not just define it as any area more than 100km from an 
> incorporated city or metropolitan area with a population 
> greater than 250,000 and eliminate ALL of the above oddities?

Owen, you are missing the point. All the items that
you critiqued are merely examples of the kind of thing
that could be suggested and argued at some future
point in time.

For now, in the current policy, I am only suggesting a bit
of restructuring so that the policy applies to a list of
defined regions, even if that list currently only has
one item in it. I am not suggesting any change to the
substance of the policy, just the structure.

--Michael Dillon


From michael.dillon at bt.com  Fri Oct 10 04:05:38 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 10 Oct 2008 09:05:38 +0100
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081009173427.GA55511@ussenterprise.ufp.org>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08920974@E03MVZ2-UKDY.domain1.systemhost.net>

> So I don't believe population density has anything to do with 
> the problem, and I would not support taking the definition in 
> a direction that uses population density as a metric.

Then change the term that I suggested. Perhaps it should be
"Specified Regions", or "Supported Regions" or "Special Regions"
or "Special Support Regions" or "Exempted Regions" or "Listed
Regions".

The point is that when you create one special case, it is only
a matter of time before another one comes along. Let's not make
the policy text too specific.

--Michael Dillon


From BillD at cait.wustl.edu  Fri Oct 10 08:51:57 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 10 Oct 2008 07:51:57 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48EEC3F4.8308.66F5837@farmer.umn.edu>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>,
	<48EE3D55.16597.4617C09@farmer.umn.edu>,
	<c3227e9e0810091835r7c8c9321qab25888e36177836@mail.gmail.com>
	<48EEC3F4.8308.66F5837@farmer.umn.edu>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030877ADF0D@ex1.cait.wustl.edu>

David,

ARIN did not initiate the proposed change for the Caribbean sector.

My first experience with issues surrounding this proposal was in a
pre-sector meeting in St. Thomas February of '07.

There, many representatives of the Caribbean community voiced a variety
of concerns related to limited infrastructure, lack of competition  due
to powerful and protected imcumbency, etc.  They learned much about ARIN
and learned more during the whole region meeting in Puerto Rico the
following Spring at ARIN XIX. 

Cathy and Paul may correct me, but I believe the impetus for the actual
writing of the proposal came during Open Policy Hour at ARIN XXI in
Denver.  There, Bernadette Lewis, Secretary General of the Caribbean
Telecommunications Union spoke about the need for change and support
with addressing policy.

Cathy and Paul responded by crafting a draft proposal very shortly
thereafter.

Bill Darte
ARIN AC

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
> Sent: Friday, October 10, 2008 2:55 AM
> To: cja at daydream.com; cja at daydream.com
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
> 
> On 9 Oct 2008 cja at daydream.com wrote:
> 
> > David,
> > 
> > Although I get what you're saying currently the Arctic 
> Regions aren't asking
> > for a change in ARIN policy.   This proposal was asked for 
> by a specific
> > subset of our community and it was written in an effort to 
> serve the needs
> > of that community.    I personally feel that the ARIN staff 
> has defined that
> > region in their response to this proposal.  I am not wedded to its 
> > name and if we want to call this policy something else 
> that's fine.  I 
> > object to making it a kitchen sink proposal (which will definitely 
> > delay this proposal from approval) that includes segments of the 
> > community that didn't ask for and don't necessarily need 
> this policy.
> >
> > ----Cathy
> 
> I here you saying that this should only apply to the 
> "Caribbean Region" 
> because they are the ones that asked for it. 
> 
> However, the rational states that; "ARIN staff have noted 
> that organizations in the Caribbean region have problems...", 
>  This make it sound like this was initiated by ARIN noticing 
> problems.  If this is the case then I'm asking why the issue 
> is only limited to the Caribbean region.  If ARIN is going to 
> initiate a change then why shouldn't it be more broadly defined.  
> 
> If it is truly the case that you state above "this proposal 
> was asked for by a specific subset of our community (the 
> Caribbean region)" then the rational should say that, and not 
> start out with "ARIN staff have noted that organizations in 
> the Caribbean region have problems..."  
> 
> I believe the currently stated rationale equally applies to 
> "Antarctica, Bouvet Islands, US Minor Outlying Islands, St 
> Pierre and Miquelon, Heard and McDonald Islands and St 
> Helena" and If this is an ARIN initiate change it should 
> include these too.  If you don't believe the rational equally 
> applies to these, then help me understand why?  Or, if this 
> was truly initiated by the Caribbean region, provide a more 
> accurate Rationale.
> 
> As I have said, I think this is an important policy, and call 
> for the inclusion of these 7other countries within the ARIN 
> Region to the 21 countries you are saying make up the 
> Caribbean region.
> 
> 
> =======================================================
> 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.
> 


From stephen at sprunk.org  Fri Oct 10 09:27:34 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 10 Oct 2008 08:27:34 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081009204115.GF4140@nsn.com>
References: <C0F2465B4F386241A58321C884AC7ECC089204A7@E03MVZ2-UKDY.domain1.systemhost.net>	<F24EC748-B10D-45A1-BDC7-278F6CA2B94E@delong.com>	<20081009181553.GE4140@nsn.com>	<4B18DD8E-4AEB-4011-B83C-5E18B6DB84CA@delong.com>
	<20081009204115.GF4140@nsn.com>
Message-ID: <48EF5846.2010400@sprunk.org>

David Kessens wrote:
> On Thu, Oct 09, 2008 at 12:21:21PM -0700, Owen DeLong wrote:
>   
>> The same problem applies to Michael's much more elaborate effort at the same statement.
>>     
>
> Correct. Attempts to define special areas are bound to be wrong, complicated or unfair. That is why I don't support policies for special geographical areas.
>
> Let's have a minimum allocation boundary that works for everybody in the ARIN region (or better yet all RIRs) and be done with this.
>   

I'm all for fairness, but one must recognize that our Caribbean members 
operate in a rather different legal and economic environment than our US 
and Canadian members and thus different policy is, at times, justified 
to account for those differences.  With all due respect to folks there, 
they simply aren't big or numerous enough for this proposal to have any 
meaningful impact on the global routing table even in the case of 
widespread abuse, unlike the US and Canada.  Being supportive to our 
less fortunate neighbors is worth the minimal risk, IMHO.

If folks from other small island countries and territories in ARIN's 
region request special status, as folks in the Caribbean have, then I 
would support adding them to the list.  Since that has not happened, 
AFAICT, I do not find the simple act of failing to include them 
sufficient grounds to oppose this proposal.

S


From info at arin.net  Fri Oct 10 11:47:23 2008
From: info at arin.net (Member Services)
Date: Fri, 10 Oct 2008 11:47:23 -0400
Subject: [arin-ppml] Revised Policy Proposal 2007-14
In-Reply-To: <E6BA7842-FF32-4DD7-8537-3238D828636B@delong.com>
References: <E6BA7842-FF32-4DD7-8537-3238D828636B@delong.com>
Message-ID: <48EF790B.5050005@arin.net>

Policy Proposal 2007-14
Resource Review Process

This proposal has been revised. It is open for discussion on this
mailing list and will be on the agenda at the upcoming ARIN Public
Policy Meeting.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2007_14.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


Owen DeLong wrote:
> Some last minute changes to address concerns raised by staff and legal.
>
> These changes do not change the intent of the policy.
>
>
> Changes include:
> 	Paragraph 3 replaced with language proposed by staff
> 	Paragraph 8 replaced with language proposed by counsel
>
> I apologize for the last minute nature of these changes, however,
> the staff, counsel, and the authors have been working diligently
> over the last several days to address these issues as a result of
> the information in the recent staff/legal assessments posted to the
> list.
>
> Thanks,
>
> Owen
>
> Policy statement:
>
> Add the following to the NRPM:
>
> Resource Review
>
> 1. ARIN may review the current usage of any resources issued by ARIN  
> to an organization. The organization shall furnish whatever records  
> are necessary to perform this review.
>
> 2. ARIN may conduct such reviews:
>
> a. when any new resource is requested,
> b. whenever ARIN has cause to believe that the resources had  
> originally been obtained fraudulently, or
> c. at any other time without cause unless a prior review has been  
> completed in the preceding 24 months.
>
> 3. At the conclusion of a review in which ARIN has solicited  
> information from the resource holder,  ARIN shall communicate to the  
> resource holder that the review has been concluded and what, if any,  
> further actions are required of said resource holder.
>
> 4. Organizations shown to be substantially out of compliance with  
> current ARIN policy shall return resources as needed to bring them  
> into (or reasonably close to) compliance.
>
> 4a. The extent to which an organization may remain out of compliance  
> shall be based on the best judgment of the ARIN staff and shall  
> balance the organizations utilization rate, available address pool,  
> and other factors as appropriate so as to avoid forcing returns which  
> will result in near-term additional requests or unnecessary route de- 
> aggregation.
>
> 4b. To the extent possible, entire blocks should be returned. Partial  
> address blocks shall be returned in such a way that the portion  
> retained will comprise a single aggregate block.
>
> 5. If the organization does not voluntarily return resources as  
> required, ARIN may revoke any resources issued by ARIN as required to  
> bring the organization into overall compliance. ARIN shall follow the  
> same guidelines for revocation that are required for voluntary return  
> in the previous paragraph.
>
> 6. Except in cases of fraud, an organization shall be given a minimum  
> of six months to effect a return. ARIN shall negotiate a longer term  
> with the organization if ARIN believes the organization is working in  
> good faith to substantially restore compliance and has a valid need  
> for additional time to renumber out of the affected blocks.
>
> 7. ARIN shall continue to maintain the resource(s) while their return  
> or revocation is pending, except no new maintenance fees shall be  
> assessed for the resource(s).
>
> 8. This policy does not create any additional authority for ARIN to  
> revoke legacy address space. However, the utilization of legacy  
> resources shall be considered during a review to assess overall  
> compliance.
>
> 9. In considering compliance with policies which allow a timeframe  
> (such as a requirement to assign some number of prefixes within 5  
> years) failure to comply cannot be measured until after the timeframe  
> specified in the applicable policy has elapsed. Blocks subject to such  
> a policy shall be assumed in compliance with that policy until such  
> time as the specified time since issuance has elapsed.
>
>
>
> Delete NRPM sections 4.1.2, 4.1.3, 4.1.4
>
> Remove the sentence "In extreme cases, existing allocations may be  
> affected." from NRPM section 4.2.3.1.
>
> Rationale:
>
> ARIN feels that current policy does not give them the power to review  
> or reclaim resources except in cases of fraud, despite this being  
> mentioned in the Registration Services Agreement. This policy proposal  
> provides clear policy authority to do so, guidelines for how and under  
> what conditions it shall be done, and a guarantee of a (minimum) six- 
> month grace period so that the current user shall have time to  
> renumber out of any resources to be reclaimed.
>
> The nature of the "review" is to be of the same form as is currently  
> done when an organization requests new resources, i.e. the  
> documentation required and standards should be the same.
>
> The intent of paragraph 2c is to prevent ARIN from doing more than one  
> without-cause review in a 24 month period.
>
> The renumbering period does not affect any "hold" period that ARIN may  
> apply after return or revocation of resources is complete.
>
> The deleted sections/text would be redundant with the adoption of this  
> proposal.
>
> Timetable for implementation: Immediate
>
>
>
> _______________________________________________
> 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  Fri Oct 10 12:40:15 2008
From: farmer at umn.edu (David Farmer)
Date: Fri, 10 Oct 2008 11:40:15 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877ADF0D@ex1.cait.wustl.edu>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>,
	<48EEC3F4.8308.66F5837@farmer.umn.edu>,
	<EACF8B735E9CBA4B8BAF9E4165D030877ADF0D@ex1.cait.wustl.edu>
Message-ID: <48EF3F1F.13732.85078EA@farmer.umn.edu>

On 10 Oct 2008 Bill Darte wrote:

> David,
> 
> ARIN did not initiate the proposed change for the Caribbean sector.
>
> My first experience with issues surrounding this proposal was in a
> pre-sector meeting in St. Thomas February of '07.
> 
> There, many representatives of the Caribbean community voiced a variety
> of concerns related to limited infrastructure, lack of competition  due
> to powerful and protected imcumbency, etc.  They learned much about ARIN
> and learned more during the whole region meeting in Puerto Rico the
> following Spring at ARIN XIX. 
> 
> Cathy and Paul may correct me, but I believe the impetus for the actual
> writing of the proposal came during Open Policy Hour at ARIN XXI in
> Denver.  There, Bernadette Lewis, Secretary General of the Caribbean
> Telecommunications Union spoke about the need for change and support
> with addressing policy.
>
> Cathy and Paul responded by crafting a draft proposal very shortly
> thereafter.
>

Yes, I remember I was there and I raised the very issue I'm raising now.  
Why exclude the other small stuff by defining this with a scope limited to the 
Caribbean.  I even went back a review the Quicktime of the Open Policy 
Hour from Denver, because I honestly couldn't remember if I only thought 
about raising the issue or if I actually did. 

I'm going to have to stick with the courage of my convictions on this one, I 
simply cannot support this policy if it is limited to the Caribbean.  It has to 
include all of the smaller economies in the ARIN Region.  In my view the 
valid issue here is that the smaller economies simply can't meet ARIN's 
current requirements, which are mostly based on what is workable for the 
US and Canada, but that issue doesn't have a Caribbean box around it.

I also, think it is completely wrong for ARIN to lower the standards for the 
US and Canada, it mostly works here.  To that end, I'm going the completely 
withdraw the idea that the Arctic regions of the US and Canada are even 
part, or could even be part of this issue.  The economies of US and Canada 
are large enough to solve Arctic regions on their own.  

This discussion and reviewing the Open Policy Hour Quicktime from 
Denver, has help me to come to the conclusion that the proper scope of this 
issues and maybe even the proper title is "Small Economies within the ARIN 
Region"  

The issue here isn't a geographical region, "it's the economy, stupid." (it 
never cease to amaze me how many places that is a valid quote for :)) By 
scooping it by economy, we deal with population, infrastructure, and 
remoteness, etc... as they all play a role in an economy. 

I'll grant that primary effect of this policy will be in the Caribbean, they are 
probably the "Small Economies" that are even big enough and advanced 
enough to actually have the issue currently, but that doesn't make it right to 
exclude the other "Small Economies" from this policy.  

So, I support this important policy, iff (if an only if) it includes all the smaller 
economies in the ARIN Region.


=======================================================
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  Fri Oct 10 12:59:26 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 10 Oct 2008 17:59:26 +0100
Subject: [arin-ppml] Policy Proposal 2008-4 - New wording
In-Reply-To: <48EF3F1F.13732.85078EA@farmer.umn.edu>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC089CAF4F@E03MVZ2-UKDY.domain1.systemhost.net>

 
> I'm going to have to stick with the courage of my convictions 
> on this one, I simply cannot support this policy if it is 
> limited to the Caribbean.  It has to include all of the 
> smaller economies in the ARIN Region. 

New Title - Minimum Allocation in Special Regions
  
Add the following as section 4.8 of NRPM:

4.8.   Minimum Allocation. The minimum IPv4 allocation size for ISPs
from a Special Region within the ARIN region is /22.

   4.8.1. List of Special Regions

The following defined regions will be considered Special Regions for the
purposes of section 4.8:

   4.8.1.1 The country Barbados
   4.8.1.2 The country Bermuda
   4.8.1.3 The country Jamaica
   4.8.1.4 The French Overseas Department of Martinique
   4.8.1.5 The French Overseas Collectivity of St. Pierre & Miquelon
   
   4.8.2. Allocation Criteria.

*  The requesting organization must show the efficient
utilization of an entire previously allocated /22 from their
upstream ISP. This allocation (/22) may have been provided
by an ISP's upstream provider(s), and does not have to be
contiguous address space. The organization must meet the
requirement of efficient use of 4 /24s.


*  A multi-homed organization must show the efficient
utilization of an entire previously allocated /23 from their
upstream ISP. This allocation (/23) may have been provided
by an ISP's upstream provider(s), and does not have to be
contiguous address space. The organization must meet the
requirement of efficient use of 2 /24s.


*  Utilization Reporting and Justification. All other ARIN policies
regarding the reporting of justification information for the
allocation of IPv4 and IPv6 address space will remain in effect.

> I'll grant that primary effect of this policy will be in the 
> Caribbean, they are probably the "Small Economies" that are 
> even big enough and advanced enough to actually have the 
> issue currently, but that doesn't make it right to exclude 
> the other "Small Economies" from this policy.  

If you compare my wording above (with its incomplete list)
you will note that the changes are very minor. The biggest
change is to get every territory named on the list in an
unambigous way that is consistent with the grammar of the
run-on sentence in which the list is placed.

This is not a big task and really should be done.

--Michael Dillon

P.S. Because some people have difficulty with reading
comprehension, I have left of the U.S. and Canadian
territories that I mentioned earlier. I *NEVER* intended
that they be a part of this policy change. I only wanted
to demonstrate how a rational layout of the policy with
a list, made it much easier to add overlooked regions if
we should notice, at some future date, that we had overlooked
something.


From BillD at cait.wustl.edu  Fri Oct 10 13:20:04 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 10 Oct 2008 12:20:04 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <48EF3F1F.13732.85078EA@farmer.umn.edu>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>,
	<48EEC3F4.8308.66F5837@farmer.umn.edu>,
	<EACF8B735E9CBA4B8BAF9E4165D030877ADF0D@ex1.cait.wustl.edu>
	<48EF3F1F.13732.85078EA@farmer.umn.edu>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030877ADF4A@ex1.cait.wustl.edu>

Personally, I have no problem with your conclusion that a more
generalized proposal should emerge.

Given that, the central issue is that the proposal should change scope.
And, it has two possible solutions in time.
1. We can support the existing proposal and have two successful examples
(hopefully), that being the African community support and then the
Caribbean....and then introduce another more generalized proposal.
Or 2. we can abandon the existing proposal because it is not general
enough and propose the more general.

I see little service in later, compared to the former.

Bill Darte
ARIN AC
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
> Sent: Friday, October 10, 2008 11:40 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
> 
> On 10 Oct 2008 Bill Darte wrote:
> 
> > David,
> > 
> > ARIN did not initiate the proposed change for the Caribbean sector.
> >
> > My first experience with issues surrounding this proposal was in a 
> > pre-sector meeting in St. Thomas February of '07.
> > 
> > There, many representatives of the Caribbean community voiced a 
> > variety of concerns related to limited infrastructure, lack of 
> > competition  due to powerful and protected imcumbency, etc.  They 
> > learned much about ARIN and learned more during the whole region 
> > meeting in Puerto Rico the following Spring at ARIN XIX.
> > 
> > Cathy and Paul may correct me, but I believe the impetus for the 
> > actual writing of the proposal came during Open Policy Hour at ARIN 
> > XXI in Denver.  There, Bernadette Lewis, Secretary General of the 
> > Caribbean Telecommunications Union spoke about the need for 
> change and 
> > support with addressing policy.
> >
> > Cathy and Paul responded by crafting a draft proposal very shortly 
> > thereafter.
> >
> 
> Yes, I remember I was there and I raised the very issue I'm 
> raising now.  
> Why exclude the other small stuff by defining this with a 
> scope limited to the Caribbean.  I even went back a review 
> the Quicktime of the Open Policy Hour from Denver, because I 
> honestly couldn't remember if I only thought about raising 
> the issue or if I actually did. 
> 
> I'm going to have to stick with the courage of my convictions 
> on this one, I simply cannot support this policy if it is 
> limited to the Caribbean.  It has to include all of the 
> smaller economies in the ARIN Region.  In my view the valid 
> issue here is that the smaller economies simply can't meet 
> ARIN's current requirements, which are mostly based on what 
> is workable for the US and Canada, but that issue doesn't 
> have a Caribbean box around it.
> 
> I also, think it is completely wrong for ARIN to lower the 
> standards for the US and Canada, it mostly works here.  To 
> that end, I'm going the completely withdraw the idea that the 
> Arctic regions of the US and Canada are even part, or could 
> even be part of this issue.  The economies of US and Canada 
> are large enough to solve Arctic regions on their own.  
> 
> This discussion and reviewing the Open Policy Hour Quicktime 
> from Denver, has help me to come to the conclusion that the 
> proper scope of this issues and maybe even the proper title 
> is "Small Economies within the ARIN Region"  
> 
> The issue here isn't a geographical region, "it's the 
> economy, stupid." (it never cease to amaze me how many places 
> that is a valid quote for :)) By scooping it by economy, we 
> deal with population, infrastructure, and remoteness, etc... 
> as they all play a role in an economy. 
> 
> I'll grant that primary effect of this policy will be in the 
> Caribbean, they are probably the "Small Economies" that are 
> even big enough and advanced enough to actually have the 
> issue currently, but that doesn't make it right to exclude 
> the other "Small Economies" from this policy.  
> 
> So, I support this important policy, iff (if an only if) it 
> includes all the smaller economies in the ARIN Region.
> 
> 
> =======================================================
> 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.
> 


From dlw+arin at tellme.com  Fri Oct 10 13:24:22 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Fri, 10 Oct 2008 10:24:22 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877ADF4A@ex1.cait.wustl.edu>
References: <EACF8B735E9CBA4B8BAF9E4165D030877ADF0D@ex1.cait.wustl.edu>
	<48EF3F1F.13732.85078EA@farmer.umn.edu>
	<EACF8B735E9CBA4B8BAF9E4165D030877ADF4A@ex1.cait.wustl.edu>
Message-ID: <20081010172421.GV5704@shell02.cell.sv2.tellme.com>

I agree with Bill on this one.  Let's not punish the Caribbean folks
with a 6-month delay because we forgot to include 10,000 people
scattered across a few tiny islands.  I'd still like to see a simple
list defining the "Caribbean region" appended to the existing proposal,
but I wouldn't want to hold up adoption of this otherwise very worthy
proposal.

Out of curiosity, can someone from the ARIN staff tell us if we've ever
had *any* requests from St. Pierre and Miquelon or St. Helena?  (Since
those are the only inhabited locations that aren't "Caribbean" or
US/Canada....)  I suspect this is really a complete non-issue.  I would
just prefer that we remove ambiguity so future interpretation isn't
different from current intent.

-David

On Fri, Oct 10, 2008 at 12:20:04PM -0500, Bill Darte wrote:
> Personally, I have no problem with your conclusion that a more
> generalized proposal should emerge.
> 
> Given that, the central issue is that the proposal should change scope.
> And, it has two possible solutions in time.
> 1. We can support the existing proposal and have two successful examples
> (hopefully), that being the African community support and then the
> Caribbean....and then introduce another more generalized proposal.
> Or 2. we can abandon the existing proposal because it is not general
> enough and propose the more general.
> 
> I see little service in later, compared to the former.
> 
> Bill Darte
> ARIN AC
>  
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
> > Sent: Friday, October 10, 2008 11:40 AM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
> > 
> > On 10 Oct 2008 Bill Darte wrote:
> > 
> > > David,
> > > 
> > > ARIN did not initiate the proposed change for the Caribbean sector.
> > >
> > > My first experience with issues surrounding this proposal was in a 
> > > pre-sector meeting in St. Thomas February of '07.
> > > 
> > > There, many representatives of the Caribbean community voiced a 
> > > variety of concerns related to limited infrastructure, lack of 
> > > competition  due to powerful and protected imcumbency, etc.  They 
> > > learned much about ARIN and learned more during the whole region 
> > > meeting in Puerto Rico the following Spring at ARIN XIX.
> > > 
> > > Cathy and Paul may correct me, but I believe the impetus for the 
> > > actual writing of the proposal came during Open Policy Hour at ARIN 
> > > XXI in Denver.  There, Bernadette Lewis, Secretary General of the 
> > > Caribbean Telecommunications Union spoke about the need for 
> > change and 
> > > support with addressing policy.
> > >
> > > Cathy and Paul responded by crafting a draft proposal very shortly 
> > > thereafter.
> > >
> > 
> > Yes, I remember I was there and I raised the very issue I'm 
> > raising now.  
> > Why exclude the other small stuff by defining this with a 
> > scope limited to the Caribbean.  I even went back a review 
> > the Quicktime of the Open Policy Hour from Denver, because I 
> > honestly couldn't remember if I only thought about raising 
> > the issue or if I actually did. 
> > 
> > I'm going to have to stick with the courage of my convictions 
> > on this one, I simply cannot support this policy if it is 
> > limited to the Caribbean.  It has to include all of the 
> > smaller economies in the ARIN Region.  In my view the valid 
> > issue here is that the smaller economies simply can't meet 
> > ARIN's current requirements, which are mostly based on what 
> > is workable for the US and Canada, but that issue doesn't 
> > have a Caribbean box around it.
> > 
> > I also, think it is completely wrong for ARIN to lower the 
> > standards for the US and Canada, it mostly works here.  To 
> > that end, I'm going the completely withdraw the idea that the 
> > Arctic regions of the US and Canada are even part, or could 
> > even be part of this issue.  The economies of US and Canada 
> > are large enough to solve Arctic regions on their own.  
> > 
> > This discussion and reviewing the Open Policy Hour Quicktime 
> > from Denver, has help me to come to the conclusion that the 
> > proper scope of this issues and maybe even the proper title 
> > is "Small Economies within the ARIN Region"  
> > 
> > The issue here isn't a geographical region, "it's the 
> > economy, stupid." (it never cease to amaze me how many places 
> > that is a valid quote for :)) By scooping it by economy, we 
> > deal with population, infrastructure, and remoteness, etc... 
> > as they all play a role in an economy. 
> > 
> > I'll grant that primary effect of this policy will be in the 
> > Caribbean, they are probably the "Small Economies" that are 
> > even big enough and advanced enough to actually have the 
> > issue currently, but that doesn't make it right to exclude 
> > the other "Small Economies" from this policy.  
> > 
> > So, I support this important policy, iff (if an only if) it 
> > includes all the smaller economies in the ARIN Region.
> > 
> > 
> > =======================================================
> > 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.
> > 
> _______________________________________________
> 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 tme at multicasttech.com  Fri Oct 10 13:40:32 2008
From: tme at multicasttech.com (Marshall Eubanks)
Date: Fri, 10 Oct 2008 13:40:32 -0400
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <20081010172421.GV5704@shell02.cell.sv2.tellme.com>
References: <EACF8B735E9CBA4B8BAF9E4165D030877ADF0D@ex1.cait.wustl.edu>
	<48EF3F1F.13732.85078EA@farmer.umn.edu>
	<EACF8B735E9CBA4B8BAF9E4165D030877ADF4A@ex1.cait.wustl.edu>
	<20081010172421.GV5704@shell02.cell.sv2.tellme.com>
Message-ID: <4C595B7B-F284-4C68-BFCC-A33C0696B1A5@multicasttech.com>

There appear to be no autonomous systems based in those locations.

Regards
Marshall

On Oct 10, 2008, at 1:24 PM, David Williamson wrote:

> I agree with Bill on this one.  Let's not punish the Caribbean folks
> with a 6-month delay because we forgot to include 10,000 people
> scattered across a few tiny islands.  I'd still like to see a simple
> list defining the "Caribbean region" appended to the existing  
> proposal,
> but I wouldn't want to hold up adoption of this otherwise very worthy
> proposal.
>
> Out of curiosity, can someone from the ARIN staff tell us if we've  
> ever
> had *any* requests from St. Pierre and Miquelon or St. Helena?  (Since
> those are the only inhabited locations that aren't "Caribbean" or
> US/Canada....)  I suspect this is really a complete non-issue.  I  
> would
> just prefer that we remove ambiguity so future interpretation isn't
> different from current intent.
>
> -David
>
> On Fri, Oct 10, 2008 at 12:20:04PM -0500, Bill Darte wrote:
>> Personally, I have no problem with your conclusion that a more
>> generalized proposal should emerge.
>>
>> Given that, the central issue is that the proposal should change  
>> scope.
>> And, it has two possible solutions in time.
>> 1. We can support the existing proposal and have two successful  
>> examples
>> (hopefully), that being the African community support and then the
>> Caribbean....and then introduce another more generalized proposal.
>> Or 2. we can abandon the existing proposal because it is not general
>> enough and propose the more general.
>>
>> I see little service in later, compared to the former.
>>
>> Bill Darte
>> ARIN AC
>>
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net
>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
>>> Sent: Friday, October 10, 2008 11:40 AM
>>> To: arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
>>>
>>> On 10 Oct 2008 Bill Darte wrote:
>>>
>>>> David,
>>>>
>>>> ARIN did not initiate the proposed change for the Caribbean sector.
>>>>
>>>> My first experience with issues surrounding this proposal was in a
>>>> pre-sector meeting in St. Thomas February of '07.
>>>>
>>>> There, many representatives of the Caribbean community voiced a
>>>> variety of concerns related to limited infrastructure, lack of
>>>> competition  due to powerful and protected imcumbency, etc.  They
>>>> learned much about ARIN and learned more during the whole region
>>>> meeting in Puerto Rico the following Spring at ARIN XIX.
>>>>
>>>> Cathy and Paul may correct me, but I believe the impetus for the
>>>> actual writing of the proposal came during Open Policy Hour at ARIN
>>>> XXI in Denver.  There, Bernadette Lewis, Secretary General of the
>>>> Caribbean Telecommunications Union spoke about the need for
>>> change and
>>>> support with addressing policy.
>>>>
>>>> Cathy and Paul responded by crafting a draft proposal very shortly
>>>> thereafter.
>>>>
>>>
>>> Yes, I remember I was there and I raised the very issue I'm
>>> raising now.
>>> Why exclude the other small stuff by defining this with a
>>> scope limited to the Caribbean.  I even went back a review
>>> the Quicktime of the Open Policy Hour from Denver, because I
>>> honestly couldn't remember if I only thought about raising
>>> the issue or if I actually did.
>>>
>>> I'm going to have to stick with the courage of my convictions
>>> on this one, I simply cannot support this policy if it is
>>> limited to the Caribbean.  It has to include all of the
>>> smaller economies in the ARIN Region.  In my view the valid
>>> issue here is that the smaller economies simply can't meet
>>> ARIN's current requirements, which are mostly based on what
>>> is workable for the US and Canada, but that issue doesn't
>>> have a Caribbean box around it.
>>>
>>> I also, think it is completely wrong for ARIN to lower the
>>> standards for the US and Canada, it mostly works here.  To
>>> that end, I'm going the completely withdraw the idea that the
>>> Arctic regions of the US and Canada are even part, or could
>>> even be part of this issue.  The economies of US and Canada
>>> are large enough to solve Arctic regions on their own.
>>>
>>> This discussion and reviewing the Open Policy Hour Quicktime
>>> from Denver, has help me to come to the conclusion that the
>>> proper scope of this issues and maybe even the proper title
>>> is "Small Economies within the ARIN Region"
>>>
>>> The issue here isn't a geographical region, "it's the
>>> economy, stupid." (it never cease to amaze me how many places
>>> that is a valid quote for :)) By scooping it by economy, we
>>> deal with population, infrastructure, and remoteness, etc...
>>> as they all play a role in an economy.
>>>
>>> I'll grant that primary effect of this policy will be in the
>>> Caribbean, they are probably the "Small Economies" that are
>>> even big enough and advanced enough to actually have the
>>> issue currently, but that doesn't make it right to exclude
>>> the other "Small Economies" from this policy.
>>>
>>> So, I support this important policy, iff (if an only if) it
>>> includes all the smaller economies in the ARIN Region.
>>>
>>>
>>> =======================================================
>>> 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.
>>>
>> _______________________________________________
>> 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  Fri Oct 10 14:26:50 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Oct 2008 14:26:50 -0400
Subject: [arin-ppml] Heard and McDonald
Message-ID: <20081010182650.GA56362@ussenterprise.ufp.org>


I want to bring up an item that came up in the 2008-4 discussion
but IS COMPLETELY UNRELATED.  Please let's not discuss 2008-4 in
this thread.

The Heard and McDonald Islands are in the ARIN service region, as
defined at http://www.arin.net/community/ARINcountries.html.
Information on these islands can be found at
http://en.wikipedia.org/wiki/Heard_Island_and_McDonald_Islands or
if you don't trust Wikipeida,
https://www.cia.gov/library/publications/the-world-factbook/geos/hm.html.

Near as I can tell, APNIC allocates IP's for everywhere around this
set of islands, and the islands are territories of APNIC, which is
a country APNIC serves and is located in.  It seems to me that
should these islands ever need IP's (which is unlikely) that APNIC
is much better positioned to provide the resources.

Is there some procedure for ARIN and APNIC to agree to transfer
these islands from one service region to another?  Would anyone
else support (or oppose) such a move?

-- 
       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/20081010/9fbf6b3c/attachment.sig>

From bicknell at ufp.org  Fri Oct 10 14:30:21 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Oct 2008 14:30:21 -0400
Subject: [arin-ppml] Heard and McDonald
In-Reply-To: <20081010182650.GA56362@ussenterprise.ufp.org>
References: <20081010182650.GA56362@ussenterprise.ufp.org>
Message-ID: <20081010183021.GB56362@ussenterprise.ufp.org>

In a message written on Fri, Oct 10, 2008 at 02:26:50PM -0400, Leo Bicknell wrote:
> Near as I can tell, APNIC allocates IP's for everywhere around this
> set of islands, and the islands are territories of APNIC, which is
> a country APNIC serves and is located in.  It seems to me that

Man, some things you don't catch profreading your own e-mail.

APNIC does not have terrirtories, at least, that I know of.... :)
They are territories of Australia.

-- 
       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/20081010/47bcf97b/attachment.sig>

From woody at pch.net  Fri Oct 10 16:51:11 2008
From: woody at pch.net (Bill Woodcock)
Date: Fri, 10 Oct 2008 13:51:11 -0700 (PDT)
Subject: [arin-ppml] Heard and McDonald
In-Reply-To: <20081010182650.GA56362@ussenterprise.ufp.org>
References: <20081010182650.GA56362@ussenterprise.ufp.org>
Message-ID: <Pine.SOC.4.61.0810101350210.13912@paixhost.pch.net>

    > The Heard and McDonald Islands are in the ARIN service region, as
    > defined at http://www.arin.net/community/ARINcountries.html.
    > Information on these islands can be found at
    > http://en.wikipedia.org/wiki/Heard_Island_and_McDonald_Islands or
    > if you don't trust Wikipeida,
    > https://www.cia.gov/library/publications/the-world-factbook/geos/hm.html.
    > 
    > Near as I can tell, APNIC allocates IP's for everywhere around this
    > set of islands, and the islands are territories of APNIC, which is
    > a country APNIC serves and is located in.  It seems to me that
    > should these islands ever need IP's (which is unlikely) that APNIC
    > is much better positioned to provide the resources.

American Samoa made that choice at one point, and decided to approach 
APNIC for space, rather than ARIN, because Samoa uses APNIC, and they had 
more regional ties.

                                -Bill



From farmer at umn.edu  Fri Oct 10 17:36:53 2008
From: farmer at umn.edu (David Farmer)
Date: Fri, 10 Oct 2008 16:36:53 -0500
Subject: [arin-ppml] Heard and McDonald
In-Reply-To: <20081010182650.GA56362@ussenterprise.ufp.org>
References: <20081010182650.GA56362@ussenterprise.ufp.org>
Message-ID: <48EF84A5.11469.9600DC1@farmer.umn.edu>

On 10 Oct 2008 Leo Bicknell wrote:

> Is there some procedure for ARIN and APNIC to agree to transfer
> these islands from one service region to another?  Would anyone
> else support (or oppose) such a move?

I'd support the move.
 


=======================================================
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 bicknell at ufp.org  Fri Oct 10 18:04:14 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Oct 2008 18:04:14 -0400
Subject: [arin-ppml] Heard and McDonald
In-Reply-To: <20081010182650.GA56362@ussenterprise.ufp.org>
References: <20081010182650.GA56362@ussenterprise.ufp.org>
Message-ID: <20081010220414.GA72002@ussenterprise.ufp.org>


Upon further reflection this does not appear to be a policy matter,
and should probably be moved to the consultation and suggestion
process.

-- 
       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/20081010/e0db9039/attachment.sig>

From packetgrrl at gmail.com  Sun Oct 12 15:36:52 2008
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Sun, 12 Oct 2008 13:36:52 -0600
Subject: [arin-ppml] Policy Proposal 2008-4 - a consensus opinion?
In-Reply-To: <20081010035924.GA3266@vacation.karoshi.com.>
References: <20081009204115.GF4140@nsn.com>
	<48EE4037.30792.46CBDA0@farmer.umn.edu>
	<20081010035924.GA3266@vacation.karoshi.com.>
Message-ID: <c3227e9e0810121236w4e20d0c5n4c0a5d97a0a54ad7@mail.gmail.com>

Bill,

I am sure /32s will be very popular.  Let's add the equivalent for IPv6  and
we're all set.  !   The MICRO-ALLOCATION-GRRL (tm) torch has been handed off
to you though.   So knock yourself out.  :-)

----Cathy
(Formerly known as MICRO-ALLOCATION-GRRL currently known as Moose Whisperer)

On Thu, Oct 9, 2008 at 9:59 PM, <bmanning at vacation.karoshi.com> wrote:

> On Thu, Oct 09, 2008 at 05:32:39PM -0500, David Farmer wrote:
> > > Let's have a minimum allocation boundary that works for everybody in
> > > the ARIN region (or better yet all RIRs) and be done with this.
> >
> > This is like saying that there should be one and only one global set of
> Zoning
> > laws.  And, I don't believe in a one size fits all world.
> >
>
>        well, not to toss cold H2O on the fire, but routing is either
>        bilateral or global in scope... if one takes the view that
>        minalloc size affects global routing, then one-size does fit
>        the whole world...
>
>        that said, perhaps it is time to re-animate -MICRO-ALLOCATION GRRL-
> (tm)
>        and argue that the correct minium allocation for now should be
>        a /32, regardless of address family.
>
>        Cathy, are you up for it?
>
> --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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081012/a1807e19/attachment.htm>

From leo.vegoda at icann.org  Mon Oct 13 15:44:02 2008
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Mon, 13 Oct 2008 12:44:02 -0700
Subject: [arin-ppml] Policy Proposal 2008-4 - a consensus opinion?
In-Reply-To: <48EE9D05.20909.5D744C1@farmer.umn.edu>
Message-ID: <C51971A2.20291%leo.vegoda@icann.org>

On 10/10/2008 7:08, "David Farmer" <farmer at umn.edu> wrote:

[...]

> Bill if you say so, then the magic number is /29, see the following looking at
> 193/8 and 194/7;
>
> https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html
>
> I've been digging in and looking at stuff, I didn't realize any RIR were or
> did
> allocate /29s.

It may be worth noting that people sometimes require unique address space to
number relatively private internetworks. I believe the concept was accepted
by ARIN in policy proposal 2004-3 (Global Addresses for Private Network
Inter-Connectivity). ARIN policy section 4.3.5 now states that "When
private, non-connected networks require interconnectivity and the private IP
address numbers are ineffective, globally unique addresses may be requested
and used to provide this interconnectivity."

If a /29 works in this sort of situation it seems reasonable to allow such
an assignment, rather than forcing a /24 on the network and wasting 248
addresses. You *might* see announcements for /29s but I expect that very few
of these small PI assignments are intended to be publicly routed.

Regards,

Leo Vegoda



From michael.dillon at bt.com  Mon Oct 13 17:33:54 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 13 Oct 2008 22:33:54 +0100
Subject: [arin-ppml] Policy Proposal 2008-4 - a consensus opinion?
In-Reply-To: <C51971A2.20291%leo.vegoda@icann.org>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08A51CBE@E03MVZ2-UKDY.domain1.systemhost.net>

> It may be worth noting that people sometimes require unique 
> address space to number relatively private internetworks. I 
> believe the concept was accepted by ARIN in policy proposal 
> 2004-3 (Global Addresses for Private Network 
> Inter-Connectivity). ARIN policy section 4.3.5 now states 
> that "When private, non-connected networks require 
> interconnectivity and the private IP address numbers are 
> ineffective, globally unique addresses may be requested and 
> used to provide this interconnectivity."

This is misleading. RFC 2050 has always provided for allocating
IP address blocks for use on private INTERnetworks. Policy 2004-3
refers to private non-connected networks and accepts that even
this kind of network deserves an allocation if they have exhausted
the private network ranges.

--Michael Dillon


From farmer at umn.edu  Mon Oct 13 19:59:32 2008
From: farmer at umn.edu (David Farmer)
Date: Mon, 13 Oct 2008 18:59:32 -0500
Subject: [arin-ppml] Policy Proposal 2008-4 - Staff Assessment
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030877ADF4A@ex1.cait.wustl.edu>
References: <48EDCAEE.15993.2A299C1@farmer.umn.edu>,
	<48EF3F1F.13732.85078EA@farmer.umn.edu>,
	<EACF8B735E9CBA4B8BAF9E4165D030877ADF4A@ex1.cait.wustl.edu>
Message-ID: <48F39A94.8484.F6E257C@farmer.umn.edu>

On 10 Oct 2008 Bill Darte wrote:

> Personally, I have no problem with your conclusion that a more
> generalized proposal should emerge.

Actually, I'm not sure we need to generalize it like I was thinking earlier. 
 
> Given that, the central issue is that the proposal should change scope.
> And, it has two possible solutions in time.
> 1. We can support the existing proposal and have two successful examples
> (hopefully), that being the African community support and then the
> Caribbean....and then introduce another more generalized proposal.
> Or 2. we can abandon the existing proposal because it is not general
> enough and propose the more general.
> 
> I see little service in later, compared to the former.
> 
> Bill Darte
> ARIN AC

Actually, I think we can proceed with the proposal mostly as it currently is, I 
have what I think is one small change, and maybe some clarifying language 
that optionally could be added. 

But first I need to set things up a little bit;  I've been doing some research 
and a bit of thinking about this in the past few days.  Lets take a look at what 
currently the ARIN Staff seems to understand as being included in the 
proposal.

ANGUILLA  - Caribbean Sea, CARICOM Associate Member, Caribbean 
Telecommunications Union Member Member
	 
ANTIGUA AND BARBUDA  - Caribbean Sea, CARICOM full Member, 
Caribbean Telecommunications Union Member
	
BAHAMAS - Atlantic Ocean, CARICOM full Member, Caribbean 
Telecommunications Union Member	

BARBADOS - Caribbean Sea, CARICOM full Member	, Caribbean 
Telecommunications Union Member

BERMUDA - Atlantic Ocean, CARICOM Associate Member	

CAYMAN ISLANDS  - Caribbean Sea, CARICOM Associate Member, 
Caribbean Telecommunications Union Member
	
DOMINICA  - Caribbean Sea, CARICOM full Member, Caribbean 
Telecommunications Union Member
	
GRENADA  - Caribbean Sea, CARICOM full Member, Caribbean 
Telecommunications Union Member
	
GUADELOUPE  - Caribbean Sea

JAMAICA  - Caribbean Sea, CARICOM full Member, Caribbean 
Telecommunications Union Member

MARTINIQUE  - Caribbean Sea

MONTSERRAT  - Caribbean Sea, CARICOM full Member, Caribbean 
Telecommunications Union Member
	
PUERTO RICO  - Caribbean Sea, CARICOM Observer
	
SAINT BARTHELEMY  - Caribbean Sea	

SAINT KITTS AND NEVIS  - Caribbean Sea, CARICOM full Member, 
Caribbean Telecommunications Union Member

SAINT LUCIA  - Caribbean Sea, CARICOM full Member, Caribbean 
Telecommunications Union Member

SAINT VINCENT AND THE GRENADINES  - Caribbean Sea, CARICOM 
full Member, Caribbean Telecommunications Union Member

ST. MARTIN - Caribbean Sea	

TURKS AND CAICOS ISLANDS - Atlantic Ocean, CARICOM Associate 
Member, Caribbean Telecommunications Union Member	

VIRGIN ISLANDS (BRITISH) - Caribbean Sea, CARICOM Associate 
Member, Caribbean Telecommunications Union Member	

VIRGIN ISLANDS (U.S.) - Caribbean Sea

So being only slightly hyper technical here, the BAHAMAS, BERMUDA, and 
the TURKS AND CAICOS ISLANDS are not actually in the Caribbean Sea 
they are in the Atlantic Ocean.  So from a precise geographic point of view 
they are not part of the Caribbean.  

http://en.wikipedia.org/wiki/Caribbean

I'll grant you most people probably consider the BAHAMAS and the TURKS 
AND CAICOS ISLANDS as part of the Caribbean Region, they are in the 
same general area and mostly contagious with the Caribbean.  However, I'm 
not sure most people would consider BERMUDA as part of the Caribbean 
Region, it is 800 to 900 miles mostly north across open ocean.

Politically, the Caribbean Community (CARICOM), includes the BAHAMAS 
as a full member, BERMUDA, and the TURKS AND CAICOS ISLANDS are 
associate members.  However,  GUADELOUPE, MARTINIQUE, SAINT 
BARTHELEMY, ST. MARTIN, and VIRGIN ISLANDS (U.S.) don't seem to 
be part of CARICOM, and PUERTO RICO is only listed as an Observer.

http://en.wikipedia.org/wiki/Caribbean_Community
http://www.caricom.org/jsp/community/member_states.jsp?menu=communit
y

So how about the Caribbean Telecommunications Union, well BERMUDA, 
GUADELOUPE, MARTINIQUE, PUERTO RICO, SAINT BARTHELEMY, 
ST. MARTIN, and VIRGIN ISLANDS (U.S.) are not members.

http://www.ctu.int/ctu/AbouttheCTU/MemberStates/tabid/60/Default.aspx

So, how did we come up with the list above?  What was the criteria use to 
justify them all as part of the Caribbean?

I suggest we go with a slightly expanded geographically based definition 
"Atlantic and Caribbean Region".  This is a minor change that I think more 
accurately reflects the intent and what is already understood to be included.

Now lets look at what ARIN staff hasn't been included so far;

ANTARCTICA - Southernmost Continent
BOUVET ISLAND - Atlantic Ocean 
HEARD AND MC DONALD ISLANDS - Southern Ocean
ST. HELENA - Atlantic Ocean
ST. PIERRE AND MIQUELON - Atlantic Ocean
UNITED STATES MINOR OUTLYING ISLANDS - mostly Pacific Ocean, 3 
(w/disputed claims) in Caribbean Sea

I have left out CANADA, and the UNITED STATES, as I think every one 
agrees they shouldn't be included, or if we include them, then we should just 
make the change for all of ARIN.

Of these only ST. HELENA and ST. PIERRE AND MIQUELON have  
permanent inhabitants, which totals appropriately 10,000 people.  With the 
more accurate title proposed above these could easily be included in an 
"Atlantic and Caribbean Region" without really changing the scope of this 
proposal.

Everything else has no permanent inhabitants, most are uninhibited, a few 
have temporary inhabitants, generally military personal, support contractors, 
or scientific researches.  Many are protected from development as wildlife 
refuges and nature reserves, including ANTARCTICA threw international 
treaties. Therefore, it is extremely unlikely that competitive ISP service will 
ever be an issue worthy of consideration for these other territories that have 
no permanent inhabitants.  Any number resource needed, if there ever was 
a need, for these territories can likely be met by the various governmental 
entities that administrate them or buy the provider of the infrastructure, likely 
satellite.

The possible exception might be ANTARCTICA, but any need for number 
resources that can't be met by the various governmental entities or 
providers involved, would likely be highly specialized and probably justify a 
separate dedicated policy or a special exception to policy.

So I suggest the following small change;

"4.8. Minimum Allocation. The minimum IPv4 allocation size for ISPs from
the Atlantic and Caribbean portion of the ARIN region is /22."

I believe this change provides additionally clarity that BERMUDA, the 
BAHAMAS, and the TURKS AND CAICOS ISLANDS are included in this 
policy.  Additionally, it is easy to justify the inclusion of ST. HELENA and ST. 
PIERRE AND MIQUELON.  

Further, I recommend including the following clarifying language at the end 
of 4.8

"Defined as covering the permanently inhabited islands contained in the 
Atlantic Ocean and Caribbean Sea, that are not part a State in the United 
States or a part of Canada."

See you in LA!



=======================================================
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 owen at delong.com  Tue Oct 14 17:47:30 2008
From: owen at delong.com (Owen DeLong)
Date: Tue, 14 Oct 2008 14:47:30 -0700
Subject: [arin-ppml] Errors in 2007-14 Revision 3.2
Message-ID: <3B7D6BB9-955C-4992-99DE-BE47D082C269@delong.com>

Unfortunately, somehow the version 3.2 that was sent to the mailing list
was apparently the result of applying the intended 3.2 updates to an  
older
version than 3.1.

Below is the corrected 3.2 which for clarity I will call version 3.3.

Apologies for any inconvenience or misunderstanding.  The updates  
actually
conducted remain the same...

Section 3 updated to address concerns from ARIN staff.
Section 7 and 8 changed to address concerns from legal.


Policy Proposal 2007-14
Resource Review Process

Author: Owen DeLong, Stephen Sprunk

Proposal Version: 3.3

Date: 14 October 2008

Proposal type: modify

Policy term: permanent

Policy statement:

Add the following to the NRPM:

Resource Review

1. ARIN may review the current usage of any resources maintained in  
the ARIN database. The organization shall cooperate with any request  
from ARIN for reasonable related documentation.

2. ARIN may conduct such reviews:

a. when any new resource is requested,

b. whenever ARIN has reason to believe that the resources were  
originally obtained fraudulently or in contravention of existing  
policy, or

c. at any other time without having to establish cause unless a prior  
review has been completed in the preceding 24 months.

3. At the conclusion of a review in which ARIN has solicited  
information from the resource holder, ARIN shall communicate to the  
resource holder that the review has been concluded and what, if any,  
further actions are required.

4. Organizations found by ARIN to be  materially out of compliance  
with current ARIN policy shall be requested or required to return  
resources as needed to bring them into (or reasonably close to)  
compliance.

4a. The degree to which an organization may remain out of compliance  
shall be based on the reasonable judgment of the ARIN staff and shall  
balance all facts known, including the organization?s utilization rate,
available address pool, and other factors as appropriate so as to  
avoid forcing returns which will result in near-term additional  
requests or unnecessary route de-aggregation.

4b. To the extent possible, entire blocks should be returned. Partial  
address blocks shall be returned in such a way that the portion  
retained will comprise a single aggregate block.

5. If the organization does not voluntarily return resources as  
requested, ARIN may revoke any resources issued by ARIN as required to  
bring the organization into overall compliance. ARIN shall follow the  
same guidelines for revocation that are required for voluntary return  
in the previous paragraph.

6. Except in cases of fraud, or violations of policy, an organization  
shall be given a minimum of six months to effect a return. ARIN shall  
negotiate a longer term with the organization if ARIN believes the  
organization is working in good faith to substantially restore  
compliance and has a valid need for additional time to renumber out of  
the affected blocks.

7. ARIN shall continue to provide services for the resource(s) while  
their return or revocation is pending, except any maintenance fees  
assessed during that period shall be calculated as if the return or  
revocation was complete.

8. This policy does not create any additional authority for ARIN to  
revoke legacy address space. However, the utilization of legacy  
resources shall be considered during a review to assess overall  
compliance.

9. In considering compliance with policies which allow a timeframe  
(such as a requirement to assign some number of prefixes within 5  
years), failure to comply cannot be measured until after the timeframe  
specified in the applicable policy has elapsed. Blocks subject to such  
a policy shall be assumed in compliance with that policy until such  
time as the specified time since issuance has elapsed.

Delete NRPM sections 4.1.2, 4.1.3, 4.1.4

Remove the sentence "In extreme cases, existing allocations may be  
affected." from NRPM section 4.2.3.1.

Rationale:

Under current policy and existing RSAs, ARIN has an unlimited  
authority to audit or review a resource holder's utilization for  
compliance at any time and no requirement to communicate the results  
of any such review to the resource holder.

This policy attempts to balance the needs of the community and the  
potential for abuse of process by ARIN in a way that better clarifies  
the purpose, scope, and capabilities of ARIN and codifies some  
appropriate protections for resource holders while still preserving  
the ability for ARIN to address cases of fraud and abuse on an  
expedited basis.

The intended nature of the review is to be no more invasive than what  
usually happens when an organization applies for additional resources.  
Additionally, paragraph 2c prevents ARIN from doing excessive without- 
cause reviews.

The authors believe that this update addresses the majority of the  
feedback received from the community to date and addresses most of the  
concerns expressed.


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

From info at arin.net  Tue Oct 14 18:52:52 2008
From: info at arin.net (Member Services)
Date: Tue, 14 Oct 2008 18:52:52 -0400
Subject: [arin-ppml] Errors in 2007-14 Revision 3.2
In-Reply-To: <3B7D6BB9-955C-4992-99DE-BE47D082C269@delong.com>
References: <3B7D6BB9-955C-4992-99DE-BE47D082C269@delong.com>
Message-ID: <48F522C4.2050404@arin.net>

Policy Proposal 2007-14
Resource Review Process

This proposal has been revised. It is open for discussion on this
mailing list and will be on the agenda at the upcoming ARIN Public
Policy Meeting.

The current policy proposal text is provided below and is also available
at: http://www.arin.net/policy/proposals/2007_14.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


Owen DeLong wrote:
> Unfortunately, somehow the version 3.2 that was sent to the mailing list
> was apparently the result of applying the intended 3.2 updates to an older
> version than 3.1.
>
> Below is the corrected 3.2 which for clarity I will call version 3.3.
>
> Apologies for any inconvenience or misunderstanding. The updates actually
> conducted remain the same...
>
> Section 3 updated to address concerns from ARIN staff.
> Section 7 and 8 changed to address concerns from legal.
>
>
> Policy Proposal 2007-14
> Resource Review Process
>
> Author: Owen DeLong, Stephen Sprunk
>
> Proposal Version: 3.3
>
> Date: 14 October 2008
>
> Proposal type: modify
>
> Policy term: permanent
>
> Policy statement:
>
> Add the following to the NRPM:
>
> Resource Review
>
> 1. ARIN may review the current usage of any resources maintained in 
> the ARIN database. The organization shall cooperate with any request 
> from ARIN for reasonable related documentation.
>
> 2. ARIN may conduct such reviews:
>
>     a. when any new resource is requested,
>
>     b. whenever ARIN has reason to believe that the resources were
>     originally obtained fraudulently or in contravention of existing
>     policy, or
>
>     c. at any other time without having to establish cause unless a
>     prior review has been completed in the preceding 24 months.
>
> 3. At the conclusion of a review in which ARIN has solicited 
> information from the resource holder, ARIN shall communicate to the 
> resource holder that the review has been concluded and what, if any, 
> further actions are required.
>
> 4. Organizations found by ARIN to be materially out of compliance with 
> current ARIN policy shall be requested or required to return resources 
> as needed to bring them into (or reasonably close to) compliance.
>
>     4a. The degree to which an organization may remain out of
>     compliance shall be based on the reasonable judgment of the ARIN
>     staff and shall balance all facts known, including the
>     organization?s utilization rate,
>     available address pool, and other factors as appropriate so as to
>     avoid forcing returns which will result in near-term additional
>     requests or unnecessary route de-aggregation.
>
>     4b. To the extent possible, entire blocks should be returned.
>     Partial address blocks shall be returned in such a way that the
>     portion retained will comprise a single aggregate block.
>
> 5. If the organization does not voluntarily return resources as 
> requested, ARIN may revoke any resources issued by ARIN as required to 
> bring the organization into overall compliance. ARIN shall follow the 
> same guidelines for revocation that are required for voluntary return 
> in the previous paragraph.
>
> 6. Except in cases of fraud, or violations of policy, an organization 
> shall be given a minimum of six months to effect a return. ARIN shall 
> negotiate a longer term with the organization if ARIN believes the 
> organization is working in good faith to substantially restore 
> compliance and has a valid need for additional time to renumber out of 
> the affected blocks.
>
> 7. ARIN shall continue to provide services for the resource(s) while 
> their return or revocation is pending, except any maintenance fees 
> assessed during that period shall be calculated as if the return or 
> revocation was complete.
>
> 8. This policy does not create any additional authority for ARIN to 
> revoke legacy address space. However, the utilization of legacy 
> resources shall be considered during a review to assess overall 
> compliance.
>
> 9. In considering compliance with policies which allow a timeframe 
> (such as a requirement to assign some number of prefixes within 5 
> years), failure to comply cannot be measured until after the timeframe 
> specified in the applicable policy has elapsed. Blocks subject to such 
> a policy shall be assumed in compliance with that policy until such 
> time as the specified time since issuance has elapsed.
>
> Delete NRPM sections 4.1.2, 4.1.3, 4.1.4
>
> Remove the sentence "In extreme cases, existing allocations may be 
> affected." from NRPM section 4.2.3.1.
>
> Rationale:
>
> Under current policy and existing RSAs, ARIN has an unlimited 
> authority to audit or review a resource holder's utilization for 
> compliance at any time and no requirement to communicate the results 
> of any such review to the resource holder.
>
> This policy attempts to balance the needs of the community and the 
> potential for abuse of process by ARIN in a way that better clarifies 
> the purpose, scope, and capabilities of ARIN and codifies some 
> appropriate protections for resource holders while still preserving 
> the ability for ARIN to address cases of fraud and abuse on an 
> expedited basis.
>
> The intended nature of the review is to be no more invasive than what 
> usually happens when an organization applies for additional resources. 
> Additionally, paragraph 2c prevents ARIN from doing excessive 
> without-cause reviews.
>
> The authors believe that this update addresses the majority of the 
> feedback received from the community to date and addresses most of the 
> concerns expressed.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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  Wed Oct 15 07:44:34 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 15 Oct 2008 12:44:34 +0100
Subject: [arin-ppml] Paul Krugman on bad equilibriums
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08AC1FB4@E03MVZ2-UKDY.domain1.systemhost.net>


I've just been reading a paper by Paul Krugman who recently
won the Economics Prize in memory of Alfred Nobel. The
paper is entitled "Supply, Demand, and English Food" but
I think it explains what has gone wrong with IPv6 some
10 years after it was developed.

Here's a relevant quotation:

   But the history of English food 
   suggests that even on so
   basic a matter as eating, a 
   free-market economy can get trapped for
   an extended period in a bad equilibrium 
   in which good things are not
   demanded because they have never 
   been supplied, and are not supplied
   because not enough people demand them.

--Michael Dillon


From info at arin.net  Wed Oct 15 11:26:01 2008
From: info at arin.net (Member Services)
Date: Wed, 15 Oct 2008 11:26:01 -0400
Subject: [arin-ppml] ARIN XXII Now Underway
Message-ID: <48F60B89.9070108@arin.net>

The ARIN XXII Public Policy and Members Meeting begins today in Los 
Angeles, California.

For those in the community who were unable to make it to LA, ARIN is 
offering a webcast and live transcript of the Public Policy and Members 
Meetings. The times of the broadcast are as follows:

Public Policy Meeting (Policy and technical discussions)
Wednesday, 15 October    11AM - 5PM
Thursday, 16 October    9AM - 4:30PM

Members Meeting (ARIN reports, Board of Trustees and Advisory Council 
reports, and candidate speeches)
Friday, 17 October               9AM - 12PM

All times are Pacific Daylight Time (PDT), (UTC/GMT -7 hours)

You may register as a remote participant at any time throughout the 
meeting, and registered remote participants may join in the meeting chat 
to vote in straw polls and submit questions or comments during the times 
listed above. Pre-register your Jabber Identifier (JID) to have full 
chat room access from the start of the meeting.  You can register a JID 
at any time, but we will only be adding new participants during 
scheduled breaks in the meeting.  The full agenda is available at 
http://www.arin.net/ARIN-XXII/agenda.html.

For details about how to connect to the webcast, chat, and live 
transcript, or to refer to the
Remote Participation Acceptable Use Policy, please see:

http://www.arin.net/ARIN-XXII/remote.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From marla.azinger at frontiercorp.com  Thu Oct 16 13:45:01 2008
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Thu, 16 Oct 2008 13:45:01 -0400
Subject: [arin-ppml] Different Approach to the Transfer and Market issue-
	input requested
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048140EF135@ROCH-EXCH1.corp.pvt>

Hello-

As promised here is an alternative proposal.  It has not officially been submitted in order to gain community feedback and revision before submitting.  Thank you everyone that has already shown interest in persuing this alternative approach.  Please be advised that this is a suggested new section to NRPM in addition to keeping the current section 4.6 Voluntary Partial Returns and Amnesty.

If you are here at ARIN please find Marla Azinger or Jason schiller at the breaks to discuss.  Cheers!

Name: Active Reclamation of abandoned number resources

Rational:
This policy addresses the following:

 1.  Find, reclaim and re-use unused number resources.
 2.  Give incentive to keep unused number resources out of the black market.
 3.  Assist ARIN in cleaning up the database.
 4.  Provide an incentive to self identify and return unused resources.
 5.  Increase efficient utilization of ARIN number resources.
 6.  Help ease the transition to IPv6.
 7.  Help ensure fair re-distribution of resources to those who need them.


NRPM#: Active Reclamation of abandoned number resources
ARIN will actively investigate and ensure abandoned ARIN number resources including legacy resources that are under ARIN management are returned to the ARIN address pool for recirculation.  Any one may submit a report of abandonment for ARIN to investigate.  ARIN may investigate abandonment without a report when ARIN has reason to believe it has been abandoned.

ARIN can use their discretion to determine if someone is abusing this policy by submitting multiple reports with poor evidence of abandonment.  This will result in a loss of claim to all reports currently in progress by the perceived abuser  ARIN has the right to reject investigation requests if they deem the reporting entity is abusing the policy.

Addresses that are squatted and efficiently used will be granted amnesty if the addresses are self reported, back billing is reconciled and any applicable RSA is signed.  Partial returns and amnesty can be granted to squatted addresses under this policy.

            Management of abandoned number resources
-ARIN will keep a Lost Property Office via a direct link from the main ARIN website.
-ARIN will publicly list all number resources that are reported abandoned on the Lost Property Office site and the status of the investigation.  Stats of recovered space through the abandoned number resources will be provided bi-annually at the ARIN Members Meetings.
- ARIN will take measures to identify a chain of custody or successor in interest to the last known POC.  If the successor is determined, the block will be transferred to the successor under current ARIN policy.
- If the number resources are not valid for transfer to the successor and the original finder is not eligible to receive the number resources then the block will be added back into the ARIN address pool for re-use.
-The original "finder" is eligible for receipt of the addresses if they are currently eligible per ARIN policy to receive more addresses and the addresses are not transferred to a chain of custody that was discovered during investigation.
- If an investigation reveals a successor who is unaware of their number resources, ARIN can decide if there is good faith and sufficient justification for the successor to keep the resources. Partial returns and amnesty can be granted to sucessors for blocks revealed in and investigation under this policy.
-Before ARIN re-uses allegedly abandoned resources ARIN will work with ISP's to route these resources no less than 90 days in order to validate they are not in use.
-The original "finder" will receive a "finders" compensation for the listing when either resolution occurs.  *For example a credit could be put towards their annual fees.
-To report an abandoned block, send a request for investigation via the Abandoned Block Template.
            Examples of Abandoned number resources:
            - Unused Legacy (e.g. swamp)
            -Business failure and the number resources are not currently assigned nor in use.
            -Bad recordkeeping by an otherwise functional entity.
            -Squatted space that is not self reported.

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

From tvest at pch.net  Thu Oct 16 15:05:01 2008
From: tvest at pch.net (Tom Vest)
Date: Thu, 16 Oct 2008 12:05:01 -0700
Subject: [arin-ppml] Different Approach to the Transfer and Market
	issue- input requested
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048140EF135@ROCH-EXCH1.corp.pvt>
References: <2E2FECEBAE57CC4BAACDE67638305F1048140EF135@ROCH-EXCH1.corp.pvt>
Message-ID: <C656DDCD-F6F6-48CE-9AD2-4A83D97A8AA2@pch.net>

Hi Marla and Jason,

Thanks for sharing this.

A couple of questions:

-- Have you had a look at the ISI/Heideman survey?

http://www.isi.edu/~johnh/PAPERS/Heidemann08c.pdf

-- How will investigators distinguish between abandoned and active but  
invisible address space?
-- A related question, how will the process avoid incentivizing  
finders to squat on abandoned space themselves rather than to report  
report it to ARIN?  
-- How will the cost of investigations, finder's fees, and the Lost  
Property Office be covered?
-- Presumably, over time the discovery process will get progressively  
slower. At what point will the process be deemed to be complete, and  
what happens to the policy mechanisms at that time?

Thanks,

TV

On Oct 16, 2008, at 10:45 AM, Azinger, Marla wrote:

> Hello-
>
> As promised here is an alternative proposal.  It has not officially  
> been submitted in order to gain community feedback and revision  
> before submitting.  Thank you everyone that has already shown  
> interest in persuing this alternative approach.  Please be advised  
> that this is a suggested new section to NRPM in addition to keeping  
> the current section 4.6 Voluntary Partial Returns and Amnesty.
>
> If you are here at ARIN please find Marla Azinger or Jason schiller  
> at the breaks to discuss.  Cheers!
>
> Name: Active Reclamation of abandoned number resources
>
> Rational:
> This policy addresses the following:
> 	? Find, reclaim and re-use unused number resources.
> 	? Give incentive to keep unused number resources out of the black  
> market.
> 	? Assist ARIN in cleaning up the database.
> 	? Provide an incentive to self identify and return unused resources.
> 	? Increase efficient utilization of ARIN number resources.
> 	? Help ease the transition to IPv6.
> 	? Help ensure fair re-distribution of resources to those who need  
> them.
>
> NRPM#: Active Reclamation of abandoned number resources
> ARIN will actively investigate and ensure abandoned ARIN number  
> resources including legacy resources that are under ARIN management  
> are returned to the ARIN address pool for recirculation.  Any one  
> may submit a report of abandonment for ARIN to investigate.  ARIN  
> may investigate abandonment without a report when ARIN has reason to  
> believe it has been abandoned.
>
> ARIN can use their discretion to determine if someone is abusing  
> this policy by submitting multiple reports with poor evidence of  
> abandonment.  This will result in a loss of claim to all reports  
> currently in progress by the perceived abuser  ARIN has the right to  
> reject investigation requests if they deem the reporting entity is  
> abusing the policy.
>
> Addresses that are squatted and efficiently used will be granted  
> amnesty if the addresses are self reported, back billing is  
> reconciled and any applicable RSA is signed.  Partial returns and  
> amnesty can be granted to squatted addresses under this policy.
>
>             Management of abandoned number resources
> -ARIN will keep a Lost Property Office via a direct link from the  
> main ARIN website.
> -ARIN will publicly list all number resources that are reported  
> abandoned on the Lost Property Office site and the status of the  
> investigation.  Stats of recovered space through the abandoned  
> number resources will be provided bi-annually at the ARIN Members  
> Meetings.
> - ARIN will take measures to identify a chain of custody or  
> successor in interest to the last known POC.  If the successor is  
> determined, the block will be transferred to the successor under  
> current ARIN policy.
> - If the number resources are not valid for transfer to the  
> successor and the original finder is not eligible to receive the  
> number resources then the block will be added back into the ARIN  
> address pool for re-use.
> -The original ?finder? is eligible for receipt of the addresses if  
> they are currently eligible per ARIN policy to receive more  
> addresses and the addresses are not transferred to a chain of  
> custody that was discovered during investigation.
> - If an investigation reveals a successor who is unaware of their  
> number resources, ARIN can decide if there is good faith and  
> sufficient justification for the successor to keep the resources.  
> Partial returns and amnesty can be granted to sucessors for blocks  
> revealed in and investigation under this policy.
> -Before ARIN re-uses allegedly abandoned resources ARIN will work  
> with ISP?s to route these resources no less than 90 days in order to  
> validate they are not in use.
> -The original ?finder? will receive a ?finders? compensation for the  
> listing when either resolution occurs.  *For example a credit could  
> be put towards their annual fees.
> -To report an abandoned block, send a request for investigation via  
> the Abandoned Block Template.
>             Examples of Abandoned number resources:
>             - Unused Legacy (e.g. swamp)
>             -Business failure and the number resources are not  
> currently assigned nor in use.
>             -Bad recordkeeping by an otherwise functional entity.
>             -Squatted space that is not self reported.
>
> _______________________________________________
> 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 marla.azinger at frontiercorp.com  Thu Oct 16 17:39:11 2008
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Thu, 16 Oct 2008 17:39:11 -0400
Subject: [arin-ppml] Different Approach to the Transfer and Market
 issue- input requested
In-Reply-To: <C656DDCD-F6F6-48CE-9AD2-4A83D97A8AA2@pch.net>
References: <2E2FECEBAE57CC4BAACDE67638305F1048140EF135@ROCH-EXCH1.corp.pvt>
	<C656DDCD-F6F6-48CE-9AD2-4A83D97A8AA2@pch.net>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048140EF4CE@ROCH-EXCH1.corp.pvt>

-- How will investigators distinguish between abandoned and active but invisible address space?

ARIN staff has records that they can first refer to and any block with current and good contact info is never considered abondoned.  Two ARIN will publicly post all number resources on a public link off of the ARIN website.  Anyone can check this at anytime to see if one of their invisible blocks may mistakenly be under investigation.


-- A related question, how will the process avoid incentivizing finders to squat on abandoned space themselves rather than to report it to ARIN?

We can require that they demonstrate a period of squatting prior to the submission of this proposal.  However, there are plenty of incentives in this document to entice a person to report any number resources they have found that are not in use.


-- How will the cost of investigations, finder's fees, and the Lost Property Office be covered?

Cost would be covered just as all other policy is covered.  The staff will need to do an assessment on this policy for us to know what the cost might actually be to do this.


-- Presumably, over time the discovery process will get progressively slower. At what point will the process be deemed to be complete, and what happens to the policy mechanisms at that time?

We simply see it as a policy that isnt envoked if it isnt needed. We don't see this as a policy that would ever become truely obsolete due to the fact that companies will continue to go out of business and buy outs will occur without proper notification to ARIN being completed.



-----Original Message-----
From: Tom Vest [mailto:tvest at pch.net]
Sent: Thursday, October 16, 2008 12:05 PM
To: Azinger, Marla
Cc: ARIN PPML; Jason Schiller
Subject: Re: [arin-ppml] Different Approach to the Transfer and Market issue- input requested

Hi Marla and Jason,

Thanks for sharing this.

A couple of questions:

-- Have you had a look at the ISI/Heideman survey?

http://www.isi.edu/~johnh/PAPERS/Heidemann08c.pdf

-- How will investigators distinguish between abandoned and active but invisible address space?
-- A related question, how will the process avoid incentivizing finders to squat on abandoned space themselves rather than to report report it to ARIN?
-- How will the cost of investigations, finder's fees, and the Lost Property Office be covered?
-- Presumably, over time the discovery process will get progressively slower. At what point will the process be deemed to be complete, and what happens to the policy mechanisms at that time?

Thanks,

TV

On Oct 16, 2008, at 10:45 AM, Azinger, Marla wrote:

> Hello-
>
> As promised here is an alternative proposal.  It has not officially
> been submitted in order to gain community feedback and revision before
> submitting.  Thank you everyone that has already shown interest in
> persuing this alternative approach.  Please be advised that this is a
> suggested new section to NRPM in addition to keeping the current
> section 4.6 Voluntary Partial Returns and Amnesty.
>
> If you are here at ARIN please find Marla Azinger or Jason schiller at
> the breaks to discuss.  Cheers!
>
> Name: Active Reclamation of abandoned number resources
>
> Rational:
> This policy addresses the following:
>       * Find, reclaim and re-use unused number resources.
>       * Give incentive to keep unused number resources out of the
> black market.
>       * Assist ARIN in cleaning up the database.
>       * Provide an incentive to self identify and return unused resources.
>       * Increase efficient utilization of ARIN number resources.
>       * Help ease the transition to IPv6.
>       * Help ensure fair re-distribution of resources to those who
> need them.
>
> NRPM#: Active Reclamation of abandoned number resources ARIN will
> actively investigate and ensure abandoned ARIN number resources
> including legacy resources that are under ARIN management are returned
> to the ARIN address pool for recirculation.  Any one may submit a
> report of abandonment for ARIN to investigate.  ARIN may investigate
> abandonment without a report when ARIN has reason to believe it has
> been abandoned.
>
> ARIN can use their discretion to determine if someone is abusing this
> policy by submitting multiple reports with poor evidence of
> abandonment.  This will result in a loss of claim to all reports
> currently in progress by the perceived abuser  ARIN has the right to
> reject investigation requests if they deem the reporting entity is
> abusing the policy.
>
> Addresses that are squatted and efficiently used will be granted
> amnesty if the addresses are self reported, back billing is reconciled
> and any applicable RSA is signed.  Partial returns and amnesty can be
> granted to squatted addresses under this policy.
>
>             Management of abandoned number resources -ARIN will keep a
> Lost Property Office via a direct link from the main ARIN website.
> -ARIN will publicly list all number resources that are reported
> abandoned on the Lost Property Office site and the status of the
> investigation.  Stats of recovered space through the abandoned number
> resources will be provided bi-annually at the ARIN Members Meetings.
> - ARIN will take measures to identify a chain of custody or successor
> in interest to the last known POC.  If the successor is determined,
> the block will be transferred to the successor under current ARIN
> policy.
> - If the number resources are not valid for transfer to the successor
> and the original finder is not eligible to receive the number
> resources then the block will be added back into the ARIN address pool
> for re-use.
> -The original "finder" is eligible for receipt of the addresses if
> they are currently eligible per ARIN policy to receive more addresses
> and the addresses are not transferred to a chain of custody that was
> discovered during investigation.
> - If an investigation reveals a successor who is unaware of their
> number resources, ARIN can decide if there is good faith and
> sufficient justification for the successor to keep the resources.
> Partial returns and amnesty can be granted to sucessors for blocks
> revealed in and investigation under this policy.
> -Before ARIN re-uses allegedly abandoned resources ARIN will work with
> ISP's to route these resources no less than 90 days in order to
> validate they are not in use.
> -The original "finder" will receive a "finders" compensation for the
> listing when either resolution occurs.  *For example a credit could be
> put towards their annual fees.
> -To report an abandoned block, send a request for investigation via
> the Abandoned Block Template.
>             Examples of Abandoned number resources:
>             - Unused Legacy (e.g. swamp)
>             -Business failure and the number resources are not
> currently assigned nor in use.
>             -Bad recordkeeping by an otherwise functional entity.
>             -Squatted space that is not self reported.
>
> _______________________________________________
> 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  Fri Oct 17 14:50:13 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Fri, 17 Oct 2008 11:50:13 -0700
Subject: [arin-ppml] Different Approach to the Transfer and Market
 issue- input requested
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048140EF135@ROCH-EXCH1.corp.pvt>
References: <2E2FECEBAE57CC4BAACDE67638305F1048140EF135@ROCH-EXCH1.corp.pvt>
Message-ID: <48F8DE65.8080701@internap.com>

I would oppose this if proposed as written.  I think it is dangerous to 
encourage vigilantes to get involved in reclamation efforts.  I am also 
concerned about the "squatter" language.

I think the direction we need to go on reclamation is to direct ARIN to 
find and reclaim netblocks registered to organizations who are no longer 
around, and aggressively reclaim resources involved in attempted fraud.  I 
don't think we need new policy there (beyond 2007-14).

-Scott

Azinger, Marla wrote:
> Hello-
>  
> As promised here is an alternative proposal.  It has not officially been 
> submitted in order to gain community feedback and revision before 
> submitting.  Thank you everyone that has already shown interest in 
> persuing this alternative approach.  Please be advised that this is a 
> suggested new section to NRPM in addition to keeping the current section 
> 4.6 Voluntary Partial Returns and Amnesty. 
>  
> If you are here at ARIN please find Marla Azinger or Jason schiller at 
> the breaks to discuss.  Cheers!
>  
> *Name: Active Reclamation of abandoned number resources*
>  
> 
> *Rational:*
> 
> This policy addresses the following:
> 
>    1. Find, reclaim and re-use unused number resources.
>    2. Give incentive to keep unused number resources out of the black
>       market.
>    3. Assist ARIN in cleaning up the database.
>    4. Provide an incentive to self identify and return unused resources.
>    5. Increase efficient utilization of ARIN number resources.
>    6. Help ease the transition to IPv6.
>    7. Help ensure fair re-distribution of resources to those who need them.
> 
>  
> *NRPM#: Active Reclamation of abandoned number resources*
> 
> ARIN will actively investigate and ensure abandoned ARIN number 
> resources including legacy resources that are under ARIN management are 
> returned to the ARIN address pool for recirculation.  Any one may submit 
> a report of abandonment for ARIN to investigate.  ARIN may investigate 
> abandonment without a report when ARIN has reason to believe it has been 
> abandoned.
> 
>  
> 
> ARIN can use their discretion to determine if someone is abusing this 
> policy by submitting multiple reports with poor evidence of 
> abandonment.  This will result in a loss of claim to all reports 
> currently in progress by the perceived abuser  ARIN has the right to 
> reject investigation requests if they deem the reporting entity is 
> abusing the policy.
> 
>  
> 
> Addresses that are squatted and efficiently used will be granted amnesty 
> if the addresses are self reported, back billing is reconciled and any 
> applicable RSA is signed.  Partial returns and amnesty can be granted to 
> squatted addresses under this policy.
> 
>  
> 
>             *Management of abandoned number resources*
> 
> -ARIN will keep a Lost Property Office via a direct link from the main 
> ARIN website. 
> 
> -ARIN will publicly list all number resources that are reported 
> abandoned on the Lost Property Office site and the status of the 
> investigation.  Stats of recovered space through the abandoned number 
> resources will be provided bi-annually at the ARIN Members Meetings.
> 
> - ARIN will take measures to identify a chain of custody or successor in 
> interest to the last known POC.  If the successor is determined, the 
> block will be transferred to the successor under current ARIN policy. 
> 
> - If the number resources are not valid for transfer to the successor 
> and the original finder is not eligible to receive the number resources 
> then the block will be added back into the ARIN address pool for re-use.
> 
> -The original ?finder? is eligible for receipt of the addresses if they 
> are currently eligible per ARIN policy to receive more addresses and the 
> addresses are not transferred to a chain of custody that was discovered 
> during investigation.
> 
> - If an investigation reveals a successor who is unaware of their number 
> resources, ARIN can decide if there is good faith and sufficient 
> justification for the successor to keep the resources. Partial returns 
> and amnesty can be granted to sucessors for blocks revealed in and 
> investigation under this policy.
> 
> -Before ARIN re-uses allegedly abandoned resources ARIN will work with 
> ISP?s to route these resources no less than 90 days in order to validate 
> they are not in use.
> 
> -The original ?finder? will receive a ?finders? compensation for the 
> listing when either resolution occurs.  *For example a credit could be 
> put towards their annual fees.
> 
> -To report an abandoned block, send a request for investigation via the 
> Abandoned Block Template.
> 
>             *Examples of Abandoned number resources:*
> 
>             - Unused Legacy (e.g. swamp)
> 
>             -Business failure and the number resources are not currently 
> assigned nor in use.
> 
>             -Bad recordkeeping by an otherwise functional entity.
> 
>             -Squatted space that is not self reported.
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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 marla.azinger at frontiercorp.com  Fri Oct 17 14:58:48 2008
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Fri, 17 Oct 2008 14:58:48 -0400
Subject: [arin-ppml] Different Approach to the Transfer and Market
 issue- input requested
In-Reply-To: <48F8DE65.8080701@internap.com>
References: <2E2FECEBAE57CC4BAACDE67638305F1048140EF135@ROCH-EXCH1.corp.pvt>
	<48F8DE65.8080701@internap.com>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048140EFC85@ROCH-EXCH1.corp.pvt>

The current text has measures to address and discourage vigilantes.

Please clarify what your concern is regarding the squatter part so that we can discuss specifics.

Thank you for your input
Marla

-----Original Message-----
From: Scott Leibrand [mailto:sleibrand at internap.com]
Sent: Friday, October 17, 2008 11:50 AM
To: Azinger, Marla
Cc: ppml at arin.net; schiller at uu.net
Subject: Re: [arin-ppml] Different Approach to the Transfer and Market issue- input requested

I would oppose this if proposed as written.  I think it is dangerous to encourage vigilantes to get involved in reclamation efforts.  I am also concerned about the "squatter" language.

I think the direction we need to go on reclamation is to direct ARIN to find and reclaim netblocks registered to organizations who are no longer around, and aggressively reclaim resources involved in attempted fraud.  I don't think we need new policy there (beyond 2007-14).

-Scott

Azinger, Marla wrote:
> Hello-
>
> As promised here is an alternative proposal.  It has not officially
> been submitted in order to gain community feedback and revision before
> submitting.  Thank you everyone that has already shown interest in
> persuing this alternative approach.  Please be advised that this is a
> suggested new section to NRPM in addition to keeping the current
> section
> 4.6 Voluntary Partial Returns and Amnesty.
>
> If you are here at ARIN please find Marla Azinger or Jason schiller at
> the breaks to discuss.  Cheers!
>
> *Name: Active Reclamation of abandoned number resources*
>
>
> *Rational:*
>
> This policy addresses the following:
>
>    1. Find, reclaim and re-use unused number resources.
>    2. Give incentive to keep unused number resources out of the black
>       market.
>    3. Assist ARIN in cleaning up the database.
>    4. Provide an incentive to self identify and return unused resources.
>    5. Increase efficient utilization of ARIN number resources.
>    6. Help ease the transition to IPv6.
>    7. Help ensure fair re-distribution of resources to those who need them.
>
>
> *NRPM#: Active Reclamation of abandoned number resources*
>
> ARIN will actively investigate and ensure abandoned ARIN number
> resources including legacy resources that are under ARIN management
> are returned to the ARIN address pool for recirculation.  Any one may
> submit a report of abandonment for ARIN to investigate.  ARIN may
> investigate abandonment without a report when ARIN has reason to
> believe it has been abandoned.
>
>
>
> ARIN can use their discretion to determine if someone is abusing this
> policy by submitting multiple reports with poor evidence of
> abandonment.  This will result in a loss of claim to all reports
> currently in progress by the perceived abuser  ARIN has the right to
> reject investigation requests if they deem the reporting entity is
> abusing the policy.
>
>
>
> Addresses that are squatted and efficiently used will be granted
> amnesty if the addresses are self reported, back billing is reconciled
> and any applicable RSA is signed.  Partial returns and amnesty can be
> granted to squatted addresses under this policy.
>
>
>
>             *Management of abandoned number resources*
>
> -ARIN will keep a Lost Property Office via a direct link from the main
> ARIN website.
>
> -ARIN will publicly list all number resources that are reported
> abandoned on the Lost Property Office site and the status of the
> investigation.  Stats of recovered space through the abandoned number
> resources will be provided bi-annually at the ARIN Members Meetings.
>
> - ARIN will take measures to identify a chain of custody or successor
> in interest to the last known POC.  If the successor is determined,
> the block will be transferred to the successor under current ARIN policy.
>
> - If the number resources are not valid for transfer to the successor
> and the original finder is not eligible to receive the number
> resources then the block will be added back into the ARIN address pool for re-use.
>
> -The original "finder" is eligible for receipt of the addresses if
> they are currently eligible per ARIN policy to receive more addresses
> and the addresses are not transferred to a chain of custody that was
> discovered during investigation.
>
> - If an investigation reveals a successor who is unaware of their
> number resources, ARIN can decide if there is good faith and
> sufficient justification for the successor to keep the resources.
> Partial returns and amnesty can be granted to sucessors for blocks
> revealed in and investigation under this policy.
>
> -Before ARIN re-uses allegedly abandoned resources ARIN will work with
> ISP's to route these resources no less than 90 days in order to
> validate they are not in use.
>
> -The original "finder" will receive a "finders" compensation for the
> listing when either resolution occurs.  *For example a credit could be
> put towards their annual fees.
>
> -To report an abandoned block, send a request for investigation via
> the Abandoned Block Template.
>
>             *Examples of Abandoned number resources:*
>
>             - Unused Legacy (e.g. swamp)
>
>             -Business failure and the number resources are not
> currently assigned nor in use.
>
>             -Bad recordkeeping by an otherwise functional entity.
>
>             -Squatted space that is not self reported.
>
>
>
>
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> 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  Fri Oct 17 15:07:25 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Fri, 17 Oct 2008 12:07:25 -0700
Subject: [arin-ppml] Different Approach to the Transfer and Market
 issue- input requested
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048140EFC85@ROCH-EXCH1.corp.pvt>
References: <2E2FECEBAE57CC4BAACDE67638305F1048140EF135@ROCH-EXCH1.corp.pvt>
	<48F8DE65.8080701@internap.com>
	<2E2FECEBAE57CC4BAACDE67638305F1048140EFC85@ROCH-EXCH1.corp.pvt>
Message-ID: <48F8E26D.2040707@internap.com>

Azinger, Marla wrote:
> The current text has measures to address and discourage vigilantes.

I think this text, and other similar related sections, encourage 
vigilante-ism:

 >> -The original "finder" is eligible for receipt of the addresses if
 >> they are currently eligible per ARIN policy to receive more addresses
 >> and the addresses are not transferred to a chain of custody that was
 >> discovered during investigation.

> Please clarify what your concern is regarding the squatter part so that we can discuss specifics.

Firstly, the term "squatter" is undefined, and has a number of negative 
connotations.  For example:

 >> Addresses that are squatted and efficiently used will be granted
 >> amnesty if the addresses are self reported, back billing is reconciled
 >> and any applicable RSA is signed.  Partial returns and amnesty can be
 >> granted to squatted addresses under this policy.

This could be taken to mean that someone who has never been assigned a 
resource could start using it, thereby bypassing normal process.  Or, it 
could mean that we intent to start considering legacy holders to be 
squatters.  Either interpretation seems bad to me, and I'm not sure which 
is worse.

> Thank you for your input
> Marla

Thank you,
Scott

> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com]
> Sent: Friday, October 17, 2008 11:50 AM
> To: Azinger, Marla
> Cc: ppml at arin.net; schiller at uu.net
> Subject: Re: [arin-ppml] Different Approach to the Transfer and Market issue- input requested
> 
> I would oppose this if proposed as written.  I think it is dangerous to encourage vigilantes to get involved in reclamation efforts.  I am also concerned about the "squatter" language.
> 
> I think the direction we need to go on reclamation is to direct ARIN to find and reclaim netblocks registered to organizations who are no longer around, and aggressively reclaim resources involved in attempted fraud.  I don't think we need new policy there (beyond 2007-14).
> 
> -Scott
> 
> Azinger, Marla wrote:
>> Hello-
>>
>> As promised here is an alternative proposal.  It has not officially
>> been submitted in order to gain community feedback and revision before
>> submitting.  Thank you everyone that has already shown interest in
>> persuing this alternative approach.  Please be advised that this is a
>> suggested new section to NRPM in addition to keeping the current
>> section
>> 4.6 Voluntary Partial Returns and Amnesty.
>>
>> If you are here at ARIN please find Marla Azinger or Jason schiller at
>> the breaks to discuss.  Cheers!
>>
>> *Name: Active Reclamation of abandoned number resources*
>>
>>
>> *Rational:*
>>
>> This policy addresses the following:
>>
>>    1. Find, reclaim and re-use unused number resources.
>>    2. Give incentive to keep unused number resources out of the black
>>       market.
>>    3. Assist ARIN in cleaning up the database.
>>    4. Provide an incentive to self identify and return unused resources.
>>    5. Increase efficient utilization of ARIN number resources.
>>    6. Help ease the transition to IPv6.
>>    7. Help ensure fair re-distribution of resources to those who need them.
>>
>>
>> *NRPM#: Active Reclamation of abandoned number resources*
>>
>> ARIN will actively investigate and ensure abandoned ARIN number
>> resources including legacy resources that are under ARIN management
>> are returned to the ARIN address pool for recirculation.  Any one may
>> submit a report of abandonment for ARIN to investigate.  ARIN may
>> investigate abandonment without a report when ARIN has reason to
>> believe it has been abandoned.
>>
>>
>>
>> ARIN can use their discretion to determine if someone is abusing this
>> policy by submitting multiple reports with poor evidence of
>> abandonment.  This will result in a loss of claim to all reports
>> currently in progress by the perceived abuser  ARIN has the right to
>> reject investigation requests if they deem the reporting entity is
>> abusing the policy.
>>
>>
>>
>> Addresses that are squatted and efficiently used will be granted
>> amnesty if the addresses are self reported, back billing is reconciled
>> and any applicable RSA is signed.  Partial returns and amnesty can be
>> granted to squatted addresses under this policy.
>>
>>
>>
>>             *Management of abandoned number resources*
>>
>> -ARIN will keep a Lost Property Office via a direct link from the main
>> ARIN website.
>>
>> -ARIN will publicly list all number resources that are reported
>> abandoned on the Lost Property Office site and the status of the
>> investigation.  Stats of recovered space through the abandoned number
>> resources will be provided bi-annually at the ARIN Members Meetings.
>>
>> - ARIN will take measures to identify a chain of custody or successor
>> in interest to the last known POC.  If the successor is determined,
>> the block will be transferred to the successor under current ARIN policy.
>>
>> - If the number resources are not valid for transfer to the successor
>> and the original finder is not eligible to receive the number
>> resources then the block will be added back into the ARIN address pool for re-use.
>>
>> -The original "finder" is eligible for receipt of the addresses if
>> they are currently eligible per ARIN policy to receive more addresses
>> and the addresses are not transferred to a chain of custody that was
>> discovered during investigation.
>>
>> - If an investigation reveals a successor who is unaware of their
>> number resources, ARIN can decide if there is good faith and
>> sufficient justification for the successor to keep the resources.
>> Partial returns and amnesty can be granted to sucessors for blocks
>> revealed in and investigation under this policy.
>>
>> -Before ARIN re-uses allegedly abandoned resources ARIN will work with
>> ISP's to route these resources no less than 90 days in order to
>> validate they are not in use.
>>
>> -The original "finder" will receive a "finders" compensation for the
>> listing when either resolution occurs.  *For example a credit could be
>> put towards their annual fees.
>>
>> -To report an abandoned block, send a request for investigation via
>> the Abandoned Block Template.
>>
>>             *Examples of Abandoned number resources:*
>>
>>             - Unused Legacy (e.g. swamp)
>>
>>             -Business failure and the number resources are not
>> currently assigned nor in use.
>>
>>             -Bad recordkeeping by an otherwise functional entity.
>>
>>             -Squatted space that is not self reported.
>>
>>
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> 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  Sat Oct 18 17:01:17 2008
From: vixie at isc.org (Paul Vixie)
Date: Sat, 18 Oct 2008 21:01:17 +0000
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
Message-ID: <36790.1224363677@nsa.vix.com>

"The most comprehensive scan of the entire internet for several decades
shows that millions of allocated addresses simply aren't being
used. Professor John Heidemann from the University of Southern California
(USC) used ICMP and TCP to scan the internet. Even though the last IPv4
addresses will be handed out in a couple of years, his survey reveals that
many of the addresses allocated to big companies and institutions are lying
idle. Heidemann says: 'People are very concerned that the IPv4 address
space is very close to being exhausted. Our data suggests that maybe there
are better things we should be doing in managing the IPv4 address space.'
So, is it time to reclaim those unused addresses before the IPv6 crunch?"

http://tech.slashdot.org/article.pl?sid=08/10/15/1659244


From bicknell at ufp.org  Sat Oct 18 17:22:39 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Sat, 18 Oct 2008 17:22:39 -0400
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <36790.1224363677@nsa.vix.com>
References: <36790.1224363677@nsa.vix.com>
Message-ID: <20081018212239.GA38332@ussenterprise.ufp.org>

In a message written on Sat, Oct 18, 2008 at 09:01:17PM +0000, Paul Vixie wrote:
> "The most comprehensive scan of the entire internet for several decades
> shows that millions of allocated addresses simply aren't being
> used. Professor John Heidemann from the University of Southern California

Unfortunately while I might even give him that this is the most
comprehensive, I believe there are more than a few severe holes in
it that mean it may not be representative.

A large problem is that many hosts will not respond to unsolicited
ICMP, TCP, or other packets.  Indeed, many hosts today are protected
by multiple levels of this, service providers helpfully dropping
some packets before a organization based firewall dropping some
more, followed by a host based firewall dropping the rest.  I have
no doubt that millions of computers were missed as a result.

However, the larger problem is that this is the entirely wrong
definition of "in use".  Let's take a simple example of a University.
They may have wired dorm rooms, students with laptops, and wifi
enabled classrooms.  If you ping at 11AM, the classroom IP's respond,
and the dorm ones do not, if you ping at 11PM, the dorm rooms
respond, the classrooms do not.  And if you ping at 12 noon when
they are all walking to lunch almost none of either respond.

This survey equates in use to be having a computer actively using
it and responding at the time of the probe.  I would submit that
is a very poor definition.  The dorm room block and classroom blocks
are both "in use" every day, and unfortunately the technology
involved does not make it possible to move back and forth.

In fact, the interesting thing to do here is simple.  Cross reference
the "pingable" IP's in a block of space with requests over the past
month to google, or akamai, or updates.microsoft.com and see what
percentage of the "unpingable" IP's are in fact in use on a regular
basis.  We could haggle over if "in use" means active in the last
day, week, or month, if it really matters.

A pretty chart for sure; in terms of being helpful for planning the
future, it's borderline chart junk.

-- 
       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/20081018/f5f80125/attachment.sig>

From BillD at cait.wustl.edu  Sat Oct 18 18:12:13 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Sat, 18 Oct 2008 17:12:13 -0500
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>


But like many political statements....it's not necessarily the substance that is important.
This spark, if fanned could be an opening to do reclaimation...not that I am in favor of this, but it would preserve the status quo.



-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Leo Bicknell
Sent: Sat 10/18/2008 4:22 PM
To: ppml at arin.net
Subject: Re: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"(slashdot)
 
In a message written on Sat, Oct 18, 2008 at 09:01:17PM +0000, Paul Vixie wrote:
> "The most comprehensive scan of the entire internet for several decades
> shows that millions of allocated addresses simply aren't being
> used. Professor John Heidemann from the University of Southern California

Unfortunately while I might even give him that this is the most
comprehensive, I believe there are more than a few severe holes in
it that mean it may not be representative.

A large problem is that many hosts will not respond to unsolicited
ICMP, TCP, or other packets.  Indeed, many hosts today are protected
by multiple levels of this, service providers helpfully dropping
some packets before a organization based firewall dropping some
more, followed by a host based firewall dropping the rest.  I have
no doubt that millions of computers were missed as a result.

However, the larger problem is that this is the entirely wrong
definition of "in use".  Let's take a simple example of a University.
They may have wired dorm rooms, students with laptops, and wifi
enabled classrooms.  If you ping at 11AM, the classroom IP's respond,
and the dorm ones do not, if you ping at 11PM, the dorm rooms
respond, the classrooms do not.  And if you ping at 12 noon when
they are all walking to lunch almost none of either respond.

This survey equates in use to be having a computer actively using
it and responding at the time of the probe.  I would submit that
is a very poor definition.  The dorm room block and classroom blocks
are both "in use" every day, and unfortunately the technology
involved does not make it possible to move back and forth.

In fact, the interesting thing to do here is simple.  Cross reference
the "pingable" IP's in a block of space with requests over the past
month to google, or akamai, or updates.microsoft.com and see what
percentage of the "unpingable" IP's are in fact in use on a regular
basis.  We could haggle over if "in use" means active in the last
day, week, or month, if it really matters.

A pretty chart for sure; in terms of being helpful for planning the
future, it's borderline chart junk.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/

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

From randy at psg.com  Sat Oct 18 18:22:53 2008
From: randy at psg.com (Randy Bush)
Date: Sat, 18 Oct 2008 15:22:53 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>
References: <36790.1224363677@nsa.vix.com>	<20081018212239.GA38332@ussenterprise.ufp.org>
	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>
Message-ID: <48FA61BD.8050302@psg.com>

> not that I am in favor of this, but it would preserve the status quo.

guys, get over it.  *nothing* will preserve the status quo.  there is a
serious brick wall looming in the headlights.

randy


From bruce.eastman at twcable.com  Sat Oct 18 19:21:25 2008
From: bruce.eastman at twcable.com (Eastman, Bruce)
Date: Sat, 18 Oct 2008 19:21:25 -0400
Subject: [arin-ppml] "Millions of Internet Addresses
	AreLying	Idle"(slashdot)
In-Reply-To: <48FA61BD.8050302@psg.com>
Message-ID: <82665B12B693474481A2A69504DD6F5D0B20D872@PRVPVSMAIL06.corp.twcable.com>


>> not that I am in favor of this, but it would preserve the status quo.

>guys, get over it.  *nothing* will preserve the status quo.  there is a
>serious brick wall looming in the headlights.

>randy


Yes, and unfortunately, the bricks in that wall are made out of a shiny,
dense alloy, popular with certain individuals/organizations that know
what they are sitting on. I am not saying that Professor John
Heidemann's scan is entirely accurate, but I will bet you one of those
bricks, that when IPV4 is depleted, you will see a lot of space that is
suddenly free------for the right amount of bricks.


Bruce Eastman
IP Capacity Engineer




This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.



From michael at rancid.berkeley.edu  Sat Oct 18 19:05:02 2008
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Sat, 18 Oct 2008 16:05:02 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"	(slashdot)
In-Reply-To: <20081018212239.GA38332@ussenterprise.ufp.org>
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
Message-ID: <48FA6B9E.3080908@rancid.berkeley.edu>

On 10/18/08 2:22 PM, Leo Bicknell wrote:
> In a message written on Sat, Oct 18, 2008 at 09:01:17PM +0000, Paul Vixie wrote:
>> "The most comprehensive scan of the entire internet for several decades
>> shows that millions of allocated addresses simply aren't being
>> used. Professor John Heidemann from the University of Southern California
> 
> Unfortunately while I might even give him that this is the most
> comprehensive, I believe there are more than a few severe holes in
> it that mean it may not be representative.
> 
> A large problem is that many hosts will not respond to unsolicited
> ICMP, TCP, or other packets.

[snip]

I am seriously concerned about drawing any sort of conclusion from an 
study that has methodological holes like this.  Here's some language 
from the Technology Review article that sets off alarm bells for me:

> Sending an ICMP packet to another host (an action known as pinging) is generally not seen as hostile, Heidemann says. "There are certainly people who misunderstand what we are doing," and interpret it as the prelude to an attack, he says. "By request, we remove them from the survey, but its fewer people than you might think. Pings are pretty innocuous."

It is my experience that people who are clueful enough to understand 
what ICMP does and that blocking ICMP often does more harm than good are 
a serious minority, especially when it comes to the population of people 
who run firewalls.  While I might agree with the notion that ICMP is 
innocuous, attributing that view to the rest of the networking and 
security community is dangerously deceptive.  It makes it sound as if 
most people let ICMP flow freely across borders when I think our 
experiences with network troubleshooting and PMTUD show otherwise.  If 
you contradict the assumption that ICMP is recognized as benign and 
treated as such by firewall admins, much of the *article's* conclusion 
goes out the window.

My *quick* reading of the study itself indicates to me that the study 
tries hard not to draw conclusions about address scarcity from the 
results.  (IPv6 is mentioned only once, and in passing.)  It appears to 
me (and from comments posted by one of the authors) that Technology 
Review played fast-and-loose with the study and drew conclusions that 
weren't there.

michael


From tvest at pch.net  Sat Oct 18 20:31:29 2008
From: tvest at pch.net (Tom Vest)
Date: Sat, 18 Oct 2008 17:31:29 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <48FA61BD.8050302@psg.com>
References: <36790.1224363677@nsa.vix.com>	<20081018212239.GA38332@ussenterprise.ufp.org>
	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>
	<48FA61BD.8050302@psg.com>
Message-ID: <EA40692E-2619-4F7B-863B-099361E3DFB8@pch.net>

Yes there is a brick wall looming in the headlights.
There are a lot of passengers along for the ride.
Even if the driver jumps out of the car just in time, the net  
"outcome" (i.e., tragedy) will be about the same.

A wise driver might consider braking and turning instead....

TV

On Oct 18, 2008, at 3:22 PM, Randy Bush wrote:

>> not that I am in favor of this, but it would preserve the status quo.
>
> guys, get over it.  *nothing* will preserve the status quo.  there  
> is a
> serious brick wall looming in the headlights.
>
> 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.



From rsena at mitre.org  Sat Oct 18 20:36:44 2008
From: rsena at mitre.org (Sena, Rich)
Date: Sat, 18 Oct 2008 20:36:44 -0400
Subject: [arin-ppml] "Millions of Internet Addresses
	Are	Lying	Idle"(slashdot)
Message-ID: <B473C76B9C857542A758DF792F159DF207B6016C74@IMCMBX1.MITRE.ORG>

Or he might try flying instead of driving - it is after all actually statistically safer as well as a faster more modern approach for getting from point A to point B... Although a horse and buggy might work too but you have to deal with all the crap and flies...
--
via the Blackberry Xpress!

----- Original Message -----
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
To: Randy Bush <randy at psg.com>
Cc: ppml at arin.net <ppml at arin.net>; Bill Darte <BillD at cait.wustl.edu>
Sent: Sat Oct 18 20:31:29 2008
Subject: Re: [arin-ppml] "Millions of Internet Addresses Are    Lying   Idle"(slashdot)

Yes there is a brick wall looming in the headlights.
There are a lot of passengers along for the ride.
Even if the driver jumps out of the car just in time, the net
"outcome" (i.e., tragedy) will be about the same.

A wise driver might consider braking and turning instead....

TV

On Oct 18, 2008, at 3:22 PM, Randy Bush wrote:

>> not that I am in favor of this, but it would preserve the status quo.
>
> guys, get over it.  *nothing* will preserve the status quo.  there
> is a
> serious brick wall looming in the headlights.
>
> 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.

_______________________________________________
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 rsena at mitre.org  Sat Oct 18 19:58:35 2008
From: rsena at mitre.org (Sena, Rich)
Date: Sat, 18 Oct 2008 19:58:35 -0400
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"	(slashdot)
Message-ID: <B473C76B9C857542A758DF792F159DF207B6016C73@IMCMBX1.MITRE.ORG>

I agree with Leo - studies like this do nothing but agitate the uninformed - 90+% of our space is unreachable in anyway shape or form from the outside - now folks may argue - whay don't you NAT - and some of my responses would be spurious - the simplest answer would be my routing policy dictates our need - we have high security stakes and althought there are ways to mitigate and redirect tthe policy - none of them are low impact on our community and some are high impact on our work programs.

We're pushing to go v6 and hoping to avoid some some of the legacy chains that make it so difficult for us to return lefacy resources in the future...

God help us!
--
via the Blackberry Xpress!

----- Original Message -----
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
To: ppml at arin.net <ppml at arin.net>
Sent: Sat Oct 18 19:05:02 2008
Subject: Re: [arin-ppml] "Millions of Internet Addresses Are Lying      Idle"   (slashdot)

On 10/18/08 2:22 PM, Leo Bicknell wrote:
> In a message written on Sat, Oct 18, 2008 at 09:01:17PM +0000, Paul Vixie wrote:
>> "The most comprehensive scan of the entire internet for several decades
>> shows that millions of allocated addresses simply aren't being
>> used. Professor John Heidemann from the University of Southern California
>
> Unfortunately while I might even give him that this is the most
> comprehensive, I believe there are more than a few severe holes in
> it that mean it may not be representative.
>
> A large problem is that many hosts will not respond to unsolicited
> ICMP, TCP, or other packets.

[snip]

I am seriously concerned about drawing any sort of conclusion from an
study that has methodological holes like this.  Here's some language
from the Technology Review article that sets off alarm bells for me:

> Sending an ICMP packet to another host (an action known as pinging) is generally not seen as hostile, Heidemann says. "There are certainly people who misunderstand what we are doing," and interpret it as the prelude to an attack, he says. "By request, we remove them from the survey, but its fewer people than you might think. Pings are pretty innocuous."

It is my experience that people who are clueful enough to understand
what ICMP does and that blocking ICMP often does more harm than good are
a serious minority, especially when it comes to the population of people
who run firewalls.  While I might agree with the notion that ICMP is
innocuous, attributing that view to the rest of the networking and
security community is dangerously deceptive.  It makes it sound as if
most people let ICMP flow freely across borders when I think our
experiences with network troubleshooting and PMTUD show otherwise.  If
you contradict the assumption that ICMP is recognized as benign and
treated as such by firewall admins, much of the *article's* conclusion
goes out the window.

My *quick* reading of the study itself indicates to me that the study
tries hard not to draw conclusions about address scarcity from the
results.  (IPv6 is mentioned only once, and in passing.)  It appears to
me (and from comments posted by one of the authors) that Technology
Review played fast-and-loose with the study and drew conclusions that
weren't there.

michael
_______________________________________________
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 Oct 19 11:51:04 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sun, 19 Oct 2008 15:51:04 +0000
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <36790.1224363677@nsa.vix.com>
References: <36790.1224363677@nsa.vix.com>
Message-ID: <20081019155104.GA23549@vacation.karoshi.com.>



Johns analysis is based on the premise that nodes respond to an
ICMP echo request or the TCP equivalent.  That might temper ones
expectations or presumptions about allocated but fallow data.

--bill


On Sat, Oct 18, 2008 at 09:01:17PM +0000, Paul Vixie wrote:
> "The most comprehensive scan of the entire internet for several decades
> shows that millions of allocated addresses simply aren't being
> used. Professor John Heidemann from the University of Southern California
> (USC) used ICMP and TCP to scan the internet. Even though the last IPv4
> addresses will be handed out in a couple of years, his survey reveals that
> many of the addresses allocated to big companies and institutions are lying
> idle. Heidemann says: 'People are very concerned that the IPv4 address
> space is very close to being exhausted. Our data suggests that maybe there
> are better things we should be doing in managing the IPv4 address space.'
> So, is it time to reclaim those unused addresses before the IPv6 crunch?"
> 
> http://tech.slashdot.org/article.pl?sid=08/10/15/1659244
> _______________________________________________
> 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 Oct 19 11:55:16 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sun, 19 Oct 2008 15:55:16 +0000
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <20081018212239.GA38332@ussenterprise.ufp.org>
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
Message-ID: <20081019155516.GB23549@vacation.karoshi.com.>

> However, the larger problem is that this is the entirely wrong
> definition of "in use".  Let's take a simple example of a University.
> They may have wired dorm rooms, students with laptops, and wifi
> enabled classrooms.  If you ping at 11AM, the classroom IP's respond,
> and the dorm ones do not, if you ping at 11PM, the dorm rooms
> respond, the classrooms do not.  And if you ping at 12 noon when
> they are all walking to lunch almost none of either respond.
> 
> This survey equates in use to be having a computer actively using
> it and responding at the time of the probe.  I would submit that
> is a very poor definition.  The dorm room block and classroom blocks
> are both "in use" every day, and unfortunately the technology
> involved does not make it possible to move back and forth.


	actually, the methodology used does address this concern.
	there are multiple probes over time.  firewalls and NAT
	are problematic in this study.

--bill


From vixie at isc.org  Sun Oct 19 13:21:56 2008
From: vixie at isc.org (Paul Vixie)
Date: Sun, 19 Oct 2008 17:21:56 +0000
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: Your message of "Sun, 19 Oct 2008 15:51:04 GMT."
	<20081019155104.GA23549@vacation.karoshi.com.> 
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.> 
Message-ID: <77143.1224436916@nsa.vix.com>

> Johns analysis is based on the premise that nodes respond to an
> ICMP echo request or the TCP equivalent.  That might temper ones
> expectations or presumptions about allocated but fallow data.
> 
> --bill

don't shoot the messenger, i found the article relevant since it touched
on reclaimation policy, even though i found the study itself irrelevant
since the RIR system and RFC2050 do not require connectedness for "need".

but it begs an interesting series of questions.  if "need" were redefined
to include connectedness, how much space would become "unneeded", how long
would that last in terms of randy's gold brick wall, and what legal regime
would apply since we can presume that most "unconnected" space is probably
legacy.  my personal suspicions are that the amount of space that would
become unneeded could push the brick wall back by more than two years, but
there's no way to define "connected" since there are so many private
interconnects between defaultless networks (and it's easy to connect a
network if it'd mean somebody keeping rights to their ip space).


From bmanning at vacation.karoshi.com  Sun Oct 19 18:09:52 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Sun, 19 Oct 2008 22:09:52 +0000
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <77143.1224436916@nsa.vix.com>
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
Message-ID: <20081019220952.GA25658@vacation.karoshi.com.>

On Sun, Oct 19, 2008 at 05:21:56PM +0000, Paul Vixie wrote:
> > Johns analysis is based on the premise that nodes respond to an
> > ICMP echo request or the TCP equivalent.  That might temper ones
> > expectations or presumptions about allocated but fallow data.
> > 
> > --bill
> 
> don't shoot the messenger, i found the article relevant since it touched
> on reclaimation policy, even though i found the study itself irrelevant
> since the RIR system and RFC2050 do not require connectedness for "need".
> 
> but it begs an interesting series of questions.  if "need" were redefined
> to include connectedness, how much space would become "unneeded", how long
> would that last in terms of randy's gold brick wall, and what legal regime
> would apply since we can presume that most "unconnected" space is probably
> legacy.  my personal suspicions are that the amount of space that would
> become unneeded could push the brick wall back by more than two years, but
> there's no way to define "connected" since there are so many private
> interconnects between defaultless networks (and it's easy to connect a
> network if it'd mean somebody keeping rights to their ip space).

	connected to whom indeed.
	connected != "in-use"

	second guessing "when" is counter productive.
	for all intents, we are already grappling w/ how
	to deal w/ a steady-state system where we need to be
	able to move IPv4 resources around.  we are in the 
	end-times and for some of us, we have already hit
	the brick wall.  

	even if a couple dozen /8's reenter the playing field,
	we are -never- going to back to status quo (to borrow
	friend bushes phrasology).   like it or not, we are
	in a situation where we have to deal w/ steady state
	in the v4 world.

--bill


From gih at apnic.net  Sun Oct 19 21:08:21 2008
From: gih at apnic.net (Geoff Huston)
Date: Mon, 20 Oct 2008 12:08:21 +1100
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
Message-ID: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>

Hi,

At the ARIN meeting last week the question arose as to why the various  
policy proposals related to address transfers in the different RIRs  
were so different. I made some comments in response to this question  
from my perspective and then I had some followup questions mailed to  
me, so I thought maybe there is some value in writing up from my  
perspective. After all there is still some difference between the  
proposal(s) before ARIN and Proposal-50 before APNIC, and  the  
question as to why this difference exists is an interesting one.

If you are interested its at: http://www.potaroo.net/ispcol/2008-11/transfers.html

thanks,

    Geoff Huston

    DIsclaimer: I'm speaking for myself, again!


  
   


From sleibrand at internap.com  Sun Oct 19 21:47:46 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Sun, 19 Oct 2008 18:47:46 -0700
Subject: [arin-ppml] Some observations on the differences in the various
 transfer policy proposals
In-Reply-To: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
Message-ID: <48FBE342.8020403@internap.com>

Geoff,

In your article you imply that the RIRs' registry functions are not the 
proper lever from which to apply the various regulatory functions that the 
community has indicated are needed.  Where/how would you propose the 
regulatory function reside / be applied instead?

Or, to put a more practical face on the same question: how do you propose 
that the industry deal with the deaggregation that will result from the 
widespread transfer of small netblocks (as allowed under prop-50)?

I agree that restricting deaggregation through regulating access to the 
registry will not be 100% effective, but it seems more likely to be 
effective than any alternative I've seen so far.

Thanks,
Scott

Geoff Huston wrote:
> Hi,
> 
> At the ARIN meeting last week the question arose as to why the various  
> policy proposals related to address transfers in the different RIRs  
> were so different. I made some comments in response to this question  
> from my perspective and then I had some followup questions mailed to  
> me, so I thought maybe there is some value in writing up from my  
> perspective. After all there is still some difference between the  
> proposal(s) before ARIN and Proposal-50 before APNIC, and  the  
> question as to why this difference exists is an interesting one.
> 
> If you are interested its at: http://www.potaroo.net/ispcol/2008-11/transfers.html
> 
> thanks,
> 
>     Geoff Huston
> 
>     DIsclaimer: I'm speaking for myself, again!
> 
> 
>   
>    
> _______________________________________________
> 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 gih at apnic.net  Sun Oct 19 22:24:53 2008
From: gih at apnic.net (Geoff Huston)
Date: Mon, 20 Oct 2008 13:24:53 +1100
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
References: <48FBE342.8020403@internap.com>
	<6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
Message-ID: <E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>

Hi Scott,

>> In your article you imply that the RIRs' registry functions are not  
>> the
>> proper lever from which to apply the various regulatory functions  
>> that the
>> community has indicated are needed.  Where/how would you propose the
>> regulatory function reside / be applied instead?
>>

Again, the real question is, MUST the RIRs have an answer for  
_everything_? Must the RIR's devise complex procedures that attempt to  
counter particular behaviours,  at the common community cost of more  
onerous procedures with higher overheads. And without any practical  
enforcement mechanism why will others even listen to the RIRs?

To quote from the article:

"But the observation should be made that markets in all manner of good  
and services have a rich history in human societies, and the role of  
the regulator is similarly one with a rich history. Market regulators  
exist in many guises and in many regimes, and can exert influence  
through various direct and indirect means. There is no need to believe  
that this issue of transfers and address markets requires a  
comprehensive solution based solely on the resources, capability,  
authority and enforcement authority of the RIR's. Once the RIR's are  
no longer address allocation entities much of their ability to enforce  
certain behaviours goes with that role, and the residual role, that of  
operation of an address registry, necessarily has to take a more  
neutral stance if it is to be a role that is discharged effectively."




>> Or, to put a more practical face on the same question: how do you  
>> propose
>> that the industry deal with the deaggregation that will result from  
>> the
>> widespread transfer of small netblocks (as allowed under prop-50)?
>>


Thats a very good example, because deaggregation in the address space  
has been a constant factor for decades. i.e. if enforcing strong  
aggregation in the routing space was a metric of success of the policy  
framework associated with allocation, then the metrics of the routing  
system over the past 10 years would have to assign a failing grade here.

Again, to quote from the article:

"However, fragmentation of the routing space has not been directly  
linked to the further allocation function, and the results of this  
decoupling of policy with a risk of any negative outcome is clearly  
evident in the continuing fragmentation observed in the routing space."

So, no, I don't think that any transfer policy proposal will do any  
better than the allocation policy framework, and the allocation policy  
framework has been, on the whole, ineffectual.


>> I agree that restricting deaggregation through regulating access to  
>> the
>> registry will not be 100% effective, but it seems more likely to be
>> effective than any alternative I've seen so far.
>>

Well with no successful practical experience to call upon so far, I  
suppose that we can all have a guess at what an effective policy may  
be in this area.

regards,

    Geoff







From ppml at rs.seastrom.com  Sun Oct 19 22:28:36 2008
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Sun, 19 Oct 2008 22:28:36 -0400
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <48FA61BD.8050302@psg.com> (Randy Bush's message of "Sat,
	18 Oct 2008 15:22:53 -0700")
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>
	<48FA61BD.8050302@psg.com>
Message-ID: <868wskuhij.fsf@seastrom.com>


Randy Bush <randy at psg.com> writes:

>> not that I am in favor of this, but it would preserve the status quo.
>
> guys, get over it.  *nothing* will preserve the status quo.  there is a
> serious brick wall looming in the headlights.

the status quo is that there is an impending train wreck which is not
being adequately addressed.

reclamation would preserve this status quo and give some people a
false sense of security.

-r




From sleibrand at internap.com  Sun Oct 19 23:14:21 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Sun, 19 Oct 2008 20:14:21 -0700
Subject: [arin-ppml] Prop-50 and the differences in the various transfer
	policy proposals
In-Reply-To: <E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
References: <48FBE342.8020403@internap.com>
	<6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
	<E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
Message-ID: <48FBF78D.4070501@internap.com>

[Cc'ing prop-50 discussion to sig-policy.]

Geoff Huston wrote:
> Hi Scott,
> 
>>> In your article you imply that the RIRs' registry functions are not the
>>> proper lever from which to apply the various regulatory functions 
>>> that the
>>> community has indicated are needed.  Where/how would you propose the
>>> regulatory function reside / be applied instead?
>>>
> 
> Again, the real question is, MUST the RIRs have an answer for 
> _everything_? Must the RIR's devise complex procedures that attempt to 
> counter particular behaviours,  at the common community cost of more 
> onerous procedures with higher overheads. And without any practical 
> enforcement mechanism why will others even listen to the RIRs?

I understand that the RIRs don't have to do this.  I'm asking who else (or 
what other set of distributed incentives and emergent properties) should 
do it instead.

If no one / nothing else can do it, and it needs done, maybe we should 
try.  If you think APNIC can't do so for whatever reason, I still think 
ARIN could (and should) for the ARIN region.

>>> Or, to put a more practical face on the same question: how do you 
>>> propose
>>> that the industry deal with the deaggregation that will result from the
>>> widespread transfer of small netblocks (as allowed under prop-50)?
> 
> Thats a very good example, because deaggregation in the address space 
> has been a constant factor for decades. i.e. if enforcing strong 
> aggregation in the routing space was a metric of success of the policy 
> framework associated with allocation, then the metrics of the routing 
> system over the past 10 years would have to assign a failing grade here.

I would argue that current levels of deaggregation have not yet posed 
undue burden on default-free operators, and based on that, the 
historical/current level of routing table growth is manageable.  I am 
therefore only talking about attempting to provide sufficient incentive to 
maintain the current "weak" level of aggregation.

> Again, to quote from the article:
> 
> "However, fragmentation of the routing space has not been directly 
> linked to the further allocation function, and the results of this 
> decoupling of policy with a risk of any negative outcome is clearly 
> evident in the continuing fragmentation observed in the routing space."
> 
> So, no, I don't think that any transfer policy proposal will do any 
> better than the allocation policy framework, and the allocation policy 
> framework has been, on the whole, ineffectual.

I agree that we can't do any better than we do today.  However, we can do 
a lot worse, and likely will under prop-50.

For example, consider two requests from two different organizations, the 
first for a /16 and the second for a /18.  Today, that is obviously two 
allocations and two new routes in the DFZ.  Now consider what happens in a 
simplified transfer market where the supply consists of five discontiguous 
/18s and a /16, with the /18s priced at $1000 each and the /16 at $5000.

Under prop-50, the first organization will get four discontiguous /18s for 
$4000 (passing up the intact /16 at $5000).  The second will get the fifth 
/18 for $1000.  In the end, that means that we will have 4+1=5 new routes 
in the table.

Under an RIR-regulated transfer market, however, the first organization 
would be required to get a contiguous /16, for $5000.  The /18 would still 
be a /18, so that would be 2 new routes in the table.

As you can see from the example above, or from a more general application 
of economic principles to the likely supply and demand of a transfer 
market, constraining the recipient of space under transfer to receiving 
only a single block large enough to meet their needs approximately 
preserves the current rate of routing table growth.  However, moving to a 
transfer policy like prop-50 results in an increase in the rate of routing 
table growth.

-Scott


From vixie at isc.org  Mon Oct 20 00:43:02 2008
From: vixie at isc.org (Paul Vixie)
Date: Mon, 20 Oct 2008 04:43:02 +0000
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: Your message of "Sun, 19 Oct 2008 22:09:52 GMT."
	<20081019220952.GA25658@vacation.karoshi.com.> 
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<20081019220952.GA25658@vacation.karoshi.com.> 
Message-ID: <43281.1224477782@nsa.vix.com>

> 	even if a couple dozen /8's reenter the playing field,
> 	we are -never- going to back to status quo (to borrow
> 	friend bushes phrasology).   like it or not, we are
> 	in a situation where we have to deal w/ steady state
> 	in the v4 world.

steady state could mean no growth but nobody is saying that.  it could also
mean a universally addressed core with ambiguously addressed edge networks
and double/triple NAT and ALG gluing it all together.  some are saying that.
finally, it could mean universally addressed IPv6 everywhere, after a period
of transition where growth slows or comes in the form of double/triple NAT.

i'm accepting of your assertion "have to deal w/ steady state v4".  but i'm
pondering the possible implications of that steady state.  some authors of
"relaxed transfer" policy proposals describe their endgame, but some do not.


From tvest at pch.net  Mon Oct 20 02:03:00 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 20 Oct 2008 02:03:00 -0400
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
References: <48FBE342.8020403@internap.com>
	<6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
	<E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
Message-ID: <918C41F9-03AF-418E-A853-E19DCE18E023@pch.net>

Geoff, IMHO, you're simply off base here, both in your specific  
recommendations, and in your claim that there is no relevant  
experience base.

I happen to believe that you've been absolutely true to your  
convictions since RFC 1744. And I recognize that your convictions (if  
RFC 1744 is any guide), or at least your concrete recommendations  
since then, have a solid, principled foundation in libertarian "free  
banking" theories (for those interested, see references below). But  
the fact remains, every time that such theories have been put into  
practice they have failed absolutely, resulting in the imposition of  
national partitioning of markets and regulatory structures, if not  
outright nationalization/operation of the affected industries. There  
is no reason to doubt that anything other than that will result from  
the course of action you're advocating, and numerous specific and  
likely reasons/paths that would lead precisely to that outcome.

One might observe that commercial behavior under the RIR "system" is  
quite a bit like commercial behavior in other sectors where law is  
slack, regulations are mostly post-facto, and commercial transactions  
are largely invisible. Banks are the perfect example. Just like the  
RIRs, the central banks/bank regulators exercise a fair amount of  
control at the time of "bank establishment," when capitalization  
requirements (or in our case, determination of "need" as defined by  
the community) are established. That moment of power itself doesn't  
constrain subsequent bank behavior, however. All it does is establish  
the qualifications of new entrants. However, those qualifications and  
that evaluation process directly determines the bona fides /  
population / rate of population growth of commercial entities that  
will subsequently enjoy substantial power and broad discretion to do  
business in ways directly affect the overall structure of the economy.

Banks perform a critical role in creating liquidity in the monetary  
economy, but if they lend too profligately (e.g., to attract customers  
that might otherwise go to competitors), inflation will result; or  
lend too miserly (e.g., out of uncertainty or a belief that returns  
will be higher at some time in the future), and deflation sets in.  
Commercial operators in our world are in this sense identical. They  
face the same competitive pressures, and the same incentives to  
distribute resources in ways that, in the aggregate, would cause the  
whole "network economy" to collapse -- or more likely to self- 
partition itself into smaller, mutually isolated domains for self- 
preservation.

In both spheres, self-maintenance structures evolved over time to help  
mitigate the risks that those perverse incentives create, but in both  
worlds those mechanisms are neither omnipotent nor omniscient nor  
infallible. In both spheres, the basic rules preserve an open  
industry, which is supposed to guarantees a level of continuing  
competition that should make the system(s) deliver the things that  
make markets good -- i.e., expanding choice, innovation, an ever- 
improving mix of quantity-quality-price, etc. When they are not  
intentionally closing their eyes, central banks and bank regulators  
also tend to impose additional "reserve requirements" to discourage  
profligate lending, and to require all kinds of periodic reporting in  
an attempt to detect problems before they become catastrophic. We have  
our own reserve rules too -- albeit max. reserve restrictions rather  
than the min. reserve requirements -- and our own limited form of  
reporting, which is mostly tied to subsequent allocations and annual  
membership renewals. For either sphere to endure for long, however,  
the gap between these relatively weak, indirect forms of governance  
and the kind of absolute, all-pervasive iron grip that would be  
required to completely deter system-wide failure from inflation and/or  
deflation -- or routing table "bloat" and/or address hoarding in our  
case -- can only be bridged by the prudence of individual commercial  
operators themselves.

About a century ago, several countries (yours and mine included) went  
through periods when, in place of a central bank, a private consortium  
of commercial operators (aka "bankers' club") administered a kind of  
industry self-governance system of their own. Ultimately these "free  
banking" arrangements all failed (often during times of crisis like  
the one we're now facing), and were displaced by more conventional  
sovereign-backed central banks. Today once again, banks appear to most  
people to have failed to manage themselves, even in the presence of  
central bank regulation. Regardless of the actual causes, I predict  
that financial services providers are a lot more likely to be seeing  
more of that iron grip in the months and years to come than they are  
to receive a renewed mandate to work matters out between themselves.  
The same will happen to our industry too unless we continue  
successfully managing those same systemic risks, as we have been for  
the last decade-plus -- and do so *without* sacrificing any of the  
other engineering-orthogonal values (e.g., industry openness and  
transparency) that have made the rest of the world believe that  
Internet self-governance has been successful.

IPv4 is rapidly dwindling, just as in the past the supply of other  
materials that were essential to the continued functioning of the  
global economy became too scarce to support continued growth. There's  
no denying the need to retool, but the Internet is just as much a  
"critical infrastructure" today as is than the global banking system.  
Industry-led solutions that attempt to buy technical scalability at  
the expense of openness and transparency cannot work -- but even if  
they could they would not stand.

IMHO only,
TV

http://en.wikipedia.org/wiki/Free_banking
http://www.eyeconomics.com/backstage/Presentations/Pages/Bankers_for_BGP_v1.2.html
http://www.eyeconomics.com/backstage/NetStagflationPaper.html
(plus I have lots of related journal articles for the true insomniacs  
and work-deprived)

On Oct 19, 2008, at 10:24 PM, Geoff Huston wrote:

> Hi Scott,
>
>>> In your article you imply that the RIRs' registry functions are not
>>> the
>>> proper lever from which to apply the various regulatory functions
>>> that the
>>> community has indicated are needed.  Where/how would you propose the
>>> regulatory function reside / be applied instead?
>>>
>
> Again, the real question is, MUST the RIRs have an answer for
> _everything_? Must the RIR's devise complex procedures that attempt to
> counter particular behaviours,  at the common community cost of more
> onerous procedures with higher overheads. And without any practical
> enforcement mechanism why will others even listen to the RIRs?
>
> To quote from the article:
>
> "But the observation should be made that markets in all manner of good
> and services have a rich history in human societies, and the role of
> the regulator is similarly one with a rich history. Market regulators
> exist in many guises and in many regimes, and can exert influence
> through various direct and indirect means. There is no need to believe
> that this issue of transfers and address markets requires a
> comprehensive solution based solely on the resources, capability,
> authority and enforcement authority of the RIR's. Once the RIR's are
> no longer address allocation entities much of their ability to enforce
> certain behaviours goes with that role, and the residual role, that of
> operation of an address registry, necessarily has to take a more
> neutral stance if it is to be a role that is discharged effectively."
>
>
>
>
>>> Or, to put a more practical face on the same question: how do you
>>> propose
>>> that the industry deal with the deaggregation that will result from
>>> the
>>> widespread transfer of small netblocks (as allowed under prop-50)?
>>>
>
>
> Thats a very good example, because deaggregation in the address space
> has been a constant factor for decades. i.e. if enforcing strong
> aggregation in the routing space was a metric of success of the policy
> framework associated with allocation, then the metrics of the routing
> system over the past 10 years would have to assign a failing grade  
> here.
>
> Again, to quote from the article:
>
> "However, fragmentation of the routing space has not been directly
> linked to the further allocation function, and the results of this
> decoupling of policy with a risk of any negative outcome is clearly
> evident in the continuing fragmentation observed in the routing  
> space."
>
> So, no, I don't think that any transfer policy proposal will do any
> better than the allocation policy framework, and the allocation policy
> framework has been, on the whole, ineffectual.
>
>
>>> I agree that restricting deaggregation through regulating access to
>>> the
>>> registry will not be 100% effective, but it seems more likely to be
>>> effective than any alternative I've seen so far.
>>>
>
> Well with no successful practical experience to call upon so far, I
> suppose that we can all have a guess at what an effective policy may
> be in this area.
>
> regards,
>
>    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 gih at apnic.net  Mon Oct 20 02:35:04 2008
From: gih at apnic.net (Geoff Huston)
Date: Mon, 20 Oct 2008 17:35:04 +1100
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <918C41F9-03AF-418E-A853-E19DCE18E023@pch.net>
References: <48FBE342.8020403@internap.com>
	<6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
	<E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
	<918C41F9-03AF-418E-A853-E19DCE18E023@pch.net>
Message-ID: <20985F2A-CEDF-4348-9A07-A1552E767554@apnic.net>

We certainly differ in perspective, thats true.

I'd rather not write a 1,000 word response - this list is already in  
overload in terms of reading matter, so I'll limit myself to 150  
words, and  simply state that I do not see this situation within the  
parameters of the analogies you are drawing here.

As  far as I can see when all thats left to the RIRs in IPv4 in the  
registry function then it seems rather self-defeating to me to start  
imposing all kinds of constraints and conditions on write access to  
the registry. The most natural response in such situation in the face  
of such constraints and additional overheads is for folk to head to a  
more accommodating registry. And I don't think that is a desireable  
outcome.

But you see it differently. Fair enough

rgds,

   Geoff

   Disclaimer: these are all my opinions - I'm not representing anyone  
or anybody else.

On 20/10/2008, at 5:03 PM, Tom Vest wrote:

> Geoff, IMHO, you're simply off base here, both in your specific  
> recommendations, and in your claim that there is no relevant  
> experience base.
>
> I happen to believe that you've been absolutely true to your  
> convictions since RFC 1744. And I recognize that your convictions  
> (if RFC 1744 is any guide), or at least your concrete  
> recommendations since then, have a solid, principled foundation in  
> libertarian "free banking" theories (for those interested, see  
> references below). But the fact remains, every time that such  
> theories have been put into practice they have failed absolutely,  
> resulting in the imposition of national partitioning of markets and  
> regulatory structures, if not outright nationalization/operation of  
> the affected industries. There is no reason to doubt that anything  
> other than that will result from the course of action you're  
> advocating, and numerous specific and likely reasons/paths that  
> would lead precisely to that outcome.
>

[...]




From gih at apnic.net  Mon Oct 20 04:00:17 2008
From: gih at apnic.net (Geoff Huston)
Date: Mon, 20 Oct 2008 19:00:17 +1100
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <48FBF78D.4070501@internap.com>
References: <48FBE342.8020403@internap.com>
	<6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
	<E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
	<48FBF78D.4070501@internap.com>
Message-ID: <9128FA70-73F1-4BF6-843A-72854DB1AFDA@apnic.net>

Hi Scott,

I'm pretty sure that what I was saying was not working for you, and  
maybe rephrasing my thoughts might possibly help.

What I'm trying to say is that attempting to place the registry on a  
course of saving the Internet from all kinds of dire perils in  
routing, address speculation, unfairness, and such, with only a  
registry function to work with to achieve this is pretty high risk  
path to take, in my opinion.

[Press delete now if you're already drowning with the volume on the  
ppml list! The rest of this note just expands upon this argument.]

When there are no more allocations to be made there is no de facto  
monopoly of the RIRs. The registry function is not one that is the  
unique prerogative of the RIRs to operate - quite the opposite, and,  
as we've already seen with the proliferation of IRRs, when you don't  
like the policies or practices associated with using one registry you  
can always use another! Yes, I appreciate that these are heretical  
thoughts. It would be good to believe that the RIRs will continue to  
have some enforcement authority in this space that could allow the  
inclusion of a broader agenda related to mitigating some of the worst  
risks in address transfers and markets, but, frankly, I personally  
don't find such assertions of enforcement authority at all comforting  
or even credible.

If access to the registry has onerous constraints and conditions, the  
registry runs the risk of annoying the registry's customers. And while  
the address allocation function is a de facto monopoly, registries are  
not. Registries can come and go in the blink of an eye. If a registry  
manages to alienate its customers then the most obvious response is  
that other registries, with more neutral stances, will emerge and at  
that point address chaos is only a short step further down that track.


thanks,

     Geoff

     Disclaimer: These are all my opinions, totally.

  


From tvest at pch.net  Mon Oct 20 07:16:09 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 20 Oct 2008 07:16:09 -0400
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <20985F2A-CEDF-4348-9A07-A1552E767554@apnic.net>
References: <48FBE342.8020403@internap.com>
	<6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
	<E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
	<918C41F9-03AF-418E-A853-E19DCE18E023@pch.net>
	<20985F2A-CEDF-4348-9A07-A1552E767554@apnic.net>
Message-ID: <5546F577-27DF-4401-9B12-A7CCEF601616@pch.net>


On Oct 20, 2008, at 2:35 AM, Geoff Huston wrote:

> We certainly differ in perspective, thats true.
>
> I'd rather not write a 1,000 word response - this list is already in  
> overload in terms of reading matter, so I'll limit myself to 150  
> words, and  simply state that I do not see this situation within the  
> parameters of the analogies you are drawing here.


I know that you don't agree. But you didn't agree in 1994 either. In  
fact, all of this sounds like the same arguments made against the  
establishment of open, transparent, not-for-profit RIRs in the first  
place.


> As  far as I can see when all thats left to the RIRs in IPv4 in the  
> registry function then it seems rather self-defeating to me to start  
> imposing all kinds of constraints and conditions on write access to  
> the registry. The most natural response in such situation in the  
> face of such constraints and additional overheads is for folk to  
> head to a more accommodating registry. And I don't think that is a  
> desireable outcome.
>
> But you see it differently.


You are mistaken. I don't see more "constraints and conditions and  
overhead" as a desirable outcome. I do see great benefit to preserving  
the power to balance unavoidable constraints and overhead against  
changing technological circumstances by means of our own open and  
transparent self-governance mechanisms. You appear to believe that the  
exhaustion of IPv4 provides a persuasive excuse that none of those  
constraints apply anymore, even though quite a few people are aware,  
e.g., that IPv6 exists -- and even more people will be learning about  
it if the industry elects to conveniently pursue a strategy of  
permanent addressing scarcity over one of indefinite addressing  
abundance.

To paraphrase someone with a far better command of the power of brevity:

"One may choose to ignore the fundamental technical issues, but this  
doesn't change the fundamental property of those issues."

ftp://ftp.ietf.org/ietf-online-proceedings/95apr/area.and.wg.reports/ops/cidrd/cidrd.rekhter.slides.ps

But you still see it differently... fair enough.

Regards,

TV


From mysidia at gmail.com  Mon Oct 20 08:40:47 2008
From: mysidia at gmail.com (James Hess)
Date: Mon, 20 Oct 2008 07:40:47 -0500
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <20081018212239.GA38332@ussenterprise.ufp.org>
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
Message-ID: <6eb799ab0810200540m37b0403dnda832304a43a9387@mail.gmail.com>

On Sat, Oct 18, 2008 at 4:22 PM, Leo Bicknell <bicknell at ufp.org> wrote:
[...]
> However, the larger problem is that this is the entirely wrong
> definition of "in use".  Let's take a simple example of a University.
> They may have wired dorm rooms, students with laptops, and wifi
> enabled classrooms.  If you ping at 11AM, the classroom IP's respond,
> and the dorm ones do not, if you ping at 11PM, the dorm rooms
> respond, the classrooms do not.  And if you ping at 12 noon when
> they are all walking to lunch almost none of either respond.
[...]

It is a flawwed methodology to use ICMP / TCP pings  to detect hosts

But
In that case,  I would have to say the university is not using the IP
space as efficiently as possible.  And indeed the ips _aren't_  in use
when nothing is connected to them.

A study  perhaps _should_  count the extra ones used as IPs that are
being wasted.

The inefficiency results from tying up the classroom WiFi   ips at
times when these IPs are not needed at all  and tying up the dorm IPs
at times when they are not needed.

This inefficiency may result in consuming twice as many IPs as needed;
since each host
essentially has a different IP at different times of the day.

Efficient use would be to have one pool of IPs;  a laptop is assigned
an IP from a DHCP pool,
That pool is the same for both classroom WiFi  and for dorm room connectivity.
And does not change if a laptop is moved between two places on the campus net.


Logically, the IP  is a property of the host.
The reason a host would ever have different IPs  when plugged into
different parts of the same organization's  network   is that the
topology is laden with an excessive number of
Layer 3  routing devices.


Instead,  switches  and bridges  should be used to connect the   Dorm
and classroom WiFi networks.
Any   firewalling,  broadcast filtering,  traffic limits, DHCP use
enforcement,  etc,
between the two  should  all be implemented on  transparent bridges.

This  design would eliminate unnecessary duplication of IPs for the
small set of hosts.

--
-J


From michael.dillon at bt.com  Mon Oct 20 09:52:42 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 20 Oct 2008 14:52:42 +0100
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
In-Reply-To: <6eb799ab0810200540m37b0403dnda832304a43a9387@mail.gmail.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08BF34A2@E03MVZ2-UKDY.domain1.systemhost.net>

> This  design would eliminate unnecessary duplication of IPs 
> for the small set of hosts.

IPv6 would eliminate the need to make a network design which
shares IP addresses from a flat addressing structure. It is
probably too late for anyone to fix an IPv4 network design
which uses addresses inefficiently.

Better to deploy IPv6 where addressing efficiency is not an
issue at all and it is expected that every device will have
multiple IPv6 addresses.

--Michael Dillon


From kkargel at polartel.com  Mon Oct 20 10:02:48 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 20 Oct 2008 09:02:48 -0500
Subject: [arin-ppml] Some observations on the differences in the
	varioustransfer policy proposals
In-Reply-To: <E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
References: <48FBE342.8020403@internap.com><6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
	<E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AACE@mail>

I want to support Scott (at least I think that is what I am doing in what he

says about RIR's and whther they need to have every answer.  I do agree that

the RIR is primarily a registry, and at inception was not meant to be a 
regulating body.  Could it be that we are getting too big for our britches?

>From the RIR perspective I don't think there is a problem with 
mini-allocations (<=/24).  In fact allowing mini-allocations will increase
the 
customer base.

The people who will have a problem with small allocations will be the end 
users, who will find limited connectivity as peering points respond to 
excessive de-aggregation by aggregating and filtering route advertisements.

This is not to say that small allocations will not have their use.  They
will 
still be great for the near direct connected organizations who need a small 
secure common block and don't mind manually inserting a routing entry for
it. 
What the small allocation will not work for is the SOHO implementation that 
needs a /27 for various and sundry public servers on a global market.  That 
customer will still be better off going to his provider for a re-allocated 
block.

The whole de-aggregation thing will be self healing.  Peering points will 
route using tables near the maximum size the hardware can handle and they
will 
do whatever is necessary to not break themselves.  End users will have 
connectivity to the limits of their providers hardware.  Some providers will

spend more on hardware to have greater cpability and pass that cost to their

customers.  Other providers will spend less, provide less granular routing
and 
charge less to their customers.  Business will dictate which is the better 
strategy.  End users who can't route because of aggregation will renumber or

NAT and migrate to numbers that route more easily.

Historically this has been one of the ways the internet has evolved.
Someone 
has a neat idea, and tries it.  If it works it gets implemented, if it
doesn't 
work it gets relegated to the bad idea pile.  Sort of a Darwinian approach
to 
networking.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Geoff Huston
> Sent: Sunday, October 19, 2008 9:25 PM
> To: Scott Leibrand
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Some observations on the differences
> in the varioustransfer policy proposals
>
> Hi Scott,
>
> >> In your article you imply that the RIRs' registry
> functions are not
> >> the proper lever from which to apply the various
> regulatory functions
> >> that the community has indicated are needed.  Where/how would you
> >> propose the regulatory function reside / be applied instead?
> >>
>
> Again, the real question is, MUST the RIRs have an answer for
> _everything_? Must the RIR's devise complex procedures that
> attempt to counter particular behaviours,  at the common
> community cost of more onerous procedures with higher
> overheads. And without any practical enforcement mechanism
> why will others even listen to the RIRs?
>
> To quote from the article:
>
> "But the observation should be made that markets in all
> manner of good and services have a rich history in human
> societies, and the role of the regulator is similarly one
> with a rich history. Market regulators exist in many guises
> and in many regimes, and can exert influence through various
> direct and indirect means. There is no need to believe that
> this issue of transfers and address markets requires a
> comprehensive solution based solely on the resources,
> capability, authority and enforcement authority of the RIR's.
> Once the RIR's are no longer address allocation entities much
> of their ability to enforce certain behaviours goes with that
> role, and the residual role, that of operation of an address
> registry, necessarily has to take a more neutral stance if it
> is to be a role that is discharged effectively."
>
>
>
>
> >> Or, to put a more practical face on the same question: how do you
> >> propose that the industry deal with the deaggregation that will
> >> result from the widespread transfer of small netblocks (as allowed
> >> under prop-50)?
> >>
>
>
> Thats a very good example, because deaggregation in the
> address space has been a constant factor for decades. i.e. if
> enforcing strong aggregation in the routing space was a
> metric of success of the policy framework associated with
> allocation, then the metrics of the routing system over the
> past 10 years would have to assign a failing grade here.
>
> Again, to quote from the article:
>
> "However, fragmentation of the routing space has not been
> directly linked to the further allocation function, and the
> results of this decoupling of policy with a risk of any
> negative outcome is clearly evident in the continuing
> fragmentation observed in the routing space."
>
> So, no, I don't think that any transfer policy proposal will
> do any better than the allocation policy framework, and the
> allocation policy framework has been, on the whole, ineffectual.
>
>
> >> I agree that restricting deaggregation through regulating
> access to
> >> the registry will not be 100% effective, but it seems more
> likely to
> >> be effective than any alternative I've seen so far.
> >>
>
> Well with no successful practical experience to call upon so
> far, I suppose that we can all have a guess at what an
> effective policy may be in this area.
>
> regards,
>
>     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.
> 
-------------- 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/20081020/b818f568/attachment.bin>

From mueller at syr.edu  Mon Oct 20 11:04:07 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 20 Oct 2008 11:04:07 -0400
Subject: [arin-ppml] Some observations on the differences in the
	varioustransfer policy proposals
In-Reply-To: <918C41F9-03AF-418E-A853-E19DCE18E023@pch.net>
References: <48FBE342.8020403@internap.com><6E694160-6B98-4880-81E2-AE2603243C18@apnic.net><E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
	<918C41F9-03AF-418E-A853-E19DCE18E023@pch.net>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9023C9AAD@SUEXCL-02.ad.syr.edu>

Just for the record, Tom's analogies between banking/currency and the
management of IP addresses have no foundation in economic theory. 

IP addresses are NOT a medium of exchange, store of value, and unit of
account; routing bloat is NOT "inflation;" etc. etc.



From mueller at syr.edu  Mon Oct 20 10:51:08 2008
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 20 Oct 2008 10:51:08 -0400
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <48FBE342.8020403@internap.com>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
	<48FBE342.8020403@internap.com>
Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9023C9AAC@SUEXCL-02.ad.syr.edu>

The great thing about Geoff's article is that it calls for a neutral,
open administration of the registry function AND it calls attention to
the fact that our ability to maintain that administrative neutrality
depends on not overloading it with too many regulatory functions. This
is not a theoretical concern, as our experience with ICANN has shown
what happens when you try to load a huge number of regulatory functions
onto the simple act of coordinating the root zone file. If you like what
goes on with ICANN (including WSIS, a $70million annual budget, the
ongoing takeover by governments unrestrained by any international treaty
or due process, and all the other connections to sovereignty) then keep
trying to make the RIRs into full-fledged industry regulators via the
address registry allocation function. 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Scott Leibrand
> Sent: Sunday, October 19, 2008 9:48 PM
> To: Geoff Huston
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Some observations on the differences in the
> various transfer policy proposals
> 
> Geoff,
> 
> In your article you imply that the RIRs' registry functions are not
the
> proper lever from which to apply the various regulatory functions that
the
> community has indicated are needed.  Where/how would you propose the
> regulatory function reside / be applied instead?
> 
> Or, to put a more practical face on the same question: how do you
propose
> that the industry deal with the deaggregation that will result from
the
> widespread transfer of small netblocks (as allowed under prop-50)?
> 
> I agree that restricting deaggregation through regulating access to
the
> registry will not be 100% effective, but it seems more likely to be
> effective than any alternative I've seen so far.
> 
> Thanks,
> Scott
> 
> Geoff Huston wrote:
> > Hi,
> >
> > At the ARIN meeting last week the question arose as to why the
various
> > policy proposals related to address transfers in the different RIRs
> > were so different. I made some comments in response to this question
> > from my perspective and then I had some followup questions mailed to
> > me, so I thought maybe there is some value in writing up from my
> > perspective. After all there is still some difference between the
> > proposal(s) before ARIN and Proposal-50 before APNIC, and  the
> > question as to why this difference exists is an interesting one.
> >
> > If you are interested its at: http://www.potaroo.net/ispcol/2008-
> 11/transfers.html
> >
> > thanks,
> >
> >     Geoff Huston
> >
> >     DIsclaimer: I'm speaking for myself, again!
> >
> >
> >
> >
> > _______________________________________________
> > 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 bmanning at vacation.karoshi.com  Mon Oct 20 11:39:49 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 20 Oct 2008 15:39:49 +0000
Subject: [arin-ppml] Some observations on the differences in the
	varioustransfer policy proposals
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AACE@mail>
References: <E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AACE@mail>
Message-ID: <20081020153949.GA561@vacation.karoshi.com.>

On Mon, Oct 20, 2008 at 09:02:48AM -0500, Kevin Kargel wrote:
> I want to support Scott (at least I think that is what I am doing in what he
> says about RIR's and whther they need to have every answer.  I do agree that
> the RIR is primarily a registry, and at inception was not meant to be a 
> regulating body.  Could it be that we are getting too big for our britches?


	well - we are the RIR (at least in this region) and if you
	are persuaded that we have never performed a regulatory function,
	then i would be surprised.  a good portion of ARIN policy is
	regulatory in nature.  if you want to change that, it is clearly
	within your power to do so - the policy process is open to all.

	the real trick here is that the landscape has changed.  there is 
	very little left of "greenfield" IPv4 space and so the RIR's and the
	folks who make up the membership are coming to grips with the problem
	of "re-use" ... we have to realize that its no longer possible (in v4 
	space) to pollute the space and move on to "clean" space.  Learning
	how to live within the constraints of v4 poses two general courses
	of action ::  

		a) the (perceived) Geoff Huston - Its NAT all the way down
		   forever.

		b) we move from one address family to another - e.g. migration 
		   to v6 is possible and desireable.

	in either case, we have to deal with the fact that we have to figure out
	how to reuse space.  and increasingly, there are going to be folks who 
	want to help (regulate).


--bill


From michael.dillon at bt.com  Mon Oct 20 11:59:26 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 20 Oct 2008 16:59:26 +0100
Subject: [arin-ppml] Some observations on the differences in
	thevarioustransfer policy proposals
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9023C9AAD@SUEXCL-02.ad.syr.edu>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08CC18F2@E03MVZ2-UKDY.domain1.systemhost.net>

> Just for the record, Tom's analogies between banking/currency 
> and the management of IP addresses have no foundation in 
> economic theory. 

Given that banking principles have a foundation in economic
theory, and that Tom's analogies attempted to relate this
stuff to IP address management, I would say that your
statement above is clearly wrong. 

> IP addresses are NOT a medium of exchange, store of value, 
> and unit of account; routing bloat is NOT "inflation;" etc. etc.

Yes, we know that. An analogy is an analogy, a metaphor is a metaphor
and so on. Why are you telling us these basics of English Lit 101?

--Michael Dillon


From dlw+arin at tellme.com  Mon Oct 20 12:25:42 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Mon, 20 Oct 2008 09:25:42 -0700
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <48FBE342.8020403@internap.com>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
	<48FBE342.8020403@internap.com>
Message-ID: <20081020162542.GC8662@shell02.cell.sv2.tellme.com>

On Sun, Oct 19, 2008 at 06:47:46PM -0700, Scott Leibrand wrote:
> Or, to put a more practical face on the same question: how do you propose 
> that the industry deal with the deaggregation that will result from the 
> widespread transfer of small netblocks (as allowed under prop-50)?
> 
> I agree that restricting deaggregation through regulating access to the 
> registry will not be 100% effective, but it seems more likely to be 
> effective than any alternative I've seen so far.

I know many or even most of us wear multiple hats, and routing table
bloat is a very serious concern for us.  Depsite that, I'm still
wondering why we spend so much time trying to prevent it via address
policy.  We've been only marginally effective at it, as Geoff notes.

It seems to me that the ability of a given allocation or assignment to
get into a global routing table (whatever that may mean at the time) is
entirely not our (ARIN's or other RIR's) problem.  As the ARIN NRPM
notes:

>Provider independent (portable) addresses issued directly from ARIN or
>other Regional Registries are not guaranteed to be globally routable.
>Therefore, ISPs should consider the following order of priority when
>requesting IP address space:
>
>    * Request IP address space from upstream provider
>    * Request IP address space from provider's provider
>    * Request IP address space from ARIN (not guaranteed to be globally routable)

The language is a bit outdated, but the intent is clear.

>From my point of view, good stewardship of the address space means
conservation and efficiency.  That's almost diametrically opposed to
preserving the routing table...but again, that's not ARIN's problem.
It's a problem for the operator community to sort out, via new
technology (RRG folks, save us, please!), or monetization of routing
slots, or value judgements about specific routes (if a root server was
anycast in a /28, would you route it?).

Again, many of us live in both worlds, so it's difficult to separate
those conflicting needs, but we need to at least acknowledge the
problem.  More on topic, I do think we need to consider Geoff's point
about what regulatory role we see for the RIR system in the future.
I'm not convinced that abstaining from any regulation is a good idea,
since we do have a bit of a lever to yank on, but heavy-handed
regulation will almost certainly result in alternative registries
getting setup.  While alternative roots for DNS are mostly an amusing
and harmless joke (to me, at least), alternative authorities for who
uses what IPv4 space seems like a path to chaos.

For my part, I think the level of regulation imposed by the current
*allocation* policies is sufficient.  Adding extra verbiage to a
transfer policy may only cause confusion.

Perhaps we could see a copy of the open mic slide from rs posted here?
That seemed like a more rational way to move forward with a transfer
policy.

-David



From tvest at pch.net  Mon Oct 20 12:54:58 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 20 Oct 2008 12:54:58 -0400
Subject: [arin-ppml] Some observations on the differences in the
	varioustransfer policy proposals
In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9023C9AAD@SUEXCL-02.ad.syr.edu>
References: <48FBE342.8020403@internap.com><6E694160-6B98-4880-81E2-AE2603243C18@apnic.net><E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
	<918C41F9-03AF-418E-A853-E19DCE18E023@pch.net>
	<7663C7E01D8E094989CA62F0B0D21CD9023C9AAD@SUEXCL-02.ad.syr.edu>
Message-ID: <9A7EA924-7F14-47BB-B6E3-03B7622E9154@pch.net>


On Oct 20, 2008, at 11:04 AM, Milton L Mueller wrote:

> Just for the record, Tom's analogies between banking/currency and the
> management of IP addresses have no foundation in economic theory.
>
> IP addresses are NOT a medium of exchange, store of value, and unit of
> account; routing bloat is NOT "inflation;" etc. etc.

Thank you Milton.
Between your cumulating record of meaningless-to-false assertions on  
the topic of Internet addressing, your utter lack of any expertise in  
banking or monetary economics, and the awe-inspiring success of  
orthodox theories about how banking works, I could scarcely ask for a  
more ringing endorsement.

For others:

Victor Li, Federal Reserve Bank of Atlanta, "Is Why We Use Money  
Important?"
http://www.frbatlanta.org/filelegacydocs/li.pdf
  -- clarifies what a medium of exchange is/does

Jos? De J. Noguera, "The Appearance of Carriers and the Origins of  
Money"
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=264542
-- about how environments like the NSFNet can foster the selection/ 
promotion of some simple input as a medium of exchange

Stephen Williamson, Federal Reserve Bank of Richmond, "Limited  
Participation and the Neutrality of Money"
http://www.www.rich.frb.org/publications/economic_research/economic_quarterly/pdfs/spring2005/williamson.pdf
-- about consequences of the asymmetry between delegation  
relationships like RIR->LIR and LIR-> end user 

Sebastien Lotz and Guillaume Rocheteau, Journal of Money, Credit &  
Banking (Vol. 34 No. 3: Aug. 2002), "On the Launching of a New Currency"
http://ideas.repec.org/a/mcb/jmoncb/v34y2002i3p563-88.html
-- Name is self-explanatory, relevant to the current dilemma

Geoffrey Wood, "Governance or regulation? Efficiency, Stability, and  
Integrity in the Financial Sector"
http://www.palgrave-journals.com/jbr/journal/v7/n1/abs/2340002a.html
-- Name is self-explanatory

Dozens more, at least, on request.

FYI, before actually working in the Internet sector, one of my PhD  
fields was trade and MONETARY policy. While in grad school I worked  
for the CFR/Pacific Council on International Policy for four years,  
during which I was fortunate enough to to serve as rapporteur for  
dozens of member briefings by various senior monetary policy  
practitioners -- cabinet-level treasury officials, central bankers,  
IMF and IBRD executives, etc.

Granted, that doesn't make me anybody's expert -- much less an arbiter  
of the foundations of economic theory.
Lucky for us, we have you to take care of those duties!

We missed you in Los Angeles,

TV

From sleibrand at internap.com  Mon Oct 20 13:26:06 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 20 Oct 2008 10:26:06 -0700
Subject: [arin-ppml] Possible revisions to 2008-6
In-Reply-To: <20081020162542.GC8662@shell02.cell.sv2.tellme.com>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
	<48FBE342.8020403@internap.com>
	<20081020162542.GC8662@shell02.cell.sv2.tellme.com>
Message-ID: <48FCBF2E.3040205@internap.com>

David Williamson wrote:
> Perhaps we could see a copy of the open mic slide from rs posted here?
> That seemed like a more rational way to move forward with a transfer
> policy.

I would agree, and that seems to be a viable direction in which to evolve 
2008-6.  Below is one possible way to revise 2008-6 to preserve its 
timetable and essential features, while using the much simpler open-mic 
language.  (2008-6 has not yet been revised, and this is only one 
possibility Bill and the AC are considering.)


8.2.1 Emergency Transfer Policy for IPv4 Addresses
For a period of 3 years from policy implementation, ARIN-region number 
resources may be released, in whole or in part, to ARIN or another 
organization, by the authorized holder of the resource.

Number resources may only be received under RSA, with demonstrated
need, in the exact amount which they are able to justify under ARIN
resource-allocation policies.

The timetable stuff would remain unchanged.


Thoughts?

-Scott

(speaking for myself only, not for, or even in consultation with, the AC)


From sleibrand at internap.com  Mon Oct 20 13:29:00 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Mon, 20 Oct 2008 10:29:00 -0700
Subject: [arin-ppml] Some observations on the differences in the various
 transfer policy proposals
In-Reply-To: <9128FA70-73F1-4BF6-843A-72854DB1AFDA@apnic.net>
References: <48FBE342.8020403@internap.com>
	<6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
	<E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
	<48FBF78D.4070501@internap.com>
	<9128FA70-73F1-4BF6-843A-72854DB1AFDA@apnic.net>
Message-ID: <48FCBFDC.5030206@internap.com>

Geoff Huston wrote:
> Hi Scott,
> 
> I'm pretty sure that what I was saying was not working for you, and 
> maybe rephrasing my thoughts might possibly help.
> 
> What I'm trying to say is that attempting to place the registry on a 
> course of saving the Internet from all kinds of dire perils in routing, 
> address speculation, unfairness, and such, with only a registry function 
> to work with to achieve this is pretty high risk path to take, in my 
> opinion.

I understand your position there, but you haven't answered my question: 
who/what do you think is in a better position than the RIRs to do so?

Thanks,
Scott


From info at arin.net  Mon Oct 20 13:50:26 2008
From: info at arin.net (Member Services)
Date: Mon, 20 Oct 2008 13:50:26 -0400
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation - Revised
Message-ID: <48FCC4E2.40600@arin.net>

The author submitted a revised version of the 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: Annual WHOIS POC Validation

Author: Chris Grundemann

Proposal Version: 3

Submission Date: 20 October 2008

Proposal type: new

Policy term: permanent

Policy statement:

ARIN will validate each WHOIS POC at least annually.  Unresponsive POC
email addresses shall be marked as such in the database.  If ARIN
staff deems a POC to be completely and permanently abandoned or
otherwise illegitimate, the record shall be locked or deleted.  ARIN
will maintain, and make readily available to the community, a current
list of address-blocks with no valid POC.

Rationale:

The intention of this proposal is to ensure valid whois POC
information with an annual validation process.  It further aims to
mitigate any risk that it creates in so doing.

One of the most important resources when dealing with abuse (including
hijacking, spam, ddos, etc) is whois.  ARIN's whois data is only
useful if it is known to be valid.  The current NRPM does not address
this in a manner which ensures up to date POC contact information in
all cases.  The focus is on valid email addresses because this is the
contact method of choice for most in the Internet community when
dealing with abuse or hijacking issues.  POC information that can not
be confirmed can be judged as not valid.

A netblock with no valid POC presents a target to hijackers.  Once POC
info is marked or tagged as invalid (like this policy proposes), it
becomes possible for potential hijackers to locate such netblocks by
searching the whois database.  As a defense against such hijacking
attempts, this policy proposes that the information be presented in
full to the entire community.  This should do at least one of two
things; bring the netblock to the attention of whomever is responsible
for it and/or allow other network operators to understand the
potential risk and take appropriate action to mitigate.

Timetable for implementation: The first validation should take place
within one calendar year of the policy being accepted.











From kkargel at polartel.com  Mon Oct 20 14:11:48 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 20 Oct 2008 13:11:48 -0500
Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation -
	Revised
In-Reply-To: <48FCC4E2.40600@arin.net>
References: <48FCC4E2.40600@arin.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AAD0@mail>

I support whois validation.  

One comment I would like to make would be that the method of marking the
record as unvalidated would be to just include the last contact verification
date in the record.  This could initially be the date of creation.

Tracking validation date would give staff (and the community) more
granularity for taking levels of action.  

Authenticated action taken by the registrant such as modification via
template could be construed as verification and update the validation date
field, allowing registrants to proactively volunteer record validation
refresh and to perhaps allow automated template response to verification
requests. 

If this has previously been suggested I apologize.  Maybe that's where I got
the idea.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
> Sent: Monday, October 20, 2008 12:50 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC 
> Validation - Revised
> 
> The author submitted a revised version of the 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: Annual WHOIS POC Validation
> 
> Author: Chris Grundemann
> 
> Proposal Version: 3
> 
> Submission Date: 20 October 2008
> 
> Proposal type: new
> 
> Policy term: permanent
> 
> Policy statement:
> 
> ARIN will validate each WHOIS POC at least annually.  
> Unresponsive POC email addresses shall be marked as such in 
> the database.  If ARIN staff deems a POC to be completely and 
> permanently abandoned or otherwise illegitimate, the record 
> shall be locked or deleted.  ARIN will maintain, and make 
> readily available to the community, a current list of 
> address-blocks with no valid POC.
> 
> Rationale:
> 
> The intention of this proposal is to ensure valid whois POC 
> information with an annual validation process.  It further 
> aims to mitigate any risk that it creates in so doing.
> 
> One of the most important resources when dealing with abuse 
> (including hijacking, spam, ddos, etc) is whois.  ARIN's 
> whois data is only useful if it is known to be valid.  The 
> current NRPM does not address this in a manner which ensures 
> up to date POC contact information in all cases.  The focus 
> is on valid email addresses because this is the contact 
> method of choice for most in the Internet community when 
> dealing with abuse or hijacking issues.  POC information that 
> can not be confirmed can be judged as not valid.
> 
> A netblock with no valid POC presents a target to hijackers.  
> Once POC info is marked or tagged as invalid (like this 
> policy proposes), it becomes possible for potential hijackers 
> to locate such netblocks by searching the whois database.  As 
> a defense against such hijacking attempts, this policy 
> proposes that the information be presented in full to the 
> entire community.  This should do at least one of two things; 
> bring the netblock to the attention of whomever is 
> responsible for it and/or allow other network operators to 
> understand the potential risk and take appropriate action to mitigate.
> 
> Timetable for implementation: The first validation should 
> take place within one calendar year of the policy being accepted.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20081020/39e13235/attachment.bin>

From tvest at pch.net  Mon Oct 20 14:28:46 2008
From: tvest at pch.net (Tom Vest)
Date: Mon, 20 Oct 2008 14:28:46 -0400
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <20081020162542.GC8662@shell02.cell.sv2.tellme.com>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
	<48FBE342.8020403@internap.com>
	<20081020162542.GC8662@shell02.cell.sv2.tellme.com>
Message-ID: <8FB4FCE6-08D6-4E7B-BA4B-94215F488957@pch.net>


On Oct 20, 2008, at 12:25 PM, David Williamson wrote:

> On Sun, Oct 19, 2008 at 06:47:46PM -0700, Scott Leibrand wrote:
>> Or, to put a more practical face on the same question: how do you  
>> propose
>> that the industry deal with the deaggregation that will result from  
>> the
>> widespread transfer of small netblocks (as allowed under prop-50)?
>>
>> I agree that restricting deaggregation through regulating access to  
>> the
>> registry will not be 100% effective, but it seems more likely to be
>> effective than any alternative I've seen so far.
>
> I know many or even most of us wear multiple hats, and routing table
> bloat is a very serious concern for us.  Depsite that, I'm still
> wondering why we spend so much time trying to prevent it via address
> policy.

Hi David,

That's the great thing about an operating environment that "works" --  
it's largely invisible/transparent to its beneficiaries.
But here's why we spend so much time doing it.

For the sake of argument, imagine that in most places the absolute  
success rate of first-time RIR "initial allocation" requests is around  
33% under most circumstances. Presumably, most aspiring new routing  
system participants that don't get approved initially take another  
turn at bat, perhaps with a better clarification of need, or with a  
lower need calculation. A few may give up, but presumably most get it  
right and eventually appear as their own PA or somebody else's (PI)  
routing tale entries. However, those that miss the mark first time  
take longer to appear there, and often appear with a somewhat smaller  
footprint.

Now imagine that hostmasters within ISPs have approximately the same  
"instant gratification rate" -- if not then you get more frustrated ex- 
customers arriving that the RIRs' doorsteps, or accelerated growth  
rate for subsequent allocation demand, which may also prompt RIR  
hostmasters to inquire about the effectiveness of ISP-level  
conservation practices.

The first line of evaluation determines how many PA and PI recipients  
there are, and how many more join there ranks every year. The second  
line of evaluation determines how often each is returning for a second  
and subsequent PA allocation (non-aggregatable in most regions), and  
also affects the frequency with which new, non-aggregatable PI seekers  
appear.

There's no real way to know the absolute rate of demand for new entry,  
as defined above, because we're just now reaching/exceeding the peak  
demand levels that existed at the time of the bubble. The Internet's  
much bigger now, however, so it looks much less bubble-like this time  
-- but whether or not this is a cyclical phenomenon, or the  
continuation of a single (albeit interrupted) growth trend is  
anybody's guess. But unless you imagine that the world's supply of  
aspiring ISPs and network-insourcing enterprises is almost permanently  
exhausted, maybe it doesn't matter.

So, what would have happened under a different allocation arrangement  
that made it twice as easy to secure an initial allocation? Maybe  
there would now be twice as many routing system participants, most of  
which would be facing twice the competitive pressure of the kind that  
results in PA prefix-level deaggregation. Alternately, what would have  
happened if half of the est. 3,500 or so new routing system  
participants that joined our ranks last year had been absolutely/ 
permanently turned away? How many national regulators would have  
opened up antitrust investigations under those circumstances?  
Alternately, how many would be preparing to partition their own  
economies and instituting their own, "fair" address delegation regimes?

The system that we all collectively maintain has been successful to- 
date because it has successfully balanced these requirements.

> We've been only marginally effective at it, as Geoff notes.


Geoff and others assume that PA prefix-level deaggregation could have  
been or should have been stopped somehow by the RIRs, even though the  
RIRs are basically just administrators of community-defined policies.  
They insist that this inflation management should have been successful  
despite the universal assertions of commercial independence -- and  
also assume that it would neither have resulted in a huge increase in  
the demand for PI prefixes -- leading to the same result -- or to  
calls for external intervention. Such complaints should sound familiar  
-- they're identical to the claims that some bank executives have made  
recently, that they're merely innocent victims of bank deregulation,  
and the commercial freedoms which they themselves demanded.

TV


> It seems to me that the ability of a given allocation or assignment to
> get into a global routing table (whatever that may mean at the time)  
> is
> entirely not our (ARIN's or other RIR's) problem.  As the ARIN NRPM
> notes:
>
>> Provider independent (portable) addresses issued directly from ARIN  
>> or
>> other Regional Registries are not guaranteed to be globally routable.
>> Therefore, ISPs should consider the following order of priority when
>> requesting IP address space:
>>
>>   * Request IP address space from upstream provider
>>   * Request IP address space from provider's provider
>>   * Request IP address space from ARIN (not guaranteed to be  
>> globally routable)
>
> The language is a bit outdated, but the intent is clear.
>
>> From my point of view, good stewardship of the address space means
> conservation and efficiency.  That's almost diametrically opposed to
> preserving the routing table...but again, that's not ARIN's problem.
> It's a problem for the operator community to sort out, via new
> technology (RRG folks, save us, please!), or monetization of routing
> slots, or value judgements about specific routes (if a root server was
> anycast in a /28, would you route it?).
>
> Again, many of us live in both worlds, so it's difficult to separate
> those conflicting needs, but we need to at least acknowledge the
> problem.  More on topic, I do think we need to consider Geoff's point
> about what regulatory role we see for the RIR system in the future.
> I'm not convinced that abstaining from any regulation is a good idea,
> since we do have a bit of a lever to yank on, but heavy-handed
> regulation will almost certainly result in alternative registries
> getting setup.  While alternative roots for DNS are mostly an amusing
> and harmless joke (to me, at least), alternative authorities for who
> uses what IPv4 space seems like a path to chaos.
>
> For my part, I think the level of regulation imposed by the current
> *allocation* policies is sufficient.  Adding extra verbiage to a
> transfer policy may only cause confusion.
>
> Perhaps we could see a copy of the open mic slide from rs posted here?
> That seemed like a more rational way to move forward with a transfer
> policy.
>
> -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 gih at apnic.net  Mon Oct 20 15:08:09 2008
From: gih at apnic.net (Geoff Huston)
Date: Tue, 21 Oct 2008 06:08:09 +1100
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <48FCBFDC.5030206@internap.com>
References: <48FBE342.8020403@internap.com>
	<6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
	<E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
	<48FBF78D.4070501@internap.com>
	<9128FA70-73F1-4BF6-843A-72854DB1AFDA@apnic.net>
	<48FCBFDC.5030206@internap.com>
Message-ID: <D9E4B3A6-C76B-436A-BCF3-4BA285762AF3@apnic.net>


On 21/10/2008, at 4:29 AM, Scott Leibrand wrote:

> I understand your position there, but you haven't answered my  
> question: who/what do you think is in a better position than the  
> RIRs to do so?


I think you are saying "I want you to show me your concept of The  
Complete Solution."

I am saying "In my view the registry function in and of itself is  
incapable of carrying the load of The Complete Solution, whatever that  
may be - if you overload the registry with contrived constraints on  
how one can make changes in the registry you simply motivate the  
creation of alternate registries, and then rather than having a  
valuable and useful registry for the IPv4 Internet you have, well,  
fatal confusion. There are many good and compelling reasons to get  
over this IPv4 exhaustion thing and deploy IPv6, but I'm personally  
not keen on an approach that includes destruction of the integrity of  
the entire address registry structure as a major milestone."

It should be pretty clear that your question was not a question I was  
addressing. I'm not even sure that I can - when you look at the  
extraordinary breath of the global Internet industry, the massive  
diversity and size of the interests that are bought to bear on it, the  
diverse motivations and perceptions of value, the range of  
stakeholders and the manner of their interaction and the evolving  
roles and responsibility of regulatory measures in this environment,  
its pretty clear that we are within a rather complex system. I  
personally would be very skeptical of any claim of complete  
understanding of this environment, but maybe thats just me!

At which point I've already gone past acceptable levels of brevity in  
mail, and way past my personal quota of posts -  my sincere apologies  
for this.

     Geoff

     Disclaimer: Who am I? Oh right, I'm me! And thats who I'm  
speaking for!





From jrhett at svcolo.com  Mon Oct 20 18:56:33 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Mon, 20 Oct 2008 15:56:33 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <77143.1224436916@nsa.vix.com>
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
Message-ID: <185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>

On Oct 19, 2008, at 10:21 AM, Paul Vixie wrote:
> but it begs an interesting series of questions.  if "need" were  
> redefined
> to include connectedness, how much space would become "unneeded",  
> how long
> would that last in terms of randy's gold brick wall, and what legal  
> regime
> would apply since we can presume that most "unconnected" space is  
> probably
> legacy.  my personal suspicions are that the amount of space that  
> would
> become unneeded could push the brick wall back by more than two  
> years, but
> there's no way to define "connected" since there are so many private
> interconnects between defaultless networks (and it's easy to connect a
> network if it'd mean somebody keeping rights to their ip space).

Yes.  But there is also a lot of space attached to gum at the bottom  
of the shoe of the network admin who was involved in its assignment.

We should at least try to recover this space, instead of just blinking  
in the headlights.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Mon Oct 20 18:58:23 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Mon, 20 Oct 2008 15:58:23 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <868wskuhij.fsf@seastrom.com>
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>
	<48FA61BD.8050302@psg.com> <868wskuhij.fsf@seastrom.com>
Message-ID: <EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>

On Oct 19, 2008, at 7:28 PM, Robert E. Seastrom wrote:
> the status quo is that there is an impending train wreck which is not
> being adequately addressed.
>
> reclamation would preserve this status quo and give some people a
> false sense of security.


Delaying an impact does not equal a false sense of security.

Refusing to even try is refusing to attempt to alter course.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From owen at delong.com  Mon Oct 20 19:35:19 2008
From: owen at delong.com (Owen DeLong)
Date: Mon, 20 Oct 2008 16:35:19 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>
	<48FA61BD.8050302@psg.com> <868wskuhij.fsf@seastrom.com>
	<EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>
Message-ID: <194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>


On Oct 20, 2008, at 3:58 PM, Jo Rhett wrote:

> On Oct 19, 2008, at 7:28 PM, Robert E. Seastrom wrote:
>> the status quo is that there is an impending train wreck which is not
>> being adequately addressed.
>>
>> reclamation would preserve this status quo and give some people a
>> false sense of security.
>
>
> Delaying an impact does not equal a false sense of security.
>
> Refusing to even try is refusing to attempt to alter course.

Joe,
	Attempting to reclaim the space is a bit like trying to get all
the passengers to bring their hair dryers to the bow of the titanic
in hopes we can melt the ice berg in time.

	It has nothing to do with altering course.  It's an attempt
to dismantle the wall.  As crazy as that sounds, the reality is
that if we put focus on reclamation, there are those who will
believe that it is a solution, not a band-aid.

	We don't have infinite resources. As such, reclamation is
definitely NOT the place where our limited resources will have
the greatest effect.

Owen



From farmer at umn.edu  Mon Oct 20 19:20:41 2008
From: farmer at umn.edu (David Farmer)
Date: Mon, 20 Oct 2008 18:20:41 -0500
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <6eb799ab0810200540m37b0403dnda832304a43a9387@mail.gmail.com>
References: <36790.1224363677@nsa.vix.com>,
	<20081018212239.GA38332@ussenterprise.ufp.org>,
	<6eb799ab0810200540m37b0403dnda832304a43a9387@mail.gmail.com>
Message-ID: <48FCCBF9.4998.33572582@farmer.umn.edu>

On 20 Oct 2008 James Hess wrote:

> On Sat, Oct 18, 2008 at 4:22 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> [...]
> > However, the larger problem is that this is the entirely wrong
> > definition of "in use".  Let's take a simple example of a University.
> > They may have wired dorm rooms, students with laptops, and wifi
> > enabled classrooms.  If you ping at 11AM, the classroom IP's respond,
> > and the dorm ones do not, if you ping at 11PM, the dorm rooms
> > respond, the classrooms do not.  And if you ping at 12 noon when
> > they are all walking to lunch almost none of either respond.
> [...]
> 
> It is a flawwed methodology to use ICMP / TCP pings  to detect hosts

I agree this is a flawed methodology.

> The inefficiency results from tying up the classroom WiFi   ips at
> times when these IPs are not needed at all  and tying up the dorm IPs
> at times when they are not needed.
> 
> This inefficiency may result in consuming twice as many IPs as needed;
> since each host essentially has a different IP at different times of
> the day. 

Remember that most laptops have at lest two MAC addresses, one for the 
Wireless port and one for the Ethernet port.  There is no easy way to 
correlate the two.  So at least some of the inefficiency you refer to, is built 
into the architecture of most PCs, and beyond the control of a campus 
network operator.

> Efficient use would be to have one pool of IPs;  a laptop is assigned
> an IP from a DHCP pool, That pool is the same for both classroom WiFi 
> and for dorm room connectivity. And does not change if a laptop is
> moved between two places on the campus net. 

A dorm network and a classroom network, Wifi or not, are two different 
networks they have two different purposes.  One is a residential network the 
other is essentially a corporate network.  A campus network operator plays 
much different roles in the two networks.  In one case we act much like a 
corporate network, in the other we are much more like a residential service 
provider.  

If Comcast provideds me business Internet at my work place and 
Residential Internet for my house, would you expect them to conserve IP 
addresses and provide me the same address in both places?  Some how I 
don't think so.  So why are you expecting this from a campus network 
operator?  

> Logically, the IP is a property of the host. The reason a host would
> ever have different IPs  when plugged into different parts of the same
> organization's  network is that the topology is laden with an excessive
> number of Layer 3  routing devices. 

Maybe yes, maybe no. 
 
> Instead,  switches  and bridges  should be used to connect the   Dorm
> and classroom WiFi networks. Any   firewalling,  broadcast filtering, 
> traffic limits, DHCP use enforcement,  etc, between the two  should  all
> be implemented on  transparent bridges. 
> 
> This  design would eliminate unnecessary duplication of IPs for the
> small set of hosts.

I don't think you understand the scale of many University networks, for 
instance the network I'm responsible for covers 1,233 acres, almost 250 on-
net buildings, containing 21.2M gross sqft, with over 80,000 GigE access 
ports, servicing over 50,000 students and over 17,000 staff and faculty. 

I realize we are one of the larger university campus networks, but there are 
probably about 50 to 100 university networks that are at least half our size or 
greater, and that is still a fairly substantial network.  
 
So when you are talking about this scale of networks some amount of Layer 
3 topology isn't just an option it is a necessity, most enterprise class closet 
switches have a 16K or 32k CAM table size.  We have a Layer 3 backbone 
by design, to allow us to scale to this size.  We design for 2K to 5K access 
ports within a Layer 2 switching domain, this leaves room for running over a 
bit we have a few domains with more like 7K access ports and for multiple 
MAC addresses on an access port, like for Wifi-APs, VoIP phones with PC 
ports, and those small desktop switches that people install without telling the 
IT or networking staff. 

So just like commercial Internet operators, one size doesn't fit all and 
making to many assumptions can get you in trouble quick.



=======================================================
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 lear at cisco.com  Mon Oct 20 19:40:28 2008
From: lear at cisco.com (Eliot Lear)
Date: Mon, 20 Oct 2008 16:40:28 -0700
Subject: [arin-ppml] "Millions of Internet Addresses
	Are	Lying	Idle"(slashdot)
In-Reply-To: <194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
References: <36790.1224363677@nsa.vix.com>	<20081018212239.GA38332@ussenterprise.ufp.org>	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>	<48FA61BD.8050302@psg.com>
	<868wskuhij.fsf@seastrom.com>	<EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>
	<194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
Message-ID: <48FD16EC.204@cisco.com>

Owen,
> 	It has nothing to do with altering course.  It's an attempt
> to dismantle the wall.  As crazy as that sounds, the reality is
> that if we put focus on reclamation, there are those who will
> believe that it is a solution, not a band-aid.
>    

I think it is less likely that we would put off IPv6 deployment and more 
likely that we could delay and possibly eliminate in some circumstances 
multi-level NAT, if enough liquidity is realized.  That's a big if, and 
perhaps should be the focus of research within the user base.

Eliot


From vixie at isc.org  Mon Oct 20 19:56:14 2008
From: vixie at isc.org (Paul Vixie)
Date: Mon, 20 Oct 2008 23:56:14 +0000
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: Your message of "Mon, 20 Oct 2008 15:56:33 MST."
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com> 
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com> 
Message-ID: <87466.1224546974@nsa.vix.com>

> > ... no way to define "connected" since there are so many private
> > interconnects between defaultless networks (and it's easy to connect a
> > network if it'd mean somebody keeping rights to their ip space).
> 
> Yes.  But there is also a lot of space attached to gum at the bottom of
> the shoe of the network admin who was involved in its assignment.
> 
> We should at least try to recover this space, instead of just blinking in
> the headlights.

no action of that kind can change the inevitability of runout, nor change
the short term expedients for all connected networks.  so, why bother?


From stephen at sprunk.org  Mon Oct 20 20:02:24 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 20 Oct 2008 19:02:24 -0500
Subject: [arin-ppml] "Millions of Internet Addresses
	Are	Lying	Idle"(slashdot)
In-Reply-To: <194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
References: <36790.1224363677@nsa.vix.com>	<20081018212239.GA38332@ussenterprise.ufp.org>	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>	<48FA61BD.8050302@psg.com>
	<868wskuhij.fsf@seastrom.com>	<EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>
	<194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
Message-ID: <48FD1C10.2070600@sprunk.org>

Owen DeLong wrote:
> On Oct 20, 2008, at 3:58 PM, Jo Rhett wrote:
>   
>> On Oct 19, 2008, at 7:28 PM, Robert E. Seastrom wrote:
>>     
>>> the status quo is that there is an impending train wreck which is not being adequately addressed.
>>>
>>> reclamation would preserve this status quo and give some people a
>>> false sense of security.
>>>       
>> Delaying an impact does not equal a false sense of security.
>>
>> Refusing to even try is refusing to attempt to alter course.
>>     
>
> 	Attempting to reclaim the space is a bit like trying to get all the passengers to bring their hair dryers to the bow of the titanic in hopes we can melt the ice berg in time.
>   

I'm going to have to remember that analogy; it's much better than 
rearranging the deck chairs...

> 	It has nothing to do with altering course.  It's an attempt to dismantle the wall.  As crazy as that sounds, the reality is that if we put focus on reclamation, there are those who will believe that it is a solution, not a band-aid.
>   

Indeed; there is significant risk that the media would report it that 
way: no need to go to IPv6 because ARIN is reclaiming hundreds of 
millions of "wasted" IPv4 addresses.  They simply don't understand that, 
assuming the current burn rate continues, reclamation will only buy us a 
few months, maybe a year if we're really, really good at it.

> 	We don't have infinite resources. As such, reclamation is
> definitely NOT the place where our limited resources will have
> the greatest effect.
>   

I think it's still worth the effort, not because it will delay the need 
to migrate to IPv6, but because ARIN's position becomes a lot more 
defensible come Exhaustion Day.  If there are hundreds of millions of 
addresses still out there, idle or even abandoned, that's a guaranteed 
PR black eye and possibly a legal problem.  If ARIN, in the meantime, 
has done its due diligence in reclaiming what can be reclaimed and all 
addresses are actually in use, it's a lot harder for folks to criticize 
us -- or for other regulators to step in and take over.

S


From bmanning at vacation.karoshi.com  Mon Oct 20 20:06:46 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 21 Oct 2008 00:06:46 +0000
Subject: [arin-ppml] "Millions of Internet Addresses
	Are	Lying	Idle"(slashdot)
In-Reply-To: <48FD16EC.204@cisco.com>
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>
	<48FA61BD.8050302@psg.com> <868wskuhij.fsf@seastrom.com>
	<EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>
	<194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
	<48FD16EC.204@cisco.com>
Message-ID: <20081021000646.GA5086@vacation.karoshi.com.>

On Mon, Oct 20, 2008 at 04:40:28PM -0700, Eliot Lear wrote:
> Owen,
> > 	It has nothing to do with altering course.  It's an attempt
> > to dismantle the wall.  As crazy as that sounds, the reality is
> > that if we put focus on reclamation, there are those who will
> > believe that it is a solution, not a band-aid.
> >    
> 
> I think it is less likely that we would put off IPv6 deployment and more 
> likely that we could delay and possibly eliminate in some circumstances 
> multi-level NAT, if enough liquidity is realized.  That's a big if, and 
> perhaps should be the focus of research within the user base.
> 
> Eliot

	just for grins presume complete "liquidity" of the v4 pool.
	is that going to be enough?

	also note that "liquidity" presumes we have solved the reclaimation
	question - hopefully via some kind of transfer policy.

	what you describe is the v4 world in a steady state - no new addresses
	coming online and no old addresses being deleted.  the vector in
	this world is toward highly efficent utilization.  what will be
	interesting - from a research perspective - is how that will be measured.


--bill


From michael.dillon at bt.com  Tue Oct 21 05:57:17 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 21 Oct 2008 10:57:17 +0100
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
In-Reply-To: <185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08CC1EFA@E03MVZ2-UKDY.domain1.systemhost.net>

> Yes.  But there is also a lot of space attached to gum at the 
> bottom of the shoe of the network admin who was involved in 
> its assignment.
> 
> We should at least try to recover this space, instead of just 
> blinking in the headlights.

Recovering all these bits and pieces of IP address space requires
a lot of effort which costs money. For instance, imagine two
/23 subnets with 7 hosts apiece due to consolidation of servers
onto more powerful hardware. You can get back a /24 if you renumber 
both of those subnets.

But who in their right mind is going to invest money in doing this
when IPv6 is staring them right in the face. Those headlights that
you mentioned, belong to the new IPv6 Internet, and over the next
three years every ISP will have to invest money in preparation for
this new era.

--Michael Dillon


From michael.dillon at bt.com  Tue Oct 21 06:01:26 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 21 Oct 2008 11:01:26 +0100
Subject: [arin-ppml] "Millions of Internet Addresses
	AreLying	Idle"(slashdot)
In-Reply-To: <194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08CC1F11@E03MVZ2-UKDY.domain1.systemhost.net>


> 	We don't have infinite resources. As such, reclamation 
> is definitely NOT the place where our limited resources will 
> have the greatest effect.

I agree that a reclamation policy aimed at staving off IPv4 exhaustion
is a waste of our time. However, a reclamation policy aimed at the
new reality of an IPv6 Internet is worthwhile. This will be a world
where IPv4 infrastructure is steadily, if slowly, being phased out
and shutdown. At that time, there will still be many non-Internet 
users of IPv4 addresses, and it is entirely possible that they will
be used for special purposes for another 20 years or longer. In that
case our responsibility as stewards is to make sure that the bulk 
of the unneeded IPv4 address space is recovered so that it is
available for future use.

--Michael Dillon


From jrhett at svcolo.com  Tue Oct 21 14:32:35 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 11:32:35 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08CC1EFA@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC08CC1EFA@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <0447ED5D-8523-43E9-A0C0-DF3765BF0149@svcolo.com>

On Oct 21, 2008, at 2:57 AM, <michael.dillon at bt.com> <michael.dillon at bt.com 
 > wrote:
> Recovering all these bits and pieces of IP address space requires
> a lot of effort which costs money. For instance, imagine two
> /23 subnets with 7 hosts apiece due to consolidation of servers
> onto more powerful hardware. You can get back a /24 if you renumber
> both of those subnets.

I'm talking about /12s and /16s which are lying completely idle and  
unused.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Tue Oct 21 14:36:15 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 11:36:15 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>
	<48FA61BD.8050302@psg.com> <868wskuhij.fsf@seastrom.com>
	<EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>
	<194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
Message-ID: <6A36785F-33A0-40F9-878F-A3D80CBDCBF0@svcolo.com>

On Oct 20, 2008, at 4:35 PM, Owen DeLong wrote:
> 	Attempting to reclaim the space is a bit like trying to get all
> the passengers to bring their hair dryers to the bow of the titanic
> in hopes we can melt the ice berg in time.

Sorry, I'm a factual guy.  Hyperbole like this does nothing to advance  
the conversation.

> 	It has nothing to do with altering course.  It's an attempt
> to dismantle the wall.  As crazy as that sounds, the reality is
> that if we put focus on reclamation, there are those who will
> believe that it is a solution, not a band-aid.

Your first statement makes no sense -- delay does not equal prevent.

> 	We don't have infinite resources. As such, reclamation is
> definitely NOT the place where our limited resources will have
> the greatest effect.


I'm sorry, but how exactly is ARIN in a position to help the IPv6  
migration?  Show me exactly which resources would be removed from IPv6  
migration to do something about reclamation.

This is not an EITHER / OR scenario.  There is no battle over  
resources here.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Tue Oct 21 14:39:40 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 11:39:40 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <87466.1224546974@nsa.vix.com>
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>
	<87466.1224546974@nsa.vix.com>
Message-ID: <F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>

>> We should at least try to recover this space, instead of just  
>> blinking in
>> the headlights.

On Oct 20, 2008, at 4:56 PM, Paul Vixie wrote:
> no action of that kind can change the inevitability of runout, nor  
> change
> the short term expedients for all connected networks.  so, why bother?


I saw a lot of projections about what bigger providers would be forced  
to do in short-term runout, prior to wide availability of IPv6.  Not a  
single person in the room said that multi-level provider-wide NATs  
would make the world a better place.

The amount of effort involved in reclaiming completely unused blocks  
is <= one full time person for a year.  That's a small cost for an  
extension.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Tue Oct 21 14:40:29 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 11:40:29 -0700
Subject: [arin-ppml] "Millions of Internet Addresses
	Are	Lying	Idle"(slashdot)
In-Reply-To: <48FD1C10.2070600@sprunk.org>
References: <36790.1224363677@nsa.vix.com>	<20081018212239.GA38332@ussenterprise.ufp.org>	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>	<48FA61BD.8050302@psg.com>
	<868wskuhij.fsf@seastrom.com>	<EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>
	<194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
	<48FD1C10.2070600@sprunk.org>
Message-ID: <904868EF-A438-4915-A36F-ED8C0DC1371C@svcolo.com>

On Oct 20, 2008, at 5:02 PM, Stephen Sprunk wrote:
> I think it's still worth the effort, not because it will delay the  
> need to migrate to IPv6, but because ARIN's position becomes a lot  
> more defensible come Exhaustion Day.  If there are hundreds of  
> millions of addresses still out there, idle or even abandoned,  
> that's a guaranteed PR black eye and possibly a legal problem.  If  
> ARIN, in the meantime, has done its due diligence in reclaiming what  
> can be reclaimed and all addresses are actually in use, it's a lot  
> harder for folks to criticize us -- or for other regulators to step  
> in and take over.


Bingo.  Very well said.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From michael at rancid.berkeley.edu  Tue Oct 21 14:43:55 2008
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 21 Oct 2008 11:43:55 -0700
Subject: [arin-ppml] "Millions of Internet Addresses
	Are	Lying	Idle"(slashdot)
In-Reply-To: <6A36785F-33A0-40F9-878F-A3D80CBDCBF0@svcolo.com>
References: <36790.1224363677@nsa.vix.com>	<20081018212239.GA38332@ussenterprise.ufp.org>	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>	<48FA61BD.8050302@psg.com>
	<868wskuhij.fsf@seastrom.com>	<EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>	<194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
	<6A36785F-33A0-40F9-878F-A3D80CBDCBF0@svcolo.com>
Message-ID: <48FE22EB.3050204@rancid.berkeley.edu>

On 10/21/08 11:36, Jo Rhett wrote:

> I'm sorry, but how exactly is ARIN in a position to help the IPv6  
> migration?  Show me exactly which resources would be removed from IPv6  
> migration to do something about reclamation.
> 
> This is not an EITHER / OR scenario.  There is no battle over  
> resources here.

You mentioned that big blocks of idle address space should be reclaimed, 
but what is it that you are asking ARIN to do specifically?  Is this a 
policy issue or should staff be directed to do something?  Should they 
scan address ranges and try to find large unused blocks and contact the 
WHOIS POC for the block?

Also, should unused space in the ARIN region, especially unused legacy 
space, be reclaimed and kept by ARIN or should it go back to IANA?


From vixie at isc.org  Tue Oct 21 14:54:32 2008
From: vixie at isc.org (Paul Vixie)
Date: Tue, 21 Oct 2008 18:54:32 +0000
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: Your message of "Tue, 21 Oct 2008 11:39:40 MST."
	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com> 
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>
	<87466.1224546974@nsa.vix.com>
	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com> 
Message-ID: <36202.1224615272@nsa.vix.com>

> > no action of that kind can change the inevitability of runout, nor
> > change the short term expedients for all connected networks.  so, why
> > bother?
> 
> I saw a lot of projections about what bigger providers would be forced to
> do in short-term runout, prior to wide availability of IPv6.  Not a
> single person in the room said that multi-level provider-wide NATs would
> make the world a better place.

and yet that is also inevitable.  in the theoretical case you cite where some
currently unused space is put into use (some say by reclaimation, others say
by return, others by a "market") it changes only the date at which runout will
occur, not the inevitability of such a runout.  sooner or later we get runout
and it will bring with it deaggregation, double/triple NAT, and panicked IPv6.

> The amount of effort involved in reclaiming completely unused blocks is
> <= one full time person for a year.  That's a small cost for an
> extension.

i fear that at this point the stage is set by monetary expecations, and those
address blocks which could if recirculated set back the runout date by months
or at most a year, will be closely held by those hoping that a market appears.
to expect that one full time person working less than one year would be able
to counter and/or reset that expectation seems incredibly unrealistic.

this is why to me the most salient of underexposed positions among those with
runout proposals is: do they consider IPv6 inevitable, or do they think that
some combination of deaggregation plus NAT plus their proposal could make IPv4
last forever or at least last until something other than IPv6 can develope?
i really think the community deserves to know/evaluate/choose *that* agenda.


From sleibrand at internap.com  Tue Oct 21 15:10:45 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 21 Oct 2008 12:10:45 -0700
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <36202.1224615272@nsa.vix.com>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com>
Message-ID: <48FE2935.9010109@internap.com>

Paul Vixie wrote:

> this is why to me the most salient of underexposed positions among those with
> runout proposals is: do they consider IPv6 inevitable, or do they think that
> some combination of deaggregation plus NAT plus their proposal could make IPv4
> last forever or at least last until something other than IPv6 can develope?
> i really think the community deserves to know/evaluate/choose *that* agenda.

My own opinion is that whatever transfer/reclamation policy we implement, 
it will simply smooth out and mitigate some of the negative effects of an 
abrupt transition to IPv6.  To put it another way, it makes it possible to 
extend the dual-stack phase of the v4-v6 transition so that we aren't 
forcing some organizations to turn off v4 before everyone else has turned 
on v6.

The precise timing of the various phases will depend on a lot of factors, 
but I don't foresee sticking with v4 for another decade as even remotely 
viable.

-Scott


From jrhett at svcolo.com  Tue Oct 21 15:25:30 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 12:25:30 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <36202.1224615272@nsa.vix.com>
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>
	<87466.1224546974@nsa.vix.com>
	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com>
Message-ID: <B17175B1-7411-4B63-85A8-E8BF8335845D@svcolo.com>

On Oct 21, 2008, at 11:54 AM, Paul Vixie wrote:
> to expect that one full time person working less than one year would  
> be able
> to counter and/or reset that expectation seems incredibly unrealistic.


As demonstrated by the absolute zero effort put into this by ARIN to  
date.  Somewhere between (a) oh god, let's not offend the legacy  
holders and (b) we can't win against the legacy holders - ARIN sits  
idle.  What is amusing is that not only is not all idle space in the  
hands of legacy holders (most of what I personally know about was  
assigned under the RSA) but not all legacy holders are even aware of  
the transfer proposals.

As Stephen said so much better than I did, failing to even attempt  
this will guarantee the failure of ARIN.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From cgrundemann at gmail.com  Tue Oct 21 15:31:40 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 21 Oct 2008 13:31:40 -0600
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
In-Reply-To: <48FE22EB.3050204@rancid.berkeley.edu>
References: <36790.1224363677@nsa.vix.com>
	<20081018212239.GA38332@ussenterprise.ufp.org>
	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>
	<48FA61BD.8050302@psg.com> <868wskuhij.fsf@seastrom.com>
	<EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>
	<194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
	<6A36785F-33A0-40F9-878F-A3D80CBDCBF0@svcolo.com>
	<48FE22EB.3050204@rancid.berkeley.edu>
Message-ID: <443de7ad0810211231r2f71b792r710d55bf4ef98687@mail.gmail.com>

On Tue, Oct 21, 2008 at 12:43 PM, Michael Sinatra
<michael at rancid.berkeley.edu> wrote:
> You mentioned that big blocks of idle address space should be reclaimed,
> but what is it that you are asking ARIN to do specifically?  Is this a
> policy issue or should staff be directed to do something?  Should they
> scan address ranges and try to find large unused blocks and contact the
> WHOIS POC for the block?

My $.02 is that this process could start by verifying the POCs in
WHOIS.  Then ARIN staff can focus initially on "orphaned" IP space
(blocks with no verifiable POC).  I am not suggesting that all IP
space with out a valid POC is necessarily or inherently abandoned but
I do think that it is an area that may well prove to have much low
hanging fruit in regards to reclamation.

We may need a specific policy to address under what conditions an
address block can be considered abandoned or otherwise "reclaimable."
We may also want or need a policy (such as my proposed "Annual WHOIS
POC Validation") to facilitate and/or encourage ARIN staff to do the
verifying.

> Also, should unused space in the ARIN region, especially unused legacy
> space, be reclaimed and kept by ARIN or should it go back to IANA?
> _______________________________________________
> 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.chrisgrundemann.com
www.linkedin.com/in/cgrundemann


From vixie at isc.org  Tue Oct 21 15:33:45 2008
From: vixie at isc.org (Paul Vixie)
Date: Tue, 21 Oct 2008 19:33:45 +0000
Subject: [arin-ppml] "Millions of Internet Addresses
	AreLying	Idle"(slashdot)
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08CC1F11@E03MVZ2-UKDY.domain1.systemhost.net>
	(michael dillon's message of "Tue\, 21 Oct 2008 11\:01\:26 +0100")
References: <194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
	<C0F2465B4F386241A58321C884AC7ECC08CC1F11@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <g38wshspye.fsf@nsa.vix.com>

michael.dillon at bt.com writes:

> I agree that a reclamation policy aimed at staving off IPv4 exhaustion is
> a waste of our time. However, a reclamation policy aimed at the new
> reality of an IPv6 Internet is worthwhile. This will be a world where
> IPv4 infrastructure is steadily, if slowly, being phased out and
> shutdown. At that time, there will still be many non-Internet users of
> IPv4 addresses, and it is entirely possible that they will be used for
> special purposes for another 20 years or longer. In that case our
> responsibility as stewards is to make sure that the bulk of the unneeded
> IPv4 address space is recovered so that it is available for future use.

can you explain why someone would stop using IPv4 if it still reached the
entire set of endpoints they wanted to exchange traffic with?  or failing
that can you explain why someone would switch to IPv6-only if it would
limit the set of endpoints they could exchange traffic with?

right now there's V4-only and dual-stack but there is no V6-only since it
offers inadequate connectivity.  we can expect a lot more dual-stack as we
approach and then pass runout day.  some day most of us expect the cost of
V6-only (which will be some moderate loss of connectivity) to be lower than
the cost of continuing with (which will be double/triple NAT, high prices
for leasing IPv4 RTU [perhaps as bundled with carriage], and router cost
and heat for the pea-sized gravel that the IPv4 routing table will become).

but noone i know expects that there will ever be a time when one set of
users is releasing IPv4 because they're happy with IPv6-only and IPv4-NAT,
while another set of users still needs to grow their IPv4.  unless it's
you, that is.  i'd like to hear more about this world view.
-- 
Paul Vixie


From vixie at isc.org  Tue Oct 21 15:42:28 2008
From: vixie at isc.org (Paul Vixie)
Date: Tue, 21 Oct 2008 19:42:28 +0000
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: Your message of "Tue, 21 Oct 2008 12:25:30 MST."
	<B17175B1-7411-4B63-85A8-E8BF8335845D@svcolo.com> 
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>
	<87466.1224546974@nsa.vix.com>
	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com>
	<B17175B1-7411-4B63-85A8-E8BF8335845D@svcolo.com> 
Message-ID: <42862.1224618148@nsa.vix.com>

> From: Jo Rhett <jrhett at svcolo.com>
> 
> On Oct 21, 2008, at 11:54 AM, Paul Vixie wrote:
> > to expect that one full time person working less than one year would be
> > able to counter and/or reset that expectation seems incredibly
> > unrealistic.
> 
> As demonstrated by the absolute zero effort put into this by ARIN to
> date.  Somewhere between (a) oh god, let's not offend the legacy holders
> and (b) we can't win against the legacy holders - ARIN sits idle.

let me be clear that even if the above-quoted text from me was the arin
board's view (of which it probably does not but in any case i would not
be the spokesman), then the idleness of which you speak would still be
due to the staff's and board's responsibility to act on approved policy
rather than on our own views.  if you want arin to become non-idle toward
reclaimation, then you can follow the IRPEP, and if the ARIN AC puts forth
a policy in this area and the board certifies that the IRPEP was followed,
then the staff will become non-idle in the way you're measuring here.

> What is amusing is that not only is not all idle space in the hands of
> legacy holders (most of what I personally know about was assigned under
> the RSA) but not all legacy holders are even aware of the transfer
> proposals.

more outreach would be a wonderful thing.  please suggest ways that ARIN can
do more to tell all legacy holders about these transfer policies.

> As Stephen said so much better than I did, failing to even attempt  
> this will guarantee the failure of ARIN.

there are many things that might happen.  we might end up with
double/triple NAT or a black market or rapid IPv6 deployment or the death
of ARIN.  but there is only one thing that absolutely will happen.  IPv4
space will run out.


From tme at multicasttech.com  Tue Oct 21 14:56:16 2008
From: tme at multicasttech.com (Marshall Eubanks)
Date: Tue, 21 Oct 2008 14:56:16 -0400
Subject: [arin-ppml] "Millions of Internet Addresses
	Are	Lying	Idle"(slashdot)
In-Reply-To: <904868EF-A438-4915-A36F-ED8C0DC1371C@svcolo.com>
References: <36790.1224363677@nsa.vix.com>	<20081018212239.GA38332@ussenterprise.ufp.org>	<EACF8B735E9CBA4B8BAF9E4165D03087531C88@ex1.cait.wustl.edu>	<48FA61BD.8050302@psg.com>
	<868wskuhij.fsf@seastrom.com>	<EAEEEDBA-D251-45EA-A279-B4AB11C2521F@svcolo.com>
	<194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
	<48FD1C10.2070600@sprunk.org>
	<904868EF-A438-4915-A36F-ED8C0DC1371C@svcolo.com>
Message-ID: <213D4852-CE86-48B0-B931-4BFDA2F4DDDE@multicasttech.com>



On Oct 21, 2008, at 2:40 PM, Jo Rhett wrote:

> On Oct 20, 2008, at 5:02 PM, Stephen Sprunk wrote:
>> I think it's still worth the effort, not because it will delay the
>> need to migrate to IPv6, but because ARIN's position becomes a lot
>> more defensible come Exhaustion Day.  If there are hundreds of
>> millions of addresses still out there, idle or even abandoned,
>> that's a guaranteed PR black eye and possibly a legal problem.  If
>> ARIN, in the meantime, has done its due diligence in reclaiming what
>> can be reclaimed and all addresses are actually in use, it's a lot
>> harder for folks to criticize us -- or for other regulators to step
>> in and take over.
>
>

I, too, find this reasoning to be fairly compelling.

Regards
Marshall

> Bingo.  Very well said.
>
> -- 
> 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.



From owen at delong.com  Tue Oct 21 16:05:12 2008
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Oct 2008 13:05:12 -0700
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <48FE2935.9010109@internap.com>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com> <48FE2935.9010109@internap.com>
Message-ID: <6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>


On Oct 21, 2008, at 12:10 PM, Scott Leibrand wrote:

> Paul Vixie wrote:
>
>> this is why to me the most salient of underexposed positions among  
>> those with
>> runout proposals is: do they consider IPv6 inevitable, or do they  
>> think that
>> some combination of deaggregation plus NAT plus their proposal  
>> could make IPv4
>> last forever or at least last until something other than IPv6 can  
>> develope?
>> i really think the community deserves to know/evaluate/choose  
>> *that* agenda.
>
> My own opinion is that whatever transfer/reclamation policy we  
> implement,
> it will simply smooth out and mitigate some of the negative effects  
> of an
> abrupt transition to IPv6.  To put it another way, it makes it  
> possible to
> extend the dual-stack phase of the v4-v6 transition so that we aren't
> forcing some organizations to turn off v4 before everyone else has  
> turned
> on v6.
>
You do realize that's a pipe dream, right?  There simply isn't enough  
IPv4
and time to make that realistic, and, the patterns of human behavior  
to date
suggest that  a time extension will be used primarily to procrastinate  
v6
deployment rather than achieve it.

Owen



From jrhett at svcolo.com  Tue Oct 21 16:15:43 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 13:15:43 -0700
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com> <48FE2935.9010109@internap.com>
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
Message-ID: <E8F93A01-4C0D-4747-BCB7-C5C6066EA69A@svcolo.com>

On Oct 21, 2008, at 1:05 PM, Owen DeLong wrote:
> the patterns of human behavior to date
> suggest that  a time extension will be used primarily to procrastinate
> v6 deployment rather than achieve it.


Owen you routinely argue that it's not ARIN's job to do anything about  
the routing table size.  However, you are suggesting that it is ARIN's  
job to make people act more proactively?  One of these two is possible  
(albeit in a limited fashion).  What you are proposing is a pipe dream.

Trying to speed up the car to ram it into the wall even faster and  
harder isn't something that is in anyone's interest.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From michael.dillon at bt.com  Tue Oct 21 16:16:41 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 21 Oct 2008 21:16:41 +0100
Subject: [arin-ppml] "Millions of Internet
	AddressesAreLying	Idle"(slashdot)
In-Reply-To: <g38wshspye.fsf@nsa.vix.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08D33E9C@E03MVZ2-UKDY.domain1.systemhost.net>

> can you explain why someone would stop using IPv4 if it still 
> reached the entire set of endpoints they wanted to exchange 
> traffic with?

That is precisely my point. If someone is using IPv4 addressing
in a private internetwork, or to run their MPLS core network,
they have a restricted set of endpoints with which they want
to exchange traffic. In these sorts of scenarios it is possible
that many organizations will want to avoid migrating away
from IPv4. This is only realistic because these are
LIMITED GROWTH scenarios. In the general case of the public
Internet, growth is continuous with no clear limits in sight.
As the public Internet transitions to IPv6, the IP address
stewards should make sure they keep track of IPv4 blocks that
are freed up, because there could be many, many years left
in IPv4 internetworking.

> right now there's V4-only and dual-stack but there is no 
> V6-only since it offers inadequate connectivity.

That's only true on the public Internet and only if you
discount the bits of IPv6 at the edge which use 
transition/tunneling mechanisms to reach the v4 Internet.

> we can 
> expect a lot more dual-stack as we approach and then pass 
> runout day.  some day most of us expect the cost of V6-only 
> (which will be some moderate loss of connectivity) to be 
> lower than the cost of continuing with (which will be 
> double/triple NAT, high prices for leasing IPv4 RTU [perhaps 
> as bundled with carriage], and router cost and heat for the 
> pea-sized gravel that the IPv4 routing table will become).

I don't believe that dual-stack will be used for very long 
outside of ISP core networks. Businesses are used to technology
refresh cycles, and in a couple of years we will be coming out
of the financial crisis with pent up demand, IPv6 services 
being announce every day, and a pretty clear vision of the 
road ahead. Many enterprises will go to pure IPv6 networks
wherever possible with v4 only running on legacy services 
that are being driven until they drop. Similarly, when
consumers are offered IPv6 broadband it will have v6 gateways
bundled in. In 4 years I am already on my second broadband
gateway device and I would have been on the 4th if I had kept
up with all the upgrade offers.

> but noone i know expects that there will ever be a time when 
> one set of users is releasing IPv4 because they're happy with 
> IPv6-only and IPv4-NAT, while another set of users still 
> needs to grow their IPv4.  unless it's you, that is.  i'd 
> like to hear more about this world view.

I am not sure that there will be a set of IPv4 users that needs
to grow their usage, but I do know that there are an awful lot
more ways of using IPv4 technology than most ISPs are aware of.
Embedded systems, factory automation, spacecraft. Some countries
might profit by sticking with v4 and using our castoff devices,
in the same way some African countries reuse our eyeglasses.
I can't predict this, but I think it is reasonable to be prudent
until we can see that IPv4 really is defunct.

--Michael Dillon


From owen at delong.com  Tue Oct 21 16:19:21 2008
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Oct 2008 13:19:21 -0700
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <E8F93A01-4C0D-4747-BCB7-C5C6066EA69A@svcolo.com>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com> <48FE2935.9010109@internap.com>
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
	<E8F93A01-4C0D-4747-BCB7-C5C6066EA69A@svcolo.com>
Message-ID: <0A8DB06B-A486-413A-9022-A11BEA40A39A@delong.com>


On Oct 21, 2008, at 1:15 PM, Jo Rhett wrote:

> On Oct 21, 2008, at 1:05 PM, Owen DeLong wrote:
>> the patterns of human behavior to date
>> suggest that  a time extension will be used primarily to  
>> procrastinate
>> v6 deployment rather than achieve it.
>
>
> Owen you routinely argue that it's not ARIN's job to do anything  
> about the routing table size.  However, you are suggesting that it  
> is ARIN's job to make people act more proactively?  One of these two  
> is possible (albeit in a limited fashion).  What you are proposing  
> is a pipe dream.
>
> Trying to speed up the car to ram it into the wall even faster and  
> harder isn't something that is in anyone's interest.

I'm not trying to accelerate the car. Just pointing out that sticking  
our feet out through
the door and yelling stop won't decelerate it significantly either.

Owen



From rlc at usfamily.net  Tue Oct 21 15:58:23 2008
From: rlc at usfamily.net (Ron Cleven)
Date: Tue, 21 Oct 2008 14:58:23 -0500 (CDT)
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"	(slashdot)
In-Reply-To: <36202.1224615272@nsa.vix.com>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com>
Message-ID: <48FE345D.5030200@usfamily.net>

I think this whole line of conversation is missing the point.  One has 
to honestly and simply discuss the reasons that IPv6 has not yet taken 
hold yet, and why it will not have taken hold in 12 months from now. 
Until and unless someone can describe, in simple layman's terms, a 
rational transition plan to IPv6, I don't see it happening.

1) What are the largest barriers that will prevent widescale adoption of 
IPv6 in the next 12 months or whatever timeframe (the biggest one seems 
to be we haven't hit the wall yet, in spite of idiotic management of IP 
resources)?

2) How can the transition be simplified?

3) Most importantly, how can the transition be incentified?

There are a lot of smart people on this list, but you need to step back 
from your techno-jargon and put your collective brains to use to deal 
with practical issues.

You could start incentifying the transition to IPv6 by removing the 
"economies of scale" on IPv4 allocations (which provides precisely the 
wrong incentive, talk about STUPID policy!).  The annual renewal of all 
IPv4 allocations should cost the same per ip address, whether you have 
256 ip's or 16 million.  And, yeah, I'm tired of hearing from all those 
arrogant entities who happened to acquire their addresses before ARIN 
had any of their ducks in a row.  Get over it.  This should be a 
technical battle, not a legal one.

Anyway, once the renewal costs were equalized, then ARIN, et al, should 
ratchet up those annual renewal costs until IPv4 address space usage 
reaches steady-state.  This would not solve the transition issues, but 
it would provide the economic incentive for all you really smart people 
to figure it out.






Paul Vixie wrote:
>>>no action of that kind can change the inevitability of runout, nor
>>>change the short term expedients for all connected networks.  so, why
>>>bother?
>>
>>I saw a lot of projections about what bigger providers would be forced to
>>do in short-term runout, prior to wide availability of IPv6.  Not a
>>single person in the room said that multi-level provider-wide NATs would
>>make the world a better place.
> 
> 
> and yet that is also inevitable.  in the theoretical case you cite where some
> currently unused space is put into use (some say by reclaimation, others say
> by return, others by a "market") it changes only the date at which runout will
> occur, not the inevitability of such a runout.  sooner or later we get runout
> and it will bring with it deaggregation, double/triple NAT, and panicked IPv6.
> 
> 
>>The amount of effort involved in reclaiming completely unused blocks is
>><= one full time person for a year.  That's a small cost for an
>>extension.
> 
> 
> i fear that at this point the stage is set by monetary expecations, and those
> address blocks which could if recirculated set back the runout date by months
> or at most a year, will be closely held by those hoping that a market appears.
> to expect that one full time person working less than one year would be able
> to counter and/or reset that expectation seems incredibly unrealistic.
> 
> this is why to me the most salient of underexposed positions among those with
> runout proposals is: do they consider IPv6 inevitable, or do they think that
> some combination of deaggregation plus NAT plus their proposal could make IPv4
> last forever or at least last until something other than IPv6 can develope?
> i really think the community deserves to know/evaluate/choose *that* agenda.
> _______________________________________________


From michael.dillon at bt.com  Tue Oct 21 16:21:58 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 21 Oct 2008 21:21:58 +0100
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08D33E9F@E03MVZ2-UKDY.domain1.systemhost.net>

>  To put it another way, it 
> > makes it possible to extend the dual-stack phase of the v4-v6 
> > transition so that we aren't forcing some organizations to 
> turn off v4 
> > before everyone else has turned on v6.
> >
> You do realize that's a pipe dream, right?  There simply isn't enough
> IPv4
> and time to make that realistic, 

There are also sharks circling around. Some ISPs have MPLS in their
core and they don't need to dual stack. They can grow their v6 
infrastructure at the edges using 6PE and therefore they need
fewer IPv4 addresses overall to sustain growth.

If you don't have an MPLS core, and can't transition to one,
then it would be risky to rely on dual-stack when one half
of the addresses that you need, may not be available any more.

There are other, more creative ways of adding IPv6 at the edges
that roughly emulates what 6PE does. It is safer to only dual-stack
a fixed portion of your core, and use it to connect IPv6 islands
at your edge. The IPv6 islands can then grow without the need for
additional v4 addresses. Dual-stack is far from a panacea.

--Michael Dillon







From Lee at dilkie.com  Tue Oct 21 16:23:09 2008
From: Lee at dilkie.com (Lee Dilkie)
Date: Tue, 21 Oct 2008 16:23:09 -0400
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>	<36202.1224615272@nsa.vix.com>
	<48FE2935.9010109@internap.com>
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
Message-ID: <48FE3A2D.2030103@dilkie.com>



Owen DeLong wrote:

<snipped>
>
> You do realize that's a pipe dream, right?  There simply isn't enough  
> IPv4
> and time to make that realistic, and, the patterns of human behavior  
> to date
> suggest that  a time extension will be used primarily to procrastinate  
> v6
> deployment rather than achieve it.
>
>
>   
Amen to that. If anything shows our true colours, it's our non-response
unless we have a crisis to deal with.


From jrhett at svcolo.com  Tue Oct 21 16:31:03 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 13:31:03 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying Idle"
	(slashdot)
In-Reply-To: <42862.1224618148@nsa.vix.com>
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>
	<87466.1224546974@nsa.vix.com>
	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com>
	<B17175B1-7411-4B63-85A8-E8BF8335845D@svcolo.com>
	<42862.1224618148@nsa.vix.com>
Message-ID: <20B8811F-FC4A-4310-A829-3AD763B0792C@svcolo.com>

On Oct 21, 2008, at 12:42 PM, Paul Vixie wrote:
> let me be clear that even if the above-quoted text from me was the  
> arin
> board's view (of which it probably does not but in any case i would  
> not
> be the spokesman), then the idleness of which you speak would still be
> due to the staff's and board's responsibility to act on approved  
> policy
> rather than on our own views.

Honestly, read the RSA.   It very clearly says that if the POC data is  
not kept up to date, it's a violation of contract.  Asking ARIN to  
validate POC data for RSA contractees is like reminding the teacher to  
show up in class.  It is function 1 of their job.  Why aren't they  
doing it?

> if you want arin to become non-idle toward
> reclaimation, then you can follow the IRPEP, and if the ARIN AC puts  
> forth
> a policy in this area and the board certifies that the IRPEP was  
> followed,
> then the staff will become non-idle in the way you're measuring here.

You often mention not wasting effort on lost causes.  I sat there for  
2 days and watched several very useful and long overdue efforts get  
completely shut down based not on their own merits (there was no  
discussion of their merits), but because of protectionism of the  
legacy holders "rights".  Rights which were never given in the first  
place, and were well understood by all parties at the time to not mean  
ownership.  Paul, you were there getting allocations in the 1980s just  
like I was and you know this as well as I do.

The only other very strong motivational factor I've seen witnessed by  
ARIN board and AC was an almost apparently desire to slam IPv6 down  
everyone's throat as the only apparent way to solve the legacy space  
problems.

Both of these are small-minded policies without any apparent awareness  
of the impact on people and businesses worldwide.  During an economic  
downturn, even.  I can easily recognize this kind of reasoning  
displayed often in small membership societies, local governments, etc.

Given what I've witnessed in action there, there's no reason to even  
attempt to participate beyond minor definition fixes which I have  
already committed to help out with.  I'm not given to pissing upwind.   
It's never worked very well for me in the past.

(I will agree that this conversation is likely pissing upwind, and I'm  
done with it after this message)

>> What is amusing is that not only is not all idle space in the hands  
>> of
>> legacy holders (most of what I personally know about was assigned  
>> under
>> the RSA) but not all legacy holders are even aware of the transfer
>> proposals.
>
> more outreach would be a wonderful thing.  please suggest ways that  
> ARIN can
> do more to tell all legacy holders about these transfer policies.

Is that a benefit?  I'm suggesting that ARIN reach out and ask people  
to return unused space.  How much effort would that take?  Seriously?   
I'd also like to point out that a lot of people said exactly the same  
thing at the microphone.

>> As Stephen said so much better than I did, failing to even attempt
>> this will guarantee the failure of ARIN.
>
> there are many things that might happen.  we might end up with
> double/triple NAT or a black market or rapid IPv6 deployment or the  
> death
> of ARIN.  but there is only one thing that absolutely will happen.   
> IPv4
> space will run out.

I never doubted that.  I asked if making it run out faster was useful  
to anyone.  Really.

A minimal effort which could have significant useful impact is being  
avoided for reasons explained only by "it might let people  
procrastinate".

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550


From michael.dillon at bt.com  Tue Oct 21 16:34:32 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 21 Oct 2008 21:34:32 +0100
Subject: [arin-ppml] "Millions of Internet Addresses Are
	LyingIdle"	(slashdot)
In-Reply-To: <48FE345D.5030200@usfamily.net>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08D33EAD@E03MVZ2-UKDY.domain1.systemhost.net>

> Until and unless someone can describe, in simple layman's 
> terms, a rational transition plan to IPv6, I don't see it happening.

The laymen have already transitioned to IPv6.

> 1) What are the largest barriers that will prevent widescale 
> adoption of
> IPv6 in the next 12 months or whatever timeframe

ISPs.

> 2) How can the transition be simplified?

It can't. Changing a big network that carries millions of dollars
worth of traffic every day is never simple.

> 3) Most importantly, how can the transition be incentified?

By pushing requests up the supply chain which is one thing that
governments are trying to do by mandating that publicly funded 
agencies begin migrating to IPv6.

> There are a lot of smart people on this list, but you need to 
> step back from your techno-jargon and put your collective 
> brains to use to deal with practical issues.

Why? It might be good for society if lots of ISPs go bankrupt
because they hit a brick wall and are unable to grow their
networks two to three years from now, just as the economic
recovery picks up steam. We don't need everybody to do the
right thing. In fact, if only a dozen national/regional ISPs
do the right thing, it will probably be good enough because
they will snap up the assets of their competition in three 
years and roll out more of their successful IPv6 deployment.

> over it.  This should be a technical battle, not a legal one.

Wrong story. This is ARIN, not a place for technical battles,
but a place for cost-recovery, stewardship, and prudent 
policies.

> Anyway, once the renewal costs were equalized, then ARIN, et 
> al, should ratchet up those annual renewal costs until IPv4 
> address space usage reaches steady-state.  This would not 
> solve the transition issues, but it would provide the 
> economic incentive for all you really smart people to figure it out.

I fear that such action would simply create huge economic incentives
for someone to privatize ARIN in such a way that they make a huge
personal fortune from the piles of cash which you want to send in.

This is getting more like a Slashdot thread every second...

--Michael Dillon



From farmer at umn.edu  Tue Oct 21 16:35:30 2008
From: farmer at umn.edu (David Farmer)
Date: Tue, 21 Oct 2008 15:35:30 -0500
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
In-Reply-To: <904868EF-A438-4915-A36F-ED8C0DC1371C@svcolo.com>
References: <36790.1224363677@nsa.vix.com>, <48FD1C10.2070600@sprunk.org>,
	<904868EF-A438-4915-A36F-ED8C0DC1371C@svcolo.com>
Message-ID: <48FDF6C2.1688.4795C28@farmer.umn.edu>

On 21 Oct 2008 Jo Rhett wrote:

> On Oct 20, 2008, at 5:02 PM, Stephen Sprunk wrote:
> > I think it's still worth the effort, not because it will delay the  
> > need to migrate to IPv6, but because ARIN's position becomes a lot  
> > more defensible come Exhaustion Day.  If there are hundreds of  
> > millions of addresses still out there, idle or even abandoned,  
> > that's a guaranteed PR black eye and possibly a legal problem.  If  
> > ARIN, in the meantime, has done its due diligence in reclaiming what  
> > can be reclaimed and all addresses are actually in use, it's a lot  
> > harder for folks to criticize us -- or for other regulators to step  
> > in and take over.
> 
> 
> Bingo.  Very well said.

I must agree that ARIN must be able to demonstrate due diligence in 
reclaiming what can reasonably be reclaimed.  If not, why would anyone 
take ARIN seriously when we says the transition to IPv6 is the only way 
forward in the long run.  That said, we need to be very clear in pointing out 
this is only the most temporary reprieve and is only being done to show 
good faith in ARIN's stewardship role for IPv4.

At the very least all the low hanging fruit needs to be reclaimed (and all the 
dried up prunes and raisins need to be swept up off the floor too, to extend 
the metaphor.)    An important balance needs to be struck here, enough 
effort to show good faith in reclaiming the obvious stuff, without making futile 
heroic efforts that in the end will only divert us from the transition to IPV6. 

And unfortunately, I believe this means dealing with the questions of Legacy 
Resource holders.  I believe that we need to make it clear to Legacy 
Holders, that any resources that are not in use must be reclaimed one way 
or another.  But again there is a balance needed here too.  How much effort 
as a community do we want Legacy holders to put in to reclamation vs. 
transitioning to IPv6?

I'm trying to figure out how to find this balance within my own organization.  
Trust me, this is not a trivial thing to do for an organization that has been 
using Internet number resources for more than 20 years.

Actually, I think what is requested in 10a of the LRSA is actually very 
reasonable.  Basically it requests that Legacy holders, "voluntarily return to 
ARIN the portion of all Included Number Resources that it is unlikely to need 
over the next 10 years."  It also might be a reasonable to expect in 
exchange for retaining these resources that Legacy holders help lead the 
way in the transition to IPv6.  Placing an expectation that to retain the 
benefits of early adoption of IPv4 that there is an expectation of early 
adoption of IPv6 could also be reasonable and beneficial to the community 
as a whole.

We need to be a community of  creative and critical thinkers right now.  We 
must examine all of our orthodoxies.  We must reinforce the orthodoxy that 
is still valid and dispose of those that are not in this time of change.


=======================================================
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 alan at batie.org  Tue Oct 21 16:47:01 2008
From: alan at batie.org (Alan Batie)
Date: Tue, 21 Oct 2008 13:47:01 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <48FDF6C2.1688.4795C28@farmer.umn.edu>
References: <36790.1224363677@nsa.vix.com>, <48FD1C10.2070600@sprunk.org>,
	<904868EF-A438-4915-A36F-ED8C0DC1371C@svcolo.com>
	<48FDF6C2.1688.4795C28@farmer.umn.edu>
Message-ID: <48FE3FC5.2040200@batie.org>

David Farmer wrote:

> And unfortunately, I believe this means dealing with the questions of Legacy 
> Resource holders.  I believe that we need to make it clear to Legacy 
> Holders, that any resources that are not in use must be reclaimed one way 
> or another.

As someone who has the use of a legacy portable class c, I'll pipe up
very briefly:  I tried.  My useage has dropped to the point where I
don't really need it any more, so I got a non-portable block from my
hosting facility.  It was on so many spam s**tlists that it was
unuseable, despite the fact that the spam feedback reports I was getting
were over a year old.  I had to switch back and need to let the dust
settle (and users cool down) before trying again, if I should decide
that it's worth the effort to try a different one.

I *am* in the process of bringing up ipv6 though, fwiw...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3263 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081021/c34ecfcb/attachment.bin>

From farmer at umn.edu  Tue Oct 21 16:57:23 2008
From: farmer at umn.edu (David Farmer)
Date: Tue, 21 Oct 2008 15:57:23 -0500
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
References: <36790.1224363677@nsa.vix.com>, <48FE2935.9010109@internap.com>,
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
Message-ID: <48FDFBE3.31846.48D6483@farmer.umn.edu>

On 21 Oct 2008 Owen DeLong wrote:

> On Oct 21, 2008, at 12:10 PM, Scott Leibrand wrote:
> 
> > My own opinion is that whatever transfer/reclamation policy we  
> > implement,
> > it will simply smooth out and mitigate some of the negative effects  
> > of an
> > abrupt transition to IPv6.  To put it another way, it makes it  
> > possible to
> > extend the dual-stack phase of the v4-v6 transition so that we aren't
> > forcing some organizations to turn off v4 before everyone else has  
> > turned
> > on v6.
> >
> You do realize that's a pipe dream, right?  There simply isn't enough 
> IPv4 and time to make that realistic, and, the patterns of human
> behavior  to date suggest that  a time extension will be used primarily
> to procrastinate  v6 deployment rather than achieve it. 
> 
> Owen

Not doing some amount of reclamation, will leave us open to a different 
pattern of human behavior.  In this case if we leave sizable chunks of 
address space obviously unused, no matter how trivial in the over all 
scheme of things.  It will be an existence proof that we really don't know 
what we are talking about, or that we have an "IPv6 agenda".

I'm not sure what for the reclamation should take but it does need to 
happen, at least all the trivially easy stuff.

=======================================================
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 sleibrand at internap.com  Tue Oct 21 17:25:24 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 21 Oct 2008 14:25:24 -0700
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com> <48FE2935.9010109@internap.com>
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
Message-ID: <48FE48C4.4070407@internap.com>

Owen DeLong wrote:
> 
> On Oct 21, 2008, at 12:10 PM, Scott Leibrand wrote:
> 
>> My own opinion is that whatever transfer/reclamation policy we implement,
>> it will simply smooth out and mitigate some of the negative effects of an
>> abrupt transition to IPv6.  To put it another way, it makes it 
>> possible to
>> extend the dual-stack phase of the v4-v6 transition so that we aren't
>> forcing some organizations to turn off v4 before everyone else has turned
>> on v6.
>>
> You do realize that's a pipe dream, right?  There simply isn't enough IPv4
> and time to make that realistic, and, the patterns of human behavior to 
> date
> suggest that  a time extension will be used primarily to procrastinate v6
> deployment rather than achieve it.

I have a lot of respect for the motivating power of economic incentives.

-Scott


From rlc at usfamily.net  Tue Oct 21 17:32:09 2008
From: rlc at usfamily.net (Ron Cleven)
Date: Tue, 21 Oct 2008 16:32:09 -0500 (CDT)
Subject: [arin-ppml] "Millions of Internet Addresses
	Are	LyingIdle"	(slashdot)
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08D33EAD@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC08D33EAD@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <48FE4A57.8090104@usfamily.net>

michael.dillon at bt.com wrote:
>>Until and unless someone can describe, in simple layman's 
>>terms, a rational transition plan to IPv6, I don't see it happening.
> 
> 
> The laymen have already transitioned to IPv6.
> 

Very cute.

> 
>>1) What are the largest barriers that will prevent widescale 
>>adoption of
>>IPv6 in the next 12 months or whatever timeframe
> 
> 
> ISPs.
> 

Also very cute, but, of course, you know it is a hopelessly incomplete 
answer to the question.


> 
>>2) How can the transition be simplified?
> 
> 
> It can't. Changing a big network that carries millions of dollars
> worth of traffic every day is never simple.
> 

Ok, I'll accept that answer for now.  My gut tells me, however, that 
simply not enough thought has gone into it.

> 
>>3) Most importantly, how can the transition be incentified?
> 
> 
> By pushing requests up the supply chain which is one thing that
> governments are trying to do by mandating that publicly funded 
> agencies begin migrating to IPv6.
> 

Ok, after we get all those publicly-funded agencies to IPv6, then all we 
have to worry about is all the rest of the Internet.


> 
>>There are a lot of smart people on this list, but you need to 
>>step back from your techno-jargon and put your collective 
>>brains to use to deal with practical issues.
> 
> 
> Why? 

Why should we bother to deal with practical issues?  I guess it is 
outside the scope of ARIN to be practical?  Sigh.  Come to think of it, 
that would explain the idiotic economies-of-scale ARIN established for 
IPv4 allocations.


It might be good for society if lots of ISPs go bankrupt
> because they hit a brick wall and are unable to grow their
> networks two to three years from now, just as the economic
> recovery picks up steam. We don't need everybody to do the
> right thing. In fact, if only a dozen national/regional ISPs
> do the right thing, it will probably be good enough because
> they will snap up the assets of their competition in three 
> years and roll out more of their successful IPv6 deployment.
> 

I totally agree.  I am completely against small businesses and the 
innovation they bring to the market-place.

> 
>>over it.  This should be a technical battle, not a legal one.
> 
> 
> Wrong story. This is ARIN, not a place for technical battles,
> but a place for cost-recovery, stewardship, and prudent 
> policies.
> 

I'm making notes so I don't make that mistake again.  This is ARIN, so 
we should never talk about anything practical or technical.  Wait, is it 
possible to be prudent without being practical?


> 
>>Anyway, once the renewal costs were equalized, then ARIN, et 
>>al, should ratchet up those annual renewal costs until IPv4 
>>address space usage reaches steady-state.  This would not 
>>solve the transition issues, but it would provide the 
>>economic incentive for all you really smart people to figure it out.
> 
> 
> I fear that such action would simply create huge economic incentives
> for someone to privatize ARIN in such a way that they make a huge
> personal fortune from the piles of cash which you want to send in.
> 
> This is getting more like a Slashdot thread every second...
> 


Wow, it appears I really hit a nerve.  Mandate that the money be sent to 
charity or use it to build 200-foot dikes around New Orleans.  Or use it 
to buy back the legacy space.  Obviously nobody on this list cares about 
establishing simple market-based incentives to get IPv6 moving.




From tedm at ipinc.net  Tue Oct 21 17:36:02 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Oct 2008 14:36:02 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are
	LyingIdle"(slashdot)
In-Reply-To: <443de7ad0810211231r2f71b792r710d55bf4ef98687@mail.gmail.com>
Message-ID: <68AAEA13F2AC42CCA6EE2C0FE6BAE202@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann
> Sent: Tuesday, October 21, 2008 12:32 PM
> To: Michael Sinatra
> Cc: ppml at arin.net; Bill Darte
> Subject: Re: [arin-ppml] "Millions of Internet Addresses Are 
> LyingIdle"(slashdot)
> 
> 
> On Tue, Oct 21, 2008 at 12:43 PM, Michael Sinatra 
> <michael at rancid.berkeley.edu> wrote:
> > You mentioned that big blocks of idle address space should be 
> > reclaimed, but what is it that you are asking ARIN to do 
> specifically?  
> > Is this a policy issue or should staff be directed to do 
> something?  
> > Should they scan address ranges and try to find large unused blocks 
> > and contact the WHOIS POC for the block?
> 
> My $.02 is that this process could start by verifying the 
> POCs in WHOIS. 

Yes, I agree.

> Then ARIN staff can focus initially on 
> "orphaned" IP space (blocks with no verifiable POC). I am 
> not suggesting that all IP space with out a valid POC is 
> necessarily or inherently abandoned but I do think that it is 
> an area that may well prove to have much low hanging fruit in 
> regards to reclamation.
> 
> We may need a specific policy to address under what 
> conditions an address block can be considered abandoned or 
> otherwise "reclaimable." We may also want or need a policy 
> (such as my proposed "Annual WHOIS POC Validation") 

YOUR proposed whois POC validation?

Don't you mean MY proposed "whois POC e-mail cleanup" that you didn't
even bother participating in and just ripped off the idea from?

Next time I'll just wait until the day before the
last day of submittal then turn the proposal in.

Ted

PS  Just kidding.  Mostly.




From tedm at ipinc.net  Tue Oct 21 17:39:46 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Oct 2008 14:39:46 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
In-Reply-To: <20B8811F-FC4A-4310-A829-3AD763B0792C@svcolo.com>
Message-ID: <805280BF3B8E4DDC9D2B923B55CACF46@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jo Rhett
> Sent: Tuesday, October 21, 2008 1:31 PM
> To: Paul Vixie
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] "Millions of Internet Addresses Are 
> Lying Idle"(slashdot)
> 
> 
> On Oct 21, 2008, at 12:42 PM, Paul Vixie wrote:
> > let me be clear that even if the above-quoted text from me was the
> > arin
> > board's view (of which it probably does not but in any case 
> i would  
> > not
> > be the spokesman), then the idleness of which you speak 
> would still be
> > due to the staff's and board's responsibility to act on approved  
> > policy
> > rather than on our own views.
> 
> Honestly, read the RSA.   It very clearly says that if the 
> POC data is  
> not kept up to date, it's a violation of contract.  Asking ARIN to  
> validate POC data for RSA contractees is like reminding the 
> teacher to  
> show up in class.  It is function 1 of their job.  Why aren't they  
> doing it?
> 

They ARE doing it.  Anyone who has allocated space gets a bill every
year.  If their contact info becomes invalid, the bill then gets returned
by USPS and after 6 months or whatever, the account goes to collections
and the allocated IP addressing becomes forfeit.

Ted



From sleibrand at internap.com  Tue Oct 21 17:42:32 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Tue, 21 Oct 2008 14:42:32 -0700
Subject: [arin-ppml] Whois cleanup proposals
In-Reply-To: <68AAEA13F2AC42CCA6EE2C0FE6BAE202@tedsdesk>
References: <68AAEA13F2AC42CCA6EE2C0FE6BAE202@tedsdesk>
Message-ID: <48FE4CC8.6060609@internap.com>

FWIW, the ARIN AC voted on Friday to work with all of the authors of the 
whois cleanup proposals to combine them in to a single proposal.  My sense 
  was that we felt that there was consensus in favor of the goals of 
2008-7: Whois Integrity Policy Proposal, but not for the means outlined, 
so we felt that those goals would be better accomplished by incorporating 
the various good ideas you guys proposed.

-Scott (speaking for myself)

Ted Mittelstaedt wrote:
>> We may need a specific policy to address under what 
>> conditions an address block can be considered abandoned or 
>> otherwise "reclaimable." We may also want or need a policy 
>> (such as my proposed "Annual WHOIS POC Validation") 
> 
> YOUR proposed whois POC validation?
> 
> Don't you mean MY proposed "whois POC e-mail cleanup" that you didn't
> even bother participating in and just ripped off the idea from?
> 
> Next time I'll just wait until the day before the
> last day of submittal then turn the proposal in.
> 
> Ted
> 
> PS  Just kidding.  Mostly.



From schnizlein at isoc.org  Tue Oct 21 17:35:55 2008
From: schnizlein at isoc.org (John Schnizlein)
Date: Tue, 21 Oct 2008 17:35:55 -0400
Subject: [arin-ppml] "Millions of Internet Addresses
	Are	LyingIdle"	(slashdot)
In-Reply-To: <48FE4A57.8090104@usfamily.net>
References: <C0F2465B4F386241A58321C884AC7ECC08D33EAD@E03MVZ2-UKDY.domain1.systemhost.net>
	<48FE4A57.8090104@usfamily.net>
Message-ID: <56709B29-A00B-48E3-AD41-D420D6811C4D@isoc.org>

Sarcasm (I hope) alert:

On 2008Oct21, at 5:32 PM, Ron Cleven wrote:

> Obviously nobody on this list cares about establishing
> simple market-based incentives to get IPv6 moving.



From tedm at ipinc.net  Tue Oct 21 17:53:06 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Oct 2008 14:53:06 -0700
Subject: [arin-ppml] "Millions of Internet
	AddressesAre	LyingIdle"	(slashdot)
In-Reply-To: <48FE4A57.8090104@usfamily.net>
Message-ID: <A4EBED2A48A240A7AE585C7BDBABE057@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ron Cleven
> Sent: Tuesday, October 21, 2008 2:32 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] "Millions of Internet AddressesAre 
> LyingIdle" (slashdot)
> 
> 
> michael.dillon at bt.com wrote:
> >>Until and unless someone can describe, in simple layman's
> >>terms, a rational transition plan to IPv6, I don't see it happening.
> > 
> > 
> > The laymen have already transitioned to IPv6.
> > 
> 
> Very cute.
> 

I have a smartphone, a Motorola Q running Windows Mobile 5 on it
on the Sprint network.  When I ran the Microsoft networking tools on
the phone it clearly showed that Sprint has assigned IPv6 numbers to
it's cellular data network.  When I surf the web on my phone I am
going through a IPv6->IPv4 gateway.  Ironically, if I go to
http://www.ipv6porn.co.nz/ I DO NOT see the free porn on the phone,
indicating that Sprint's IPv6->IPv4 gateways are NOT connected to
the IPv6 Internet.  What morons!

A great many laymen have cell phones nowadays.

> 
> 
> > 
> >>2) How can the transition be simplified?
> > 
> > 
> > It can't. Changing a big network that carries millions of dollars 
> > worth of traffic every day is never simple.
> > 
> 
> Ok, I'll accept that answer for now.  My gut tells me, however, that 
> simply not enough thought has gone into it.
> 

How do you eat an elephant?  A bit at a time.

> 
> It might be good for society if lots of ISPs go bankrupt
> > because they hit a brick wall and are unable to grow their networks 
> > two to three years from now, just as the economic recovery picks up 
> > steam. We don't need everybody to do the right thing. In 
> fact, if only 
> > a dozen national/regional ISPs do the right thing, it will 
> probably be 
> > good enough because they will snap up the assets of their 
> competition 
> > in three years and roll out more of their successful IPv6 
> deployment.
> > 
> 
> I totally agree.  I am completely against small businesses and the 
> innovation they bring to the market-place.
> 

Don't be foolish.  The smaller ISPs have it a lot easier to migrate
to IPv6.

> Obviously nobody on this list 
> cares about 
> establishing simple market-based incentives to get IPv6 moving.
>

We already have them.  It's called "use IPv6 post-runout or you will
go out of business"  Seems pretty much of an incentive to me.

Ted



From michael.dillon at bt.com  Tue Oct 21 17:58:53 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 21 Oct 2008 22:58:53 +0100
Subject: [arin-ppml] "Millions of Internet
	AddressesAre	LyingIdle"	(slashdot)
In-Reply-To: <48FE4A57.8090104@usfamily.net>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08D33EEF@E03MVZ2-UKDY.domain1.systemhost.net>

> It might be good for society if lots of ISPs go bankrupt
> > because they hit a brick wall and are unable to grow their
> > networks two to three years from now, just as the economic
> > recovery picks up steam. We don't need everybody to do the
> > right thing. In fact, if only a dozen national/regional ISPs
> > do the right thing, it will probably be good enough because
> > they will snap up the assets of their competition in three 
> > years and roll out more of their successful IPv6 deployment.
> > 
> 
> I totally agree.  I am completely against small businesses and the 
> innovation they bring to the market-place.

I never said anything about small businesses. If you would do
a bit of research you would learn that small businesses are
the ones that are leading the move to IPv6. Look at companies
like AAISP in the UK or XS4ALL in the Netherlands or Hurricane
Electric in the USA.

> Obviously nobody on this list 
> cares about 
> establishing simple market-based incentives to get IPv6 moving.

That is not ARIN's job.

--Michael Dillon


From tedm at ipinc.net  Tue Oct 21 18:00:33 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Oct 2008 15:00:33 -0700
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <48FE48C4.4070407@internap.com>
Message-ID: <FEB1B38301ED4EBB8CC0D8B7F80633FC@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> Sent: Tuesday, October 21, 2008 2:25 PM
> To: Owen DeLong
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] What will be the end result of IPv4 
> exhaustion?
> 
> 
> Owen DeLong wrote:
> > 
> > On Oct 21, 2008, at 12:10 PM, Scott Leibrand wrote:
> > 
> >> My own opinion is that whatever transfer/reclamation policy we 
> >> implement, it will simply smooth out and mitigate some of the 
> >> negative effects of an abrupt transition to IPv6.  To put 
> it another 
> >> way, it makes it possible to extend the dual-stack phase 
> of the v4-v6 
> >> transition so that we aren't forcing some organizations to 
> turn off 
> >> v4 before everyone else has turned on v6.
> >>
> > You do realize that's a pipe dream, right?  There simply 
> isn't enough 
> > IPv4 and time to make that realistic, and, the patterns of human 
> > behavior to date suggest that  a time extension will be 
> used primarily 
> > to procrastinate v6 deployment rather than achieve it.
> 
> I have a lot of respect for the motivating power of economic 
> incentives.
> 

Then let's place a progressive fee system into place for ARIN
allocations.

1 year before the last IPv4 is assigned a 10% surcharge to the
fee for IPv4 is applied.

9 months before the last IPv4 is assigned a 50% surcharge to the
fee for IPv4 is applied.

6 months before the last IPv4 is assigned a 100% surcharge to the
fee for IPv4 is applied.

3 months before the last IPv4 is assigned a 1000% surcharge to the
fee for IPv4 is applied.

1 month before the last IPv4 is assigned a $500,000USD surcharge to the
fee for any IPv4 is applied.

1 week before the last IPv4 is assigned a $1 million dollar surcharge
to the fee for IPv4 is applied.

The very last block of IPv4 assigned will be priced at $1 billion
dollars.  This is to ensure that only an organization that really, really
needs it will apply for it, and that they aren't just applying for it
for pure bragging rights.

How would that incentive work?  Seems to me that using that schedule we
could extend IPv4 runout indefinitely!!!!


Ted



From michael.dillon at bt.com  Tue Oct 21 18:01:19 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 21 Oct 2008 23:01:19 +0100
Subject: [arin-ppml] "Millions of
	InternetAddressesAre	LyingIdle"	(slashdot)
In-Reply-To: <A4EBED2A48A240A7AE585C7BDBABE057@tedsdesk>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08D33EF1@E03MVZ2-UKDY.domain1.systemhost.net>

> A great many laymen have cell phones nowadays.

Or Windows Vista, or Mac OS/X.

--Michael Dillon


From tvest at pch.net  Tue Oct 21 18:11:43 2008
From: tvest at pch.net (Tom Vest)
Date: Tue, 21 Oct 2008 18:11:43 -0400
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <48FE48C4.4070407@internap.com>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com> <48FE2935.9010109@internap.com>
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
	<48FE48C4.4070407@internap.com>
Message-ID: <3940716F-16A5-422C-8E96-F2D0A91C37DF@pch.net>


On Oct 21, 2008, at 5:25 PM, Scott Leibrand wrote:

> Owen DeLong wrote:
>>
>> On Oct 21, 2008, at 12:10 PM, Scott Leibrand wrote:
>>
>>> My own opinion is that whatever transfer/reclamation policy we  
>>> implement,
>>> it will simply smooth out and mitigate some of the negative  
>>> effects of an
>>> abrupt transition to IPv6.  To put it another way, it makes it
>>> possible to
>>> extend the dual-stack phase of the v4-v6 transition so that we  
>>> aren't
>>> forcing some organizations to turn off v4 before everyone else has  
>>> turned
>>> on v6.
>>>
>> You do realize that's a pipe dream, right?  There simply isn't  
>> enough IPv4
>> and time to make that realistic, and, the patterns of human  
>> behavior to
>> date
>> suggest that  a time extension will be used primarily to  
>> procrastinate v6
>> deployment rather than achieve it.
>
> I have a lot of respect for the motivating power of economic  
> incentives.

I wish we had a bit more respect for the inspirational power of short- 
term economic incentives to trump long-term interests, and to reveal  
paths around weak (non) regulations, sometimes with very surprising  
results.

TV 


From tvest at pch.net  Tue Oct 21 18:23:16 2008
From: tvest at pch.net (Tom Vest)
Date: Tue, 21 Oct 2008 18:23:16 -0400
Subject: [arin-ppml] Tax incentive for renumbering-related labor costs?
In-Reply-To: <3940716F-16A5-422C-8E96-F2D0A91C37DF@pch.net>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com> <48FE2935.9010109@internap.com>
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
	<48FE48C4.4070407@internap.com>
	<3940716F-16A5-422C-8E96-F2D0A91C37DF@pch.net>
Message-ID: <0E5BDE44-FBE9-4D02-AC6A-B01103A19A8D@pch.net>

Anyone care to suggest plausible "ballpark" renumbering-related labor  
costs for one IPv4 /24?
I vaguely recall hearing about a couple of private studies estimating  
such costs...

Anyone think that this kind of tax incentive would be sufficient to  
motivate returns to ARIN?

What (if any) legal changes would be required to permit U.S.-based  
IPv4 holders to claim U.S. tax benefits like this for address space  
returned to ARIN?

Obviously lots of variables, esp. if other jurisdictions/RIRs are  
considered, but is this worth investigating?

TV


From tedm at ipinc.net  Tue Oct 21 18:23:46 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Oct 2008 15:23:46 -0700
Subject: [arin-ppml] Some observations on the differences in the
	varioustransfer policy proposals
In-Reply-To: <D9E4B3A6-C76B-436A-BCF3-4BA285762AF3@apnic.net>
Message-ID: <B5E0C4804D4D4D94BF4AF38544E54904@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Geoff Huston
> Sent: Monday, October 20, 2008 12:08 PM
> To: Scott Leibrand
> Cc: APNIC Policy SIG List; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Some observations on the differences 
> in the varioustransfer policy proposals
> 
> 
> 
> On 21/10/2008, at 4:29 AM, Scott Leibrand wrote:
> 
> > I understand your position there, but you haven't answered my
> > question: who/what do you think is in a better position than the  
> > RIRs to do so?
> 
> 
> I think you are saying "I want you to show me your concept of The  
> Complete Solution."
> 
> I am saying "In my view the registry function in and of itself is  
> incapable of carrying the load of The Complete Solution, 
> whatever that  
> may be - if you overload the registry with contrived constraints on  
> how one can make changes in the registry you simply motivate the  
> creation of alternate registries, and then rather than having a  
> valuable and useful registry for the IPv4 Internet you have, well,  
> fatal confusion. There are many good and compelling reasons to get  
> over this IPv4 exhaustion thing and deploy IPv6, but I'm personally  
> not keen on an approach that includes destruction of the 
> integrity of  
> the entire address registry structure as a major milestone."
> 

I have trimmed APNIC Policy SIG List from this response as it 
appears to me that this is an egregious example of crossposting,

Geoff, your making a generalized statement with the phrase:

"..if you overload the registry with contrived constraints..."

So basically, the things that
YOU like and NOT overloading, they are normal registry functions.
The things that the OTHER GUY likes that YOU do NOT like, those
are covered with the loaded term "overloading"

Is that right?

As of now, no one has created any of these so-called
"alternate registries" so to put it bluntly your argument
is nothing more than speculation.

> 
> At which point I've already gone past acceptable levels of 
> brevity in  
> mail, and way past my personal quota of posts -  my sincere 
> apologies  
> for this.
>

In other words, gee, now people are nailing me to the wall for
specifics and I better find some way to claim that I don't
have to answer them, is that it?

If you don't want to defend your earlier statements then go run
off.  Otherwise, a list of SPECIFIC things that you think that
a registry SHOULD be engaged in and a list of SPECIFC things
that you think a registry SHOULD NOT be engaged, followed by some
logical reasons why, seems to me to be certainly in order.

Ted



From sethm at rollernet.us  Tue Oct 21 18:28:01 2008
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 21 Oct 2008 15:28:01 -0700
Subject: [arin-ppml] "Millions of Internet	AddressesAre	LyingIdle"
 (slashdot)
In-Reply-To: <A4EBED2A48A240A7AE585C7BDBABE057@tedsdesk>
References: <A4EBED2A48A240A7AE585C7BDBABE057@tedsdesk>
Message-ID: <48FE5771.9020202@rollernet.us>

Ted Mittelstaedt wrote:
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ron Cleven
>> Sent: Tuesday, October 21, 2008 2:32 PM
>> To: ppml at arin.net
>> Subject: Re: [arin-ppml] "Millions of Internet AddressesAre 
>> LyingIdle" (slashdot)
>>
>>
>> michael.dillon at bt.com wrote:
>>>> Until and unless someone can describe, in simple layman's
>>>> terms, a rational transition plan to IPv6, I don't see it happening.
>>>
>>> The laymen have already transitioned to IPv6.
>>>
>> Very cute.
>>
> 
> I have a smartphone, a Motorola Q running Windows Mobile 5 on it
> on the Sprint network.  When I ran the Microsoft networking tools on
> the phone it clearly showed that Sprint has assigned IPv6 numbers to
> it's cellular data network.  When I surf the web on my phone I am
> going through a IPv6->IPv4 gateway.  Ironically, if I go to
> http://www.ipv6porn.co.nz/ I DO NOT see the free porn on the phone,
> indicating that Sprint's IPv6->IPv4 gateways are NOT connected to
> the IPv6 Internet.  What morons!
> 

For what it's worth, I just tried some IPv6 sites on my Sprint 700wx and
it did access them using their IPv6 addresses.

~Seth


From ocl at gih.com  Tue Oct 21 18:18:10 2008
From: ocl at gih.com (Olivier MJ Crepin-Leblond)
Date: Wed, 22 Oct 2008 00:18:10 +0200
Subject: [arin-ppml] Suggestion: charging for IPv4 space
Message-ID: <010b01c933ca$e7860460$8a01a8c0@gih.co.uk>

All:

Although I am not representing any registry and although this is my first
post here, I have been reading debates on this mailing list for a little
while and I can clearly see that the issue of IPv4 to IPv6 transition
strikes quite a few chords, so I think that this is the right forum to post
into. I am consulting each RIR discussion list separately, so sorry for
the cross-posting, but I feel it is important to take this issue up separately
in each region of the world.

Through discussions I've had with dozens of people (some of whom may
be reading this message), I have noticed the following:

- currently, neither IPv4 nor IPv6 address delegation are directly linked to
any kind of significant recurent *annual* fee;
- some ISPs are considering introducing IPv6 connectivity to customers
*for a premium* rather than IPv4 (yes, sadly, it's true);
- we've had 10+ years of slogan "we are running out of IPv4 addresses" and
this has not "hit the spot" to get a transitional process going;
- sadly, there is a lack of IPv6 "killer ap" to promote the use of IPv6 over IPv4;
- availability of several IPv6 "islands" exist on the Internet, with very poor
"trans-island" connectivity (although I am told that this is s-l-o-w-l-y improving -
and that's good news);
- a lot of stigmas are associated with IPv6 (our customers do not request it;
there is no demand; etc.)

Clearly, we could all go on talking for another 10 years about IPv6. But
we don't have 10 years.
So what's the hurdle?

Let's be fair, folks, it all boils down to a question of *money*.

v4 to v6 transition is seen as an expensive exercise. Darn, with hardware, software
& training, transition is expensive! Had it been cheap, we wouldn't be in the
*utter mess* that we are in today because it would have been a natural thing
to do.

So we are going to run out of "greenfield IPv4" addresses by, say, 25 Dec 2010.
Or earlier. Or later. Whatever. What we know is that we'll run out. <Boom>.

IPv4 addresses will become a limited commodity. Speculators are going to
step in, and they are likely to do it at a shockingly fast speed.
(eg. Cantel & Siegel's Green Card Lottery announced mass spamming;
the sex.com case announced the worth of domain names).

My suggestion (and others here, namely Ted and Ron have already touched 
on the idea) is therefore to engage a study of the following "positive 
discrimination" proposal:

1. Introducing a *recurrent annual* cost-element to IPv4 addresses,
the reason behind it being: making v6 cheaper to run than v4. This could be a
small cost to start with, increasing significantly but steadily along a scale for 
the next few years.
This should act more as a *deterrent* for the use of IPv4 in the future than as
a "tax" to be paid now. Heck, it might even start cleaning up IPv4 space and
giving us more time to transit to v6 through the release of more IPv4 space!
Those effects are hard to predict.

2. Building a v4 to v6 neutral & non-for-profit transition fund from the 
IPv4 revenue.
This fund could finance/subsidise the following:
a. the initial bridging of the IPv6 islands until those would be able to fly
commercially
b. IPv6 tech training
c. any other project that would trigger/help v4 to v6 transition

If we do not make IPv6 more interesting financially, we risk failure to transit
smoothly.
This will cause a *much greater problem* than Domain speculation since
IP addressing constitutes the very fabric of the Internet:

1. Panic in operators who might then try and grab as much v4 space as
possible, thus compounding the problem;
2. Panic transition from v4 to v6 which will completely forego the transition
testing period which Peter Kirstein (UCL London) has mentioned many
times, thus introducing instability in the Internet;
3. A lack of fully qualified technicians & engineers to run IPv6 networks;
4. A "free" market for IPv4 addresses where prices quickly spiral out
of control.

I am trying to look for a solution which will ease the shock by instead
smoothly raising prices. A totally unregulated increase is to be feared.
The rate of increase might have a greater impact than the price itself - see
oil prices if you're not convinced: we can "survive" with oil at $140 a barrel,
but we are hurt by the price going quickly from $70 a barrel to $140.
It messes the world's economy up because it changes the balance at once
in all of our business models.

I don't believe in self-regulation by the market - it opens itself to serious
abuse, in the same way Wall Street bankers abused the system and look
where this led us?

IPv4 is a *serious* show-stopper wrt the Internet's future development.
The Internet we are seeing today is still primarily accessed by computers 
but tomorrow, and tomorrow isn't far away, we're going to see increased 
use by mobile devices. There are also now several commercial products 
out there to access your home PC remotely. Next on the tab is the concept 
of having a home multimedia server that can be accessed remotely. And 
then we fall into consumer electronics - new TVs are now all digital-enabled 
& the rest of the "home entertainment" system is quickly becoming all digital. 
The "young generations" do not know CDs - their music travels on digital 
music players & laptops. And then comes the "Network of things" where 
sensors will talk to each other. This is just about to hit us, and our dinosaur 
IPv4 will be as suited to this as the steam engine is to the modern hydrid car. 
IPv6 will enable us to have cheap devices all connected to the Internet.

With instability creeping in the system, we risk several high profile
technical failures with repercussions not dissimilar to the current
failures in the banking sector. Do we really want this?

I shall be going to the ICANN Cairo conference and would be happy to 
discuss these matters in person. Come on, let's do something about this 
impending doom. I've lived the DOTCOM boom years and met with 
teenagers who told me they were going to conquer the world - *and they did*. 
IPv6 has the ability to infuse a breath of life in Internetting & the Internet 
Economy worldwide - on every continent. Seize the day. Don't wait until
someone tells you that you've failed.

Sorry for the length of the message & thanks for reading,

Olivier

-- 
Olivier MJ Crepin-Leblond, Ph.D.
E-mail:<ocl at gih.com> | http://www.gih.com/ocl.html



From tedm at ipinc.net  Tue Oct 21 18:33:31 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Oct 2008 15:33:31 -0700
Subject: [arin-ppml] Tax incentive for renumbering-related labor costs?
In-Reply-To: <0E5BDE44-FBE9-4D02-AC6A-B01103A19A8D@pch.net>
Message-ID: <FEF93CC303A04C49A054F157F2C50686@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Tom Vest
> Sent: Tuesday, October 21, 2008 3:23 PM
> To: ARIN PPML
> Subject: [arin-ppml] Tax incentive for renumbering-related 
> labor costs?
> 
> 
> Anyone care to suggest plausible "ballpark" 
> renumbering-related labor  
> costs for one IPv4 /24?
> I vaguely recall hearing about a couple of private studies 
> estimating  
> such costs...
> 

What is this /24 used on?

If it's used on a colocated virtual webserver that has 5,000
domain names it is serving websites for, the cost could be quite high.

Otherwise, assuming every number on the subnet is in use, if it
is like most of them, you could start the renumber Friday evening and
have it completed by Monday morning, assuming you worked steadily
at it for 4-5 hours Friday, and 10-12 hours Saturday.

> Anyone think that this kind of tax incentive would be sufficient to  
> motivate returns to ARIN?
> 

tax incentives never motivated anyone to do anything.  tax incentives
are convenient political potatos that the politicians like to use
to prove that they are actually doing something about a problem when
in reality they are doing absolutely nothing.

> What (if any) legal changes would be required to permit U.S.-based  
> IPv4 holders to claim U.S. tax benefits like this for address space  
> returned to ARIN?
> 

None whatsoever.  It takes labor to do these, you pay your employees
more labor for the extra time, you get to take it off your gross, thus
dropping your taxable net.  You also help stimulate the economy
by putting more money in your employees pockets, instead of giving it
to the investors who are just going to use it to speculate in home
mortgages that they are going to later short sell anyway.

Ted



From bmanning at vacation.karoshi.com  Tue Oct 21 18:53:38 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 21 Oct 2008 22:53:38 +0000
Subject: [arin-ppml] ["Lying Idle"]
In-Reply-To: <B17175B1-7411-4B63-85A8-E8BF8335845D@svcolo.com>
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>
	<87466.1224546974@nsa.vix.com>
	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com>
	<B17175B1-7411-4B63-85A8-E8BF8335845D@svcolo.com>
Message-ID: <20081021225338.GA16319@vacation.karoshi.com.>

On Tue, Oct 21, 2008 at 12:25:30PM -0700, Jo Rhett wrote:
> On Oct 21, 2008, at 11:54 AM, Paul Vixie wrote:
> > to expect that one full time person working less than one year would  
> > be able
> > to counter and/or reset that expectation seems incredibly unrealistic.
> 
> 
> As demonstrated by the absolute zero effort put into this by ARIN to  
> date.  Somewhere between (a) oh god, let's not offend the legacy  
> holders and (b) we can't win against the legacy holders - ARIN sits  
> idle.  What is amusing is that not only is not all idle space in the  
> hands of legacy holders (most of what I personally know about was  
> assigned under the RSA) but not all legacy holders are even aware of  
> the transfer proposals.

	this is patently false Jo. ARIN has put forth effort and
	continues to do so.  As Leslie mentioned last week, all
	the /8 holders have had outreach - and there are some
	14,000+ outstanding cases pending.  If Legacy Holders
	don't know, they should soon.

--bill


From bmanning at vacation.karoshi.com  Tue Oct 21 18:58:02 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Tue, 21 Oct 2008 22:58:02 +0000
Subject: [arin-ppml] "Millions of Internet Addresses
	AreLying	Idle"(slashdot)
In-Reply-To: <g38wshspye.fsf@nsa.vix.com>
References: <194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
	<C0F2465B4F386241A58321C884AC7ECC08CC1F11@E03MVZ2-UKDY.domain1.systemhost.net>
	<g38wshspye.fsf@nsa.vix.com>
Message-ID: <20081021225802.GB16319@vacation.karoshi.com.>

On Tue, Oct 21, 2008 at 07:33:45PM +0000, Paul Vixie wrote:
> 
> can you explain why someone would stop using IPv4 if it still reached the
> entire set of endpoints they wanted to exchange traffic with?  or failing
> that can you explain why someone would switch to IPv6-only if it would
> limit the set of endpoints they could exchange traffic with?

	thats a dirt simple question Paul.  Reduced complexity in the
	end system.  Check w/ anyone who has run large scale dual-stack
	infrastructure (like ESnet, DREN, SPAWAR, etc) and the one thing
	they pine for is less crap on the endsystem.  Running a single
	protocol stack is much simpler to install, troubleshoot, debug
	and audit.

> but noone i know expects that there will ever be a time when one set of
> users is releasing IPv4 because they're happy with IPv6-only and IPv4-NAT,
> while another set of users still needs to grow their IPv4.  unless it's
> you, that is.  i'd like to hear more about this world view.

	well... let me introduce myself.

> -- 
> Paul Vixie

--bill


From cgrundemann at gmail.com  Tue Oct 21 19:05:07 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 21 Oct 2008 17:05:07 -0600
Subject: [arin-ppml] Whois cleanup proposals
In-Reply-To: <48FE4CC8.6060609@internap.com>
References: <68AAEA13F2AC42CCA6EE2C0FE6BAE202@tedsdesk>
	<48FE4CC8.6060609@internap.com>
Message-ID: <443de7ad0810211605u4e773811m1418e2271a123332@mail.gmail.com>

On Tue, Oct 21, 2008 at 3:36 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:

>> My $.02 is that this process could start by verifying the
>> POCs in WHOIS.
>
> Yes, I agree.
>
>> Then ARIN staff can focus initially on
>> "orphaned" IP space (blocks with no verifiable POC). I am
>> not suggesting that all IP space with out a valid POC is
>> necessarily or inherently abandoned but I do think that it is
>> an area that may well prove to have much low hanging fruit in
>> regards to reclamation.
>>
>> We may need a specific policy to address under what
>> conditions an address block can be considered abandoned or
>> otherwise "reclaimable." We may also want or need a policy
>> (such as my proposed "Annual WHOIS POC Validation")
>
> YOUR proposed whois POC validation?
>
> Don't you mean MY proposed "whois POC e-mail cleanup" that you didn't
> even bother participating in and just ripped off the idea from?

WOW.  I guess I mean the proposal based on the one that you ripped off
from Heather Schiller (before I had the chance too ;)).

> Next time I'll just wait until the day before the
> last day of submittal then turn the proposal in.

Not if you want consensus,  which I was trying to help _the idea_ reach.

> Ted
>
> PS  Just kidding.  Mostly.
>
>

Hoping it's all in fun,
~Chris


From tedm at ipinc.net  Tue Oct 21 19:06:02 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Oct 2008 16:06:02 -0700
Subject: [arin-ppml] Suggestion: charging for IPv4 space
In-Reply-To: <010b01c933ca$e7860460$8a01a8c0@gih.co.uk>
Message-ID: <12E2E00F6C2E40738EFA2CD08601DC61@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Olivier MJ 
> Crepin-Leblond
> Sent: Tuesday, October 21, 2008 3:18 PM
> To: ppml at arin.net
> Subject: [arin-ppml] Suggestion: charging for IPv4 space
> 
> 
> All:
> 
> Although I am not representing any registry and although this 
> is my first post here, I have been reading debates on this 
> mailing list for a little while and I can clearly see that 
> the issue of IPv4 to IPv6 transition strikes quite a few 
> chords, so I think that this is the right forum to post into. 
> I am consulting each RIR discussion list separately, so sorry 
> for the cross-posting, but I feel it is important to take 
> this issue up separately in each region of the world.
> 
> Through discussions I've had with dozens of people (some of 
> whom may be reading this message), I have noticed the following:
> 
> - currently, neither IPv4 nor IPv6 address delegation are 
> directly linked to any kind of significant recurent *annual* fee;
> - some ISPs are considering introducing IPv6 connectivity to 
> customers *for a premium* rather than IPv4 (yes, sadly, it's true);
> - we've had 10+ years of slogan "we are running out of IPv4 
> addresses" and this has not "hit the spot" to get a 
> transitional process going;
> - sadly, there is a lack of IPv6 "killer ap" to promote the 
> use of IPv6 over IPv4;
> - availability of several IPv6 "islands" exist on the 
> Internet, with very poor "trans-island" connectivity 
> (although I am told that this is s-l-o-w-l-y improving - and 
> that's good news);
> - a lot of stigmas are associated with IPv6 (our customers do 
> not request it; there is no demand; etc.)
> 
> Clearly, we could all go on talking for another 10 years 
> about IPv6. But we don't have 10 years. So what's the hurdle?
> 
> Let's be fair, folks, it all boils down to a question of *money*.
> 
> v4 to v6 transition is seen as an expensive exercise. Darn, 
> with hardware, software & training, transition is expensive! 
> Had it been cheap, we wouldn't be in the *utter mess* that we 
> are in today because it would have been a natural thing to do.
> 

It is cheaper to go pee out the window into the flowerbed
instead of using the flush toilet down the hall, that doesen't
mean we go do it.  Well, most of us don't.

There's a lot of other cheap things we don't do just because they
are cheap.  Even some we don't that we should do.

Cost is not the main reason we haven't switched.  Seriously!

> So we are going to run out of "greenfield IPv4" addresses by, 
> say, 25 Dec 2010. Or earlier. Or later. Whatever. What we 
> know is that we'll run out. <Boom>.
> 
> IPv4 addresses will become a limited commodity. Speculators 
> are going to step in, and they are likely to do it at a 
> shockingly fast speed. (eg. Cantel & Siegel's Green Card 
> Lottery announced mass spamming; the sex.com case announced 
> the worth of domain names).
> 
> My suggestion (and others here, namely Ted and Ron have 
> already touched 
> on the idea) is therefore to engage a study of the following 
> "positive 
> discrimination" proposal:
> 
> 1. Introducing a *recurrent annual* cost-element to IPv4 
> addresses, the reason behind it being: making v6 cheaper to 
> run than v4. This could be a small cost to start with, 
> increasing significantly but steadily along a scale for 
> the next few years.

We already have that:

http://www.arin.net/billing/fee_schedule.html#both

"...Organizations holding direct allocations of both IPv4 and IPv6 address
space from ARIN under a single Org ID only pay the larger of the two
annual subscription renewal fees..."

NAT also creates a HUGE incentive for orgs to renumber what
IPv4 they can into private IP space.

For myself I do not understand why all of these academic
users keep throwing up examples of student dormotories
that chew up vast blocks of IPv4.  Why does ANY student that
is getting Internet connectivity for free from the college
expect to get a public IPv4 number?

> This should act more as a *deterrent* for the use of IPv4 in 
> the future than as a "tax" to be paid now. Heck, it might 
> even start cleaning up IPv4 space and giving us more time to 
> transit to v6 through the release of more IPv4 space! Those 
> effects are hard to predict.
> 
> 2. Building a v4 to v6 neutral & non-for-profit transition 
> fund from the 
> IPv4 revenue.
> This fund could finance/subsidise the following:
> a. the initial bridging of the IPv6 islands until those would 
> be able to fly commercially b. IPv6 tech training c. any 
> other project that would trigger/help v4 to v6 transition
> 

b. and c. we already do.  Or rather, ARIN already does.  They
don't separately break out an allocation from their fees for
this but it is effectively what is going on.

a. is a whole different story.  My employer is ALREADY paying
my upstreams for bandwidth, and they should be using some of
that money to roll out IPv6.  If I am unsatisfied with their
performance in rolling out IPv6 then I'll have my employer stop
paying them and go pay someone else.  If enough other people
thought this way then there wouldn't be an IPv6 problem.

> If we do not make IPv6 more interesting financially, we risk 
> failure to transit smoothly. This will cause a *much greater 
> problem* than Domain speculation since IP addressing 
> constitutes the very fabric of the Internet:
> 
> 1. Panic in operators who might then try and grab as much v4 
> space as possible, thus compounding the problem; 2. Panic 
> transition from v4 to v6 which will completely forego the 
> transition testing period which Peter Kirstein (UCL London) 
> has mentioned many times, thus introducing instability in the 
> Internet; 3. A lack of fully qualified technicians & 
> engineers to run IPv6 networks; 4. A "free" market for IPv4 
> addresses where prices quickly spiral out of control.
> 
> I am trying to look for a solution which will ease the shock 
> by instead smoothly raising prices.

Repeat the following mantra:

If I am unsatisfied with their
performance in rolling out IPv6 then I'll have my employer stop
paying them and go pay someone else.

If I am unsatisfied with their
performance in rolling out IPv6 then I'll have my employer stop
paying them and go pay someone else.

If I am unsatisfied with their
performance in rolling out IPv6 then I'll have my employer stop
paying them and go pay someone else.

If I am unsatisfied with their
performance in rolling out IPv6 then I'll have my employer stop
paying them and go pay someone else.

EDUCATION and EMPOWERMENT is the only answer.

We need to identify the people in the orgs that are the decision
makers, educate them on the upcoming IPv4 runout, and they
need to complain to who they are paying for connectivity to 
get to work on IPv6.

> A totally unregulated 
> increase is to be feared. The rate of increase might have a 
> greater impact than the price itself - see oil prices if 
> you're not convinced: we can "survive" with oil at $140 a 
> barrel, but we are hurt by the price going quickly from $70 a 
> barrel to $140. It messes the world's economy up because it 
> changes the balance at once in all of our business models.
> 
> I don't believe in self-regulation by the market - it opens 
> itself to serious abuse, in the same way Wall Street bankers 
> abused the system and look where this led us?
> 
> IPv4 is a *serious* show-stopper wrt the Internet's future 
> development. The Internet we are seeing today is still 
> primarily accessed by computers 
> but tomorrow, and tomorrow isn't far away, we're going to see 
> increased 
> use by mobile devices. There are also now several commercial products 
> out there to access your home PC remotely. Next on the tab is 
> the concept 
> of having a home multimedia server that can be accessed remotely. And 
> then we fall into consumer electronics - new TVs are now all 
> digital-enabled 
> & the rest of the "home entertainment" system is quickly 
> becoming all digital. 
> The "young generations" do not know CDs - their music travels 
> on digital 
> music players & laptops. And then comes the "Network of things" where 
> sensors will talk to each other. This is just about to hit 
> us, and our dinosaur 
> IPv4 will be as suited to this as the steam engine is to the 
> modern hydrid car. 
> IPv6 will enable us to have cheap devices all connected to 
> the Internet.
> 
> With instability creeping in the system, we risk several high 
> profile technical failures with repercussions not dissimilar 
> to the current failures in the banking sector. Do we really want this?
> 
> I shall be going to the ICANN Cairo conference and would be happy to 
> discuss these matters in person. Come on, let's do something 
> about this 
> impending doom. I've lived the DOTCOM boom years and met with 
> teenagers who told me they were going to conquer the world - 
> *and they did*. 
> IPv6 has the ability to infuse a breath of life in 
> Internetting & the Internet 
> Economy worldwide - on every continent. Seize the day. Don't 
> wait until someone tells you that you've failed.
> 
> Sorry for the length of the message & thanks for reading,
> 

I think your being very colorful with the metaphors.  I also think
you would be excellent at identifying the people in the orgs that
are the decision makers, educating them on the upcoming IPv4 runout,
and telling them to complain to who they are paying for connectivity to 
get to work on IPv6.

This is your mission Oliver, should you decide to accept it! ;-)

Ted
 



From tedm at ipinc.net  Tue Oct 21 19:21:45 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Oct 2008 16:21:45 -0700
Subject: [arin-ppml] Whois cleanup proposals
In-Reply-To: <443de7ad0810211605u4e773811m1418e2271a123332@mail.gmail.com>
Message-ID: <46DC2D2EC3284F66B78E1EA7E09F8BC1@tedsdesk>



> -----Original Message-----
> From: Chris Grundemann [mailto:cgrundemann at gmail.com] 
> Sent: Tuesday, October 21, 2008 4:05 PM
> To: Scott Leibrand
> Cc: Ted Mittelstaedt; ppml at arin.net
> Subject: Re: Whois cleanup proposals
> 
> 
> On Tue, Oct 21, 2008 at 3:36 PM, Ted Mittelstaedt 
> <tedm at ipinc.net> wrote:
> 
> >> My $.02 is that this process could start by verifying the POCs in 
> >> WHOIS.
> >
> > Yes, I agree.
> >
> >> Then ARIN staff can focus initially on
> >> "orphaned" IP space (blocks with no verifiable POC). I am not 
> >> suggesting that all IP space with out a valid POC is 
> necessarily or 
> >> inherently abandoned but I do think that it is an area 
> that may well 
> >> prove to have much low hanging fruit in regards to reclamation.
> >>
> >> We may need a specific policy to address under what conditions an 
> >> address block can be considered abandoned or otherwise 
> "reclaimable." 
> >> We may also want or need a policy (such as my proposed 
> "Annual WHOIS 
> >> POC Validation")
> >
> > YOUR proposed whois POC validation?
> >
> > Don't you mean MY proposed "whois POC e-mail cleanup" that 
> you didn't 
> > even bother participating in and just ripped off the idea from?
> 
> WOW.  I guess I mean the proposal based on the one that you 
> ripped off from Heather Schiller (before I had the chance too ;)).
> 

Damn now you made me snort pop out my nose...

Actually I think Heather wanted to take a very large axe or mallet
to the userbase.  What she proposed was far in excess of what
either of us wrote out.  I also noted that she did very little in
revisions to incorporate anyone's suggestions.

> 
> Hoping it's all in fun,

It's all in fun until the results of the AC review and ARIN staff
review on both proposals.  Then we will know if either of the
proposals will be workable or not.  Remember it's ARIN staff that
would be doing the work, I would think that their opinion on
whether the proposals are doable or not would carry great weight.

And, these are just the beginnings of the small rocks that 
herald the avalanche  Just look at all the debate on the list
over the "Millions of Internet addresses are lying idle"
post and all THAT was, is some bozo with Perl loaded on a Windows
system who figured out how to write a loop and put the ping
command in it!

Wait and see what happens when one of these proposals is implemented
and a year from now ARIN reports that 50% of the Legacy IPv4 POCs
are not responding to their query!!!

Ted



From owen at delong.com  Tue Oct 21 19:33:01 2008
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Oct 2008 16:33:01 -0700
Subject: [arin-ppml] Tax incentive for renumbering-related labor costs?
In-Reply-To: <0E5BDE44-FBE9-4D02-AC6A-B01103A19A8D@pch.net>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com> <48FE2935.9010109@internap.com>
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
	<48FE48C4.4070407@internap.com>
	<3940716F-16A5-422C-8E96-F2D0A91C37DF@pch.net>
	<0E5BDE44-FBE9-4D02-AC6A-B01103A19A8D@pch.net>
Message-ID: <B9D4E51C-9406-4B07-BE2A-68EC93B1EAD1@delong.com>

The problem with such an estimate is that it assumes renumbering
effort is proportional to network size.

A /24 that is, for example, not referenced in external configuration
data (not containing nameservers, not in ACLs, not being used to
terminate VPNs) is much easier to remember than even a /28
that contains a bunch of VPN terminators that have lots of tunnels
configured to third parties.

Owen

On Oct 21, 2008, at 3:23 PM, Tom Vest wrote:

> Anyone care to suggest plausible "ballpark" renumbering-related labor
> costs for one IPv4 /24?
> I vaguely recall hearing about a couple of private studies estimating
> such costs...
>
> Anyone think that this kind of tax incentive would be sufficient to
> motivate returns to ARIN?
>
> What (if any) legal changes would be required to permit U.S.-based
> IPv4 holders to claim U.S. tax benefits like this for address space
> returned to ARIN?
>
> Obviously lots of variables, esp. if other jurisdictions/RIRs are
> considered, but is this worth investigating?
>
> TV
> _______________________________________________
> 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 tedm at ipinc.net  Tue Oct 21 19:40:49 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 21 Oct 2008 16:40:49 -0700
Subject: [arin-ppml] "Millions of Internet	AddressesAre	LyingIdle"
	(slashdot)
In-Reply-To: <48FE5771.9020202@rollernet.us>
Message-ID: <F81B535D34D240398FDD6F3066701CD0@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Seth Mattinen
> Sent: Tuesday, October 21, 2008 3:28 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] "Millions of Internet AddressesAre 
> LyingIdle" (slashdot)
> 
> 
> Ted Mittelstaedt wrote:
> > 
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net
> >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ron Cleven
> >> Sent: Tuesday, October 21, 2008 2:32 PM
> >> To: ppml at arin.net
> >> Subject: Re: [arin-ppml] "Millions of Internet AddressesAre 
> >> LyingIdle" (slashdot)
> >>
> >>
> >> michael.dillon at bt.com wrote:
> >>>> Until and unless someone can describe, in simple 
> layman's terms, a 
> >>>> rational transition plan to IPv6, I don't see it happening.
> >>>
> >>> The laymen have already transitioned to IPv6.
> >>>
> >> Very cute.
> >>
> > 
> > I have a smartphone, a Motorola Q running Windows Mobile 5 on it on 
> > the Sprint network.  When I ran the Microsoft networking 
> tools on the 
> > phone it clearly showed that Sprint has assigned IPv6 
> numbers to it's 
> > cellular data network.  When I surf the web on my phone I am going 
> > through a IPv6->IPv4 gateway.  Ironically, if I go to 
> > http://www.ipv6porn.co.nz/ I DO NOT see the free porn on the phone, 
> > indicating that Sprint's IPv6->IPv4 gateways are NOT 
> connected to the 
> > IPv6 Internet.  What morons!
> > 
> 
> For what it's worth, I just tried some IPv6 sites on my 
> Sprint 700wx and it did access them using their IPv6 addresses.
> 

I can hit sprintv6.net with my phone and it says I AM IPv6
enabled.  I guess Sprint doesen't have good IPv6 connectivity to
the other IPv6 networks out there.

Ted



From tvest at pch.net  Tue Oct 21 19:43:52 2008
From: tvest at pch.net (Tom Vest)
Date: Tue, 21 Oct 2008 19:43:52 -0400
Subject: [arin-ppml] Tax incentive for renumbering-related labor costs?
In-Reply-To: <B9D4E51C-9406-4B07-BE2A-68EC93B1EAD1@delong.com>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com> <48FE2935.9010109@internap.com>
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
	<48FE48C4.4070407@internap.com>
	<3940716F-16A5-422C-8E96-F2D0A91C37DF@pch.net>
	<0E5BDE44-FBE9-4D02-AC6A-B01103A19A8D@pch.net>
	<B9D4E51C-9406-4B07-BE2A-68EC93B1EAD1@delong.com>
Message-ID: <F63582FE-CDB8-47F4-94B0-6E42E9510F2B@pch.net>


On Oct 21, 2008, at 7:33 PM, Owen DeLong wrote:

> The problem with such an estimate is that it assumes renumbering
> effort is proportional to network size.

The problem with not fielding such an estimate is that no sane  
politician would consider sponsoring it.
Come on folks,  I thought that my use of the terms like "plausible"  
and "ballpark" would be enough to earn me a pass on assumptions of  
ignorance about the real-world diversity of production environments...

No one wants to even venture a guess? No one else has seen a  
consultant study on renumbering costs that could be mined for a  
barebones "plausible" estimate?

TV


> A /24 that is, for example, not referenced in external configuration
> data (not containing nameservers, not in ACLs, not being used to
> terminate VPNs) is much easier to remember than even a /28
> that contains a bunch of VPN terminators that have lots of tunnels
> configured to third parties.
>
> Owen
>
> On Oct 21, 2008, at 3:23 PM, Tom Vest wrote:
>
>> Anyone care to suggest plausible "ballpark" renumbering-related labor
>> costs for one IPv4 /24?
>> I vaguely recall hearing about a couple of private studies estimating
>> such costs...
>>
>> Anyone think that this kind of tax incentive would be sufficient to
>> motivate returns to ARIN?
>>
>> What (if any) legal changes would be required to permit U.S.-based
>> IPv4 holders to claim U.S. tax benefits like this for address space
>> returned to ARIN?
>>
>> Obviously lots of variables, esp. if other jurisdictions/RIRs are
>> considered, but is this worth investigating?
>>
>> TV
>> _______________________________________________
>> 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 gih at apnic.net  Tue Oct 21 20:18:15 2008
From: gih at apnic.net (Geoff Huston)
Date: Wed, 22 Oct 2008 11:18:15 +1100
Subject: [arin-ppml] Some observations on the differences in the
	varioustransfer policy proposals
In-Reply-To: <B5E0C4804D4D4D94BF4AF38544E54904@tedsdesk>
References: <B5E0C4804D4D4D94BF4AF38544E54904@tedsdesk>
Message-ID: <369AB223-AB7D-436D-B98B-0E6BD78A1BFB@apnic.net>


On 22/10/2008, at 9:23 AM, Ted Mittelstaedt wrote:
>

>  Otherwise, a list of SPECIFIC things that you think that
> a registry SHOULD be engaged in and a list of SPECIFC things
> that you think a registry SHOULD NOT be engaged, followed by some
> logical reasons why, seems to me to be certainly in order.
>

For reasons that may also be apparent to others who have had also had  
the pleasure of reading your prolific output in recent times, I assume  
that you have not read the material at the URL I originally referred to.

Geoff
Disclaimer: still me.





From randy at psg.com  Tue Oct 21 20:21:51 2008
From: randy at psg.com (Randy Bush)
Date: Tue, 21 Oct 2008 19:21:51 -0500
Subject: [arin-ppml] What will be the end result of IPv4 exhaustion?
In-Reply-To: <3940716F-16A5-422C-8E96-F2D0A91C37DF@pch.net>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>	<36202.1224615272@nsa.vix.com>
	<48FE2935.9010109@internap.com>	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>	<48FE48C4.4070407@internap.com>
	<3940716F-16A5-422C-8E96-F2D0A91C37DF@pch.net>
Message-ID: <48FE721F.9080307@psg.com>

> I wish we had a bit more respect for the inspirational power of short- 
> term economic incentives to trump long-term interests

what more respect can we show than the utter trashing of the world's
economy?

randy


From vixie at isc.org  Tue Oct 21 20:32:47 2008
From: vixie at isc.org (Paul Vixie)
Date: Wed, 22 Oct 2008 00:32:47 +0000
Subject: [arin-ppml] "Millions of Internet Addresses AreLying
	Idle"(slashdot)
In-Reply-To: Your message of "Tue, 21 Oct 2008 22:58:02 GMT."
	<20081021225802.GB16319@vacation.karoshi.com.> 
References: <194DB6AB-644F-4095-BA9B-902512C820EC@delong.com>
	<C0F2465B4F386241A58321C884AC7ECC08CC1F11@E03MVZ2-UKDY.domain1.systemhost.net>
	<g38wshspye.fsf@nsa.vix.com>
	<20081021225802.GB16319@vacation.karoshi.com.> 
Message-ID: <80797.1224635567@nsa.vix.com>

> From: bmanning at vacation.karoshi.com
> 
> On Tue, Oct 21, 2008 at 07:33:45PM +0000, Paul Vixie wrote:
> > 
> > can you explain why someone would stop using IPv4 if it still reached
> > the entire set of endpoints they wanted to exchange traffic with?  or
> > failing that can you explain why someone would switch to IPv6-only if
> > it would limit the set of endpoints they could exchange traffic with?
> 
> 	thats a dirt simple question Paul.  Reduced complexity in the
> 	end system.  Check w/ anyone who has run large scale dual-stack
> 	infrastructure (like ESnet, DREN, SPAWAR, etc) and the one thing
> 	they pine for is less crap on the endsystem.  Running a single
> 	protocol stack is much simpler to install, troubleshoot, debug
> 	and audit.

did you miss the part where before this could happen there would be growth
of ipv6-only end nodes and thus ipv4 would be a nonuniversal protocol, NAT
or no NAT?  as before, i don't see why DREN would prefer non-RFC1918 IPv4
over RFC1918 IPv4 if neither one will have as many endpoints to talk to as
IPv6-only -- which is the point in the timeline we're discussing.


From farmer at umn.edu  Tue Oct 21 20:43:54 2008
From: farmer at umn.edu (David Farmer)
Date: Tue, 21 Oct 2008 19:43:54 -0500
Subject: [arin-ppml] Why not NAT for Dorms (Was: Suggestion: charging
	for IPv4 space)
In-Reply-To: <12E2E00F6C2E40738EFA2CD08601DC61@tedsdesk>
References: <010b01c933ca$e7860460$8a01a8c0@gih.co.uk>,
	<12E2E00F6C2E40738EFA2CD08601DC61@tedsdesk>
Message-ID: <48FE30FA.22080.55CC496@farmer.umn.edu>

On 21 Oct 2008 Ted Mittelstaedt wrote:

> For myself I do not understand why all of these academic
> users keep throwing up examples of student dormotories
> that chew up vast blocks of IPv4.  Why does ANY student that
> is getting Internet connectivity for free from the college
> expect to get a public IPv4 number?

There are so many reasons, let me educate you on just a few;

1. Technical the definition I use for NAT (Network Address Translation) is a 
one to one internal to external address translator.  If I need one external 
IPv4 addresses for each internal IPv4 address where is the win?  I have 
more complexity and cost for almost no win, maybe a 10-20% reduction in 
number of IPv4 addresses used by eliminating subnet round up.

2. I think you really meant PAT (Port Address Translation) when you said 
NAT, so I need to support at least 10,000 users (this is only the Dorms too) 
with at least 250Mb of capacity, and at least 200,000 concurrent 
connections.  So lets say a Cisco ASA 5540 for discussion, $17,000 (list), 
need 2 for redundancy, so $34,000 (list), divide by 5 year life, and add 
$4,000 a year for Smartnet (list), comes out to about $10,000 a year for a 
PAT/NAT. a /18 is with 16K addresses is only $4500 a year.  So explain to 
me how it is cheeper?  Even with a 50% discount from Cisco it is only 
breaks even, and I have included any operation expenses yet, other than 
Smartnet.
 
3. Putting all 10,000 users behind a single address or even some small 
number of addresses just concentrates the effect of DOS attacks, which 
happen every day.

4. Putting all the users behind a single address or even some small number 
of addresses means I have to track session info to keep the RIAA and 
MPAA happy, that's several servers and a bunch of disk not in the number 
above.  By using real IPs the RIAA and MPAA have to do the real work.  
And if you don't think we should have to do this at all then tell congress that 
because they are making our federal dollars contingent on it.

http://net.educause.edu/ir/library/pdf/epo0815.pdf

But that is a whole other story;

5. Competition - If students move out of the dorms to get real IPs from 
Comcast so all there games and other stuff work then we get a bad 
reputation.  Students actually take into account the wiredness of a school 
when selecting where to go now.  That's at least as good as of a reason to 
consider than if we are party school or not, dude!!

6. Why should Comcast users expect a real IP address from Comcast?  It is 
really the same questions.

I'll stop here, but I could keep going on and on...


=======================================================
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 kc at caida.org  Tue Oct 21 20:45:06 2008
From: kc at caida.org (k claffy)
Date: Tue, 21 Oct 2008 17:45:06 -0700
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <20985F2A-CEDF-4348-9A07-A1552E767554@apnic.net>
References: <48FBE342.8020403@internap.com>
	<6E694160-6B98-4880-81E2-AE2603243C18@apnic.net>
	<E129CCE0-8F71-4F2C-8EB1-6337CC67507F@apnic.net>
	<918C41F9-03AF-418E-A853-E19DCE18E023@pch.net>
	<20985F2A-CEDF-4348-9A07-A1552E767554@apnic.net>
Message-ID: <20081022004506.GA9840@rommie.caida.org>


geoff

tom is one of the few people in this community besides you who
is actually spending many hours per day thinking and writing
about this issue, so i find it a great disservice to us all,
and unbecoming someone of your stature, that you are choosing
to blow off his feedback because you 'rather not write 1,000
words', especially since your essay defending your proposal
has twice that many words, none of which addressed his concerns.
if you are worried about lowering ppml's s/n, could you respond
directly to tom's message below and link to it from your essay?

many of us are really trying to understand the issues here,
and understanding exactly which facts -- and opinions -- 
the heavy thinkers disagree on would help greatly.  

if typing is a problem (it is for me), i would be happy to
moderate a debate between you two and put the mp3 up as a
podcast.  i have great respect for you both, not only for how 
much time you have both put into thinking about this topic, 
and believe it is a bad sign for the Internet (and an even
worse sign for the RIR community) if you declare that tom's 
points aren't even worth addressing.  i suspect they are.

k




On Mon, Oct 20, 2008 at 05:35:04PM +1100, Geoff Huston wrote:
  We certainly differ in perspective, thats true.
  
  I'd rather not write a 1,000 word response - this list is already in  
  overload in terms of reading matter, so I'll limit myself to 150  
  words, and  simply state that I do not see this situation within the  
  parameters of the analogies you are drawing here.
  
  As  far as I can see when all thats left to the RIRs in IPv4 in the  
  registry function then it seems rather self-defeating to me to start  
  imposing all kinds of constraints and conditions on write access to  
  the registry. The most natural response in such situation in the face  
  of such constraints and additional overheads is for folk to head to a  
  more accommodating registry. And I don't think that is a desireable  
  outcome.
  
  But you see it differently. Fair enough
  
  rgds,
  
     Geoff
  
     Disclaimer: these are all my opinions - I'm not representing anyone  
  or anybody else.
  
  On 20/10/2008, at 5:03 PM, Tom Vest wrote:
  
  > Geoff, IMHO, you're simply off base here, both in your specific  
  > recommendations, and in your claim that there is no relevant  
  > experience base.
  >
  > I happen to believe that you've been absolutely true to your  
  > convictions since RFC 1744. And I recognize that your convictions  
  > (if RFC 1744 is any guide), or at least your concrete  
  > recommendations since then, have a solid, principled foundation in  
  > libertarian "free banking" theories (for those interested, see  
  > references below). But the fact remains, every time that such  
  > theories have been put into practice they have failed absolutely,  
  > resulting in the imposition of national partitioning of markets and  
  > regulatory structures, if not outright nationalization/operation of  
  > the affected industries. There is no reason to doubt that anything  
  > other than that will result from the course of action you're  
  > advocating, and numerous specific and likely reasons/paths that  
  > would lead precisely to that outcome.
  >
  
  [...]
  
  
  _______________________________________________
  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 braaen at zcorum.com  Tue Oct 21 20:42:10 2008
From: braaen at zcorum.com (Brian Raaen)
Date: Tue, 21 Oct 2008 20:42:10 -0400
Subject: [arin-ppml] Tax incentive for renumbering-related labor costs?
In-Reply-To: <FEF93CC303A04C49A054F157F2C50686@tedsdesk>
References: <FEF93CC303A04C49A054F157F2C50686@tedsdesk>
Message-ID: <200810212042.10511.braaen@zcorum.com>

I would have to agree with Ted that different types of uses have differing 
cost.  I recently worked on renumbering a DSL system from one backbone to 
another backbone. As far as the standard PPPoE DSL users and the Dial access 
users, we for the most part could care less.  I.E. Add the new pool to the 
redback kill the old pool, the modems reboot and get their new address. Now 
the static users are a different story.  We have gone out of the way to set 
up route-maps to let them still route out the old backbone and let them 
renumber when they are able.

So I would agree that network block size is not a good metric.  I could 
change /24 pppoe/dhcp pools till the cows came home, but 
equipment/server/static netblocks regardless of size are approached with 
tender loving care.


----------------------

Brian Raaen
Network Engineer
braaen at zcorum.com


On Tuesday 21 October 2008, Ted Mittelstaedt wrote:
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net 
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Tom Vest
> > Sent: Tuesday, October 21, 2008 3:23 PM
> > To: ARIN PPML
> > Subject: [arin-ppml] Tax incentive for renumbering-related 
> > labor costs?
> > 
> > 
> > Anyone care to suggest plausible "ballpark" 
> > renumbering-related labor  
> > costs for one IPv4 /24?
> > I vaguely recall hearing about a couple of private studies 
> > estimating  
> > such costs...
> > 
> 
> What is this /24 used on?
> 
> If it's used on a colocated virtual webserver that has 5,000
> domain names it is serving websites for, the cost could be quite high.
> 
> Otherwise, assuming every number on the subnet is in use, if it
> is like most of them, you could start the renumber Friday evening and
> have it completed by Monday morning, assuming you worked steadily
> at it for 4-5 hours Friday, and 10-12 hours Saturday.
> 
> > Anyone think that this kind of tax incentive would be sufficient to  
> > motivate returns to ARIN?
> > 
> 
> tax incentives never motivated anyone to do anything.  tax incentives
> are convenient political potatos that the politicians like to use
> to prove that they are actually doing something about a problem when
> in reality they are doing absolutely nothing.
> 
> > What (if any) legal changes would be required to permit U.S.-based  
> > IPv4 holders to claim U.S. tax benefits like this for address space  
> > returned to ARIN?
> > 
> 
> None whatsoever.  It takes labor to do these, you pay your employees
> more labor for the extra time, you get to take it off your gross, thus
> dropping your taxable net.  You also help stimulate the economy
> by putting more money in your employees pockets, instead of giving it
> to the investors who are just going to use it to speculate in home
> mortgages that they are going to later short sell anyway.
> 
> 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.
> 




From cgrundemann at gmail.com  Tue Oct 21 20:56:26 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 21 Oct 2008 18:56:26 -0600
Subject: [arin-ppml] Tax incentive for renumbering-related labor costs?
In-Reply-To: <F63582FE-CDB8-47F4-94B0-6E42E9510F2B@pch.net>
References: <36790.1224363677@nsa.vix.com>
	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com> <48FE2935.9010109@internap.com>
	<6CA64DFA-795C-411D-8C16-C2D8C2996DDD@delong.com>
	<48FE48C4.4070407@internap.com>
	<3940716F-16A5-422C-8E96-F2D0A91C37DF@pch.net>
	<0E5BDE44-FBE9-4D02-AC6A-B01103A19A8D@pch.net>
	<B9D4E51C-9406-4B07-BE2A-68EC93B1EAD1@delong.com>
	<F63582FE-CDB8-47F4-94B0-6E42E9510F2B@pch.net>
Message-ID: <443de7ad0810211756j2d2a6ac8nafb9ad937645225c@mail.gmail.com>

Speaking as someone who managed a small ISP network (around 2000
customers) through several re-numberings of various scale, I will take
a shot.

For a single /24 (very rough estimates)
1) Design time; deciding what and how to do it.  ~5hrs (@ $75 - $100hr)
2) Configuration time; adding secondary IPs, redundant routes, etc to
prepare for the migration, adding NAT, port forwarding,  etc, and then
removing the old configs after the migration.  Assuming that the whole
/24 is broken all the way to /30s, ~10hrs (@ $75 - $100hr)
3) Notification and cooperation; working with customers (internal or
external) to set expectations and work through issues that arise.
Again assuming 64 distinct connections, ~10hrs (@ $50 - $75hr)
4) Opportunity cost (maybe I am using the wrong term); for an ISP,
there will likely be at least one customer lost, not sure how/if this
would translate to a campus setting.

$1125 - $1500 in Engineering cost
$500 - $750 in Customer Service cost
$1000 in Opportunity cost (mostly making this number up)

= $2625 - $3250

So call it $3k per /24.  Does this sound reasonable at all?

~Chris


On Tue, Oct 21, 2008 at 5:43 PM, Tom Vest <tvest at pch.net> wrote:
>
> On Oct 21, 2008, at 7:33 PM, Owen DeLong wrote:
>
>> The problem with such an estimate is that it assumes renumbering
>> effort is proportional to network size.
>
> The problem with not fielding such an estimate is that no sane
> politician would consider sponsoring it.
> Come on folks,  I thought that my use of the terms like "plausible"
> and "ballpark" would be enough to earn me a pass on assumptions of
> ignorance about the real-world diversity of production environments...
>
> No one wants to even venture a guess? No one else has seen a
> consultant study on renumbering costs that could be mined for a
> barebones "plausible" estimate?
>
> TV
>
>
>> A /24 that is, for example, not referenced in external configuration
>> data (not containing nameservers, not in ACLs, not being used to
>> terminate VPNs) is much easier to remember than even a /28
>> that contains a bunch of VPN terminators that have lots of tunnels
>> configured to third parties.
>>
>> Owen
>>
>> On Oct 21, 2008, at 3:23 PM, Tom Vest wrote:
>>
>>> Anyone care to suggest plausible "ballpark" renumbering-related labor
>>> costs for one IPv4 /24?
>>> I vaguely recall hearing about a couple of private studies estimating
>>> such costs...
>>>
>>> Anyone think that this kind of tax incentive would be sufficient to
>>> motivate returns to ARIN?
>>>
>>> What (if any) legal changes would be required to permit U.S.-based
>>> IPv4 holders to claim U.S. tax benefits like this for address space
>>> returned to ARIN?
>>>
>>> Obviously lots of variables, esp. if other jurisdictions/RIRs are
>>> considered, but is this worth investigating?
>>>
>>> TV
>>> _______________________________________________
>>> 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.chrisgrundemann.com
www.linkedin.com/in/cgrundemann


From michael at rancid.berkeley.edu  Tue Oct 21 20:58:30 2008
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Tue, 21 Oct 2008 17:58:30 -0700
Subject: [arin-ppml] Why not NAT for Dorms (Was: Suggestion: charging
 for IPv4 space)
In-Reply-To: <48FE30FA.22080.55CC496@farmer.umn.edu>
References: <010b01c933ca$e7860460$8a01a8c0@gih.co.uk>,
	<12E2E00F6C2E40738EFA2CD08601DC61@tedsdesk>
	<48FE30FA.22080.55CC496@farmer.umn.edu>
Message-ID: <48FE7AB6.2070404@rancid.berkeley.edu>

On 10/21/08 17:43, David Farmer wrote:
> On 21 Oct 2008 Ted Mittelstaedt wrote:
> 
>> For myself I do not understand why all of these academic
>> users keep throwing up examples of student dormotories
>> that chew up vast blocks of IPv4.  Why does ANY student that
>> is getting Internet connectivity for free from the college
>> expect to get a public IPv4 number?

Because it's not free.  They pay for connectivity like everyone else and 
we are their ISP.  Which leads to Dave's point:

> 5. Competition - If students move out of the dorms to get real IPs from 
> Comcast so all there games and other stuff work then we get a bad 
> reputation.  Students actually take into account the wiredness of a school 
> when selecting where to go now.  That's at least as good as of a reason to 
> consider than if we are party school or not, dude!!
> 
> 6. Why should Comcast users expect a real IP address from Comcast?  It is 
> really the same questions.
> 
> I'll stop here, but I could keep going on and on...

Ultimately, I expect to have our wireless nets and possibly eventually 
the residence halls using NAT for v4 while giving them globally-routable 
v6 addresses.  The other option is to give them v6 only and use whatever 
flavor of NAT-PT we ultimately accept as a community.  But that's a ways 
off...

But I still think NAT sucks.  And it sucks just as much in the residence 
halls as it does anywhere else.  (I guess that could be Dave's #7.)

michael


From dwcarder at wisc.edu  Tue Oct 21 22:48:25 2008
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Tue, 21 Oct 2008 21:48:25 -0500
Subject: [arin-ppml] "Millions of Internet Addresses Are	LyingIdle"
 (slashdot)
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08D33EAD@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC08D33EAD@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <F8E67DDB-E749-4ED6-AA59-6FA3D9031E19@wisc.edu>


On Oct 21, 2008, at 2:58 PM, Ron Cleven wrote:
>> 2) How can the transition be simplified?
>

Translation.  We must enable IPv6-only nodes to be able
to reach IPv4-only nodes one way or another.

We've been down the protocol translation path before, and I'm
happy to report I don't know of any GatorBox's still running
on our network.

>> 3 Most importantly, how can the transition be incentified?

On Oct 21, 2008, at 3:34 PM, michael.dillon at bt.com wrote:
> By pushing requests up the supply chain which is one thing that
> governments are trying to do by mandating that publicly funded
> agencies begin migrating to IPv6.

I agree with this approach.  One of the components of the
IPv6 negative feedback loop is the lack of v6-ready products.
Governments are a big enough purchasing entity to spark
vendor movement in this direction.

Dale


From farmer at umn.edu  Wed Oct 22 01:04:12 2008
From: farmer at umn.edu (David Farmer)
Date: Wed, 22 Oct 2008 00:04:12 -0500
Subject: [arin-ppml] Why not NAT for Dorms
In-Reply-To: <48FE7AB6.2070404@rancid.berkeley.edu>
References: <010b01c933ca$e7860460$8a01a8c0@gih.co.uk>,
	<48FE30FA.22080.55CC496@farmer.umn.edu>,
	<48FE7AB6.2070404@rancid.berkeley.edu>
Message-ID: <48FE6DFC.11623.C6F7AB@farmer.umn.edu>

On 21 Oct 2008 Michael Sinatra wrote:

> On 10/21/08 17:43, David Farmer wrote:
> > On 21 Oct 2008 Ted Mittelstaedt wrote:
> > 
> >> For myself I do not understand why all of these academic
> >> users keep throwing up examples of student dormotories
> >> that chew up vast blocks of IPv4.  Why does ANY student that
> >> is getting Internet connectivity for free from the college
> >> expect to get a public IPv4 number?
> 
> Because it's not free.  They pay for connectivity like everyone else and 
> we are their ISP.  Which leads to Dave's point:

I completely forgot about that issue, any parent who has paid to send a 
student to one of our institutions knows that almost nothing we provide is 
FREE!  Just like the Comcast Triple Play we provide a bundle of services 
with one low bill. :)

I will also point out that one of the highest correlations to Internet use is a 
college education.  While those students probably are not your direct 
customer now, in a few years we will be done with them and then they will 
likely be one of your customers.

http://www.pewinternet.org/trends/User_Demo_4.26.06.htm



=======================================================
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  Wed Oct 22 01:19:07 2008
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Wed, 22 Oct 2008 01:19:07 -0400
Subject: [arin-ppml] Why not NAT for Dorms
In-Reply-To: <48FE6DFC.11623.C6F7AB@farmer.umn.edu>
References: <010b01c933ca$e7860460$8a01a8c0@gih.co.uk>,
	<48FE30FA.22080.55CC496@farmer.umn.edu>,
	<48FE7AB6.2070404@rancid.berkeley.edu>
	<48FE6DFC.11623.C6F7AB@farmer.umn.edu>
Message-ID: <997BC128AE961E4A8B880CD7442D9480079B50EF@NJCHLEXCMB01.cable.comcast.com>

David,

Thank you for a good laugh. I liked the Comcast analogy. And since I am
still paying for my student loans, I would agree with you that I paid
for my Internet connectivity while I was at school. 

Dan Alexander
Comcast Cable
ARIN AC


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of David Farmer
Sent: Wednesday, October 22, 2008 1:04 AM
To: Ted Mittelstaedt; ppml at arin.net
Subject: Re: [arin-ppml] Why not NAT for Dorms

On 21 Oct 2008 Michael Sinatra wrote:

> On 10/21/08 17:43, David Farmer wrote:
> > On 21 Oct 2008 Ted Mittelstaedt wrote:
> > 
> >> For myself I do not understand why all of these academic users keep

> >> throwing up examples of student dormotories that chew up vast 
> >> blocks of IPv4.  Why does ANY student that is getting Internet 
> >> connectivity for free from the college expect to get a public IPv4 
> >> number?
> 
> Because it's not free.  They pay for connectivity like everyone else 
> and we are their ISP.  Which leads to Dave's point:

I completely forgot about that issue, any parent who has paid to send a
student to one of our institutions knows that almost nothing we provide
is FREE!  Just like the Comcast Triple Play we provide a bundle of
services with one low bill. :)

I will also point out that one of the highest correlations to Internet
use is a college education.  While those students probably are not your
direct customer now, in a few years we will be done with them and then
they will likely be one of your customers.

http://www.pewinternet.org/trends/User_Demo_4.26.06.htm



=======================================================
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.


From jrhett at svcolo.com  Wed Oct 22 01:57:01 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 22:57:01 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
In-Reply-To: <805280BF3B8E4DDC9D2B923B55CACF46@tedsdesk>
References: <805280BF3B8E4DDC9D2B923B55CACF46@tedsdesk>
Message-ID: <FB2C3912-A97B-4877-8D47-AD9E0521E78B@svcolo.com>

On Oct 21, 2008, at 2:39 PM, Ted Mittelstaedt wrote:
> They ARE doing it.  Anyone who has allocated space gets a bill every
> year.  If their contact info becomes invalid, the bill then gets  
> returned
> by USPS and after 6 months or whatever, the account goes to  
> collections
> and the allocated IP addressing becomes forfeit.


That is the billing contact, entirely separate from the POC data.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Wed Oct 22 02:03:56 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 23:03:56 -0700
Subject: [arin-ppml] ["Lying Idle"]
In-Reply-To: <20081021225338.GA16319@vacation.karoshi.com.>
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>
	<87466.1224546974@nsa.vix.com>
	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com>
	<B17175B1-7411-4B63-85A8-E8BF8335845D@svcolo.com>
	<20081021225338.GA16319@vacation.karoshi.com.>
Message-ID: <9BD7A07D-EC05-4C9D-8325-CB9DA144A9D4@svcolo.com>

On Oct 21, 2008, at 3:53 PM, bmanning at vacation.karoshi.com wrote:
> 	this is patently false Jo. ARIN has put forth effort and
> 	continues to do so.  As Leslie mentioned last week, all
> 	the /8 holders have had outreach - and there are some
> 	14,000+ outstanding cases pending.  If Legacy Holders
> 	don't know, they should soon.


Patently false how?  From my own experience, that we discussed during  
lunch last week:  I had 3 legacy blocks which I was the primary  
contact for.  I had misunderstood the RSA contract to mean that these  
blocks were covered under the RSA I signed for new blocks assigned.   
This situation persisted for 13 years (admittedly 2 of which predate  
ARIN) without me ever *EVER* receiving a single e-mail from ARIN  
saying "This block is not covered by an RSA.  Would you please fill  
this out and return it?" or any variant thereof.

And to be clear, these became covered by an RSA within X* hours of me  
being aware of the situation, and that only happened within the last  
calendar year.  10 years after ARIN became the steward for the  
blocks.  And I became aware because of the need to transfer resources  
to a new org id, not because ARIN contacted me about it.

* where X = the amount of time it took me to find all the previous  
organizations (or the CEOs for defunct ones) involved and get signed  
and notarized affidavits from them, something like 3.5 days.

So back to what I said before: what outreach effort?  What POC  
validation?  I've never seen this, and I've been in a position which  
*should* have seen *BOTH*.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Wed Oct 22 01:54:59 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 21 Oct 2008 22:54:59 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
In-Reply-To: <48FDF6C2.1688.4795C28@farmer.umn.edu>
References: <36790.1224363677@nsa.vix.com>, <48FD1C10.2070600@sprunk.org>,
	<904868EF-A438-4915-A36F-ED8C0DC1371C@svcolo.com>
	<48FDF6C2.1688.4795C28@farmer.umn.edu>
Message-ID: <3B19133D-9189-4D0C-918B-5A8FA594EE60@svcolo.com>

On Oct 21, 2008, at 1:35 PM, David Farmer wrote:
> At the very least all the low hanging fruit needs to be reclaimed  
> (and all the
> dried up prunes and raisins need to be swept up off the floor too,  
> to extend
> the metaphor.)    An important balance needs to be struck here, enough
> effort to show good faith in reclaiming the obvious stuff, without  
> making futile
> heroic efforts that in the end will only divert us from the  
> transition to IPV6.

Yes, exactly.  Thanks for saying this so very well.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From mysidia at gmail.com  Wed Oct 22 03:18:35 2008
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 22 Oct 2008 02:18:35 -0500
Subject: [arin-ppml] Why not NAT for Dorms (Was: Suggestion: charging
 for IPv4 space)
In-Reply-To: <48FE30FA.22080.55CC496@farmer.umn.edu>
References: <010b01c933ca$e7860460$8a01a8c0@gih.co.uk>,
	<12E2E00F6C2E40738EFA2CD08601DC61@tedsdesk>
	<48FE30FA.22080.55CC496@farmer.umn.edu>
Message-ID: <48FED3CB.809@gmail.com>

David Farmer wrote:

(1)  Technical definition you are going by is not what is now commonly 
meant. The term "PAT" is a word
used by one equipment vendor for their name of a feature,  and there are 
several other names like "NAPT"
people tried to use.    None of them caught on, and it's still most 
commonly called "NAT".

"NAT"  is  referenced  in the context of shared ips; it is implicit 
that  "masquerading/hiding NAT"  is the type of NAT meant.
Many addresses are translated to one address.
> 6. Why should Comcast users expect a real IP address from Comcast?  It is 
> really the same questions.
>   
They have no expectation of it,  except when Comcast  tells them they 
get a real IP address.
ISP's have delivered service in various ways over the years.    Most do 
use a unique ip for each user connection.

The IP is often not "unique"  to a user in that   the ISP may change it 
from time to time, or have
the user connecting with a new ip tomorrow.




On the other hand: I don't see any reason college dorms should force all 
users to share one IP.


Keep in mind:  a unique ip address is critical  when abusive activity 
such as spam is occuring.
If the IP is  dynamically  assigned or "shared";   it   may not be 
clear  what host is responsible for
the abuse.

Since the IP is shared --  the ISP  (college)  would have to catch them 
in the act, or have traffic
logs available.

In either case, it is likely to take much longer before the 'bad'  hosts 
can be identified.


They are being better citizens by  _not_    having multiple  PCs  share 
one IP in such an environment
prone to being used for abuse.


Computers in college dorms are owned by the students, and not managed by 
professionals.
Students may have a lapse in judgement.   It is _VERY_  likely there 
will be many cases where
incidents of abuse occurs,  and  a unique IP address is useful for 
properly finding the source.

Private IPs  (with one shared external)  are inappropriate for a network 
like this, unless it is
very tightly policed.

Abusive hosts are far less likely to exist on networks where hosts are 
managed  and properly policed.
Universities  can't monitor  or have nearly that level of control of 
what software is on students'  computers.


And  draconian firewalling  of outbound traffic is   right-out,    as it 
inevitably eventually interferes
with the entire purpose of having such networks...

--
-J


From rlc at usfamily.net  Wed Oct 22 04:04:42 2008
From: rlc at usfamily.net (Ron Cleven)
Date: Wed, 22 Oct 2008 03:04:42 -0500 (CDT)
Subject: [arin-ppml] "Millions of
	Internet	AddressesAre	LyingIdle"	(slashdot)
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08D33EEF@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC08D33EEF@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <48FEDE99.4070607@usfamily.net>

michael.dillon at bt.com wrote:
>>It might be good for society if lots of ISPs go bankrupt
>>
>>>because they hit a brick wall and are unable to grow their
>>>networks two to three years from now, just as the economic
>>>recovery picks up steam. We don't need everybody to do the
>>>right thing. In fact, if only a dozen national/regional ISPs
>>>do the right thing, it will probably be good enough because
>>>they will snap up the assets of their competition in three 
>>>years and roll out more of their successful IPv6 deployment.
>>>
>>
>>I totally agree.  I am completely against small businesses and the 
>>innovation they bring to the market-place.
> 
> 
> I never said anything about small businesses. If you would do
> a bit of research you would learn that small businesses are
> the ones that are leading the move to IPv6. Look at companies
> like AAISP in the UK or XS4ALL in the Netherlands or Hurricane
> Electric in the USA.
> 

My mistake.  I took your comment to mean you thought the world would be 
a better place if only a dozen national/regional ISP's existed after the 
dust settled.


> 
>>Obviously nobody on this list 
>>cares about 
>>establishing simple market-based incentives to get IPv6 moving.
> 
> 
> That is not ARIN's job.


This must be ARINv4 list.  Is there an ARINv6 list?  How did all that 
IPv6 crap get on the ARIN.NET web site?  I forgot about your previous 
point that ARIN does not worry about any solutions being practical. 
Hence, I compounded my error, as obviously using simple market-based 
incentives to get IPv6 moving falls dangerously into the realm of the 
practical.  Don't worry, I promise I will never make any more 
suggestions that violate that tenet.  Heaven help us if someone (as 
another example of such stupidity) actually suggested that ARIN would 
phase out IPv4 allocations to organizations who do not, in parallel, 
support IPv6.


From michael.dillon at bt.com  Wed Oct 22 04:45:48 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 22 Oct 2008 09:45:48 +0100
Subject: [arin-ppml] "Millions of Internet Addresses Are	LyingIdle"
	(slashdot)
In-Reply-To: <F8E67DDB-E749-4ED6-AA59-6FA3D9031E19@wisc.edu>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08D34196@E03MVZ2-UKDY.domain1.systemhost.net>

> I agree with this approach.  One of the components of the
> IPv6 negative feedback loop is the lack of v6-ready products.
> Governments are a big enough purchasing entity to spark 
> vendor movement in this direction.

It's not enough to rely on governments. We know that in two
to three years there will not be enough IPv4 addresses to
fuel network growth. We know that IPv6 is a viable alternative
if enough people deploy it. We know that one barrier to 
deployment is incomplete hardware support. Therefore, we
should go to vendors today and tell them that we want this
support in two to three years. Before we spend any more money
with a vendor buying today's product, we should ask the vendor
to explain, in detail, their roadmap for getting to full IPv6
support.

Find the people in your organization who deal with various vendors,
and ask them if they know the vendor's roadmap to IPv6. Explain
the IPv4 exhaustion scenario to them and the need to be prepared
for IPv6.

Also, consider alternate products. Maybe you should go to a new
firewall vendor if your current vendor isn't interested in IPv6.
That too, is a way of sparking vendor action.

--Michael Dillon


From rlc at usfamily.net  Wed Oct 22 04:47:57 2008
From: rlc at usfamily.net (Ron Cleven)
Date: Wed, 22 Oct 2008 03:47:57 -0500 (CDT)
Subject: [arin-ppml] "Millions of Internet
	AddressesAre	LyingIdle"	(slashdot)
In-Reply-To: <A4EBED2A48A240A7AE585C7BDBABE057@tedsdesk>
References: <A4EBED2A48A240A7AE585C7BDBABE057@tedsdesk>
Message-ID: <48FEE8BD.4090407@usfamily.net>

>>>>Until and unless someone can describe, in simple layman's
>>>>terms, a rational transition plan to IPv6, I don't see it happening.
>>>
>>>
>>>The laymen have already transitioned to IPv6.
>>>
>>
>>Very cute.
>>
> 
> 
> I have a smartphone, a Motorola Q running Windows Mobile 5 on it
> on the Sprint network.  When I ran the Microsoft networking tools on
> the phone it clearly showed that Sprint has assigned IPv6 numbers to
> it's cellular data network.  When I surf the web on my phone I am
> going through a IPv6->IPv4 gateway.  Ironically, if I go to
> http://www.ipv6porn.co.nz/ I DO NOT see the free porn on the phone,
> indicating that Sprint's IPv6->IPv4 gateways are NOT connected to
> the IPv6 Internet.  What morons!
> 
> A great many laymen have cell phones nowadays.
> 
> 

The cell data networks have little to do with my original question.  I 
don't know how we got here.  I was kind of focusing on the millions of 
web servers and millions of mail servers and millions of routers that 
are currently running IPv4 (many, or even most, of which will never run 
IPv6).  And, yes, I understand that gateways and translations allow them 
to continue to run.  But I do see all sorts of practical problems that 
will arise as ISP's transition their customers to IPv6 without the 
luxury of mapping IPv6 to IPv4 on a one-to-one basis, while, at the same 
time, those millions and millions of servers continue to run IPv4 (yes, 
they will).  Responding to subpoenas and tracking abuse will be a 
nightmare.  But, maybe that has all been solved, and I am worried for 
naught.


> 
> 
>>It might be good for society if lots of ISPs go bankrupt
>>
>>>because they hit a brick wall and are unable to grow their networks 
>>>two to three years from now, just as the economic recovery picks up 
>>>steam. We don't need everybody to do the right thing. In 
>>
>>fact, if only 
>>
>>>a dozen national/regional ISPs do the right thing, it will 
>>
>>probably be 
>>
>>>good enough because they will snap up the assets of their 
>>
>>competition 
>>
>>>in three years and roll out more of their successful IPv6 
>>
>>deployment.
>>
>>I totally agree.  I am completely against small businesses and the 
>>innovation they bring to the market-place.
>>
> 
> 
> Don't be foolish.  The smaller ISPs have it a lot easier to migrate
> to IPv6.
> 

As I noted in a separate post, my "take" on his comments were that he 
was espousing the virtues of having only a "dozen national/regional 
ISP's" remaining.  That didn't exactly sound pro-small-business to me. 
But, I accept his subsequent clarification.


> 
>>Obviously nobody on this list 
>>cares about 
>>establishing simple market-based incentives to get IPv6 moving.
>>
> 
> 
> We already have them.  It's called "use IPv6 post-runout or you will
> go out of business"  Seems pretty much of an incentive to me.

Man, I am so relieved.  I have been reading thousands of posts that led 
me to believe that this whole IPv4 runout thing was a problem and all 
these really smart people have been arguing and arguing about how to 
reclaim and preserve IPv4 space to prevent the runout from occurring too 
early before the Internet world is adequately prepared.  Now I know that 
it is not a problem.  Seems like this whole thread (and a few hundred 
others) are moot points and a waste of bandwidth.






From bmanning at vacation.karoshi.com  Wed Oct 22 11:10:40 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 22 Oct 2008 15:10:40 +0000
Subject: [arin-ppml] ["Lying Idle"]
In-Reply-To: <9BD7A07D-EC05-4C9D-8325-CB9DA144A9D4@svcolo.com>
References: <36790.1224363677@nsa.vix.com>
	<20081019155104.GA23549@vacation.karoshi.com.>
	<77143.1224436916@nsa.vix.com>
	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>
	<87466.1224546974@nsa.vix.com>
	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>
	<36202.1224615272@nsa.vix.com>
	<B17175B1-7411-4B63-85A8-E8BF8335845D@svcolo.com>
	<20081021225338.GA16319@vacation.karoshi.com.>
	<9BD7A07D-EC05-4C9D-8325-CB9DA144A9D4@svcolo.com>
Message-ID: <20081022151040.GA23763@vacation.karoshi.com.>

On Tue, Oct 21, 2008 at 11:03:56PM -0700, Jo Rhett wrote:
> On Oct 21, 2008, at 3:53 PM, bmanning at vacation.karoshi.com wrote:
> >	this is patently false Jo. ARIN has put forth effort and
> >	continues to do so.  As Leslie mentioned last week, all
> >	the /8 holders have had outreach - and there are some
> >	14,000+ outstanding cases pending.  If Legacy Holders
> >	don't know, they should soon.
> 
> 
> Patently false how?  From my own experience, that we discussed during  
> lunch last week:  I had 3 legacy blocks which I was the primary  
> contact for.  I had misunderstood the RSA contract to mean that these  
> blocks were covered under the RSA I signed for new blocks assigned.   
> This situation persisted for 13 years (admittedly 2 of which predate  
> ARIN) without me ever *EVER* receiving a single e-mail from ARIN  
> saying "This block is not covered by an RSA.  Would you please fill  
> this out and return it?" or any variant thereof.

	then our experiences differ. I've received mail from ARIN
	about a series of resources that were assigned pre-ARIN and would	
	would I be willing to place them under some form of RSA.
	Granted, the contacts have been in the last 24 months, so there
	have been years when ARIN was busy w/ other things.

	perhaps I was part of a pilot group, I don't know.  I do know
	that Leslie reported that some 14,000 cases were in process
	(where process was identification, notification, etc...)

	Its clear that you have not had the same experience as I have.
	I am confident that soon you will.  I have found that using the 
	secure login capability is very helpful in maintaining accurate 
	data about the resources under ones stewardship.
	
> -- 
> Jo Rhett
> senior geek
> Silicon Valley Colocation
> Support Phone: 408-400-0550

--bill


From trejrco at gmail.com  Wed Oct 22 11:24:27 2008
From: trejrco at gmail.com (TJ)
Date: Wed, 22 Oct 2008 11:24:27 -0400
Subject: [arin-ppml] "Millions of Internet
	Addresses	Are	LyingIdle"	(slashdot)
In-Reply-To: <48FE4A57.8090104@usfamily.net>
References: <C0F2465B4F386241A58321C884AC7ECC08D33EAD@E03MVZ2-UKDY.domain1.systemhost.net>
	<48FE4A57.8090104@usfamily.net>
Message-ID: <009301c9345a$46586930$d3093b90$@com>

Although this thread is devolving, let me add one comment


>>>3) Most importantly, how can the transition be incentivized?
>> 
>> 
>> By pushing requests up the supply chain which is one thing that
>> governments are trying to do by mandating that publicly funded 
>> agencies begin migrating to IPv6.
>> 
>
>Ok, after we get all those publicly-funded agencies to IPv6, then all we 
>have to worry about is all the rest of the Internet.

I don't believe that was quite the point.  The US Federal Government is one
of, if not the, largest IT products and services consumer in the world.
Getting IPv6 requirements added to those purchases not only gets them ready,
but forces ("incentivizes") the vendors & providers to get ready as well.  I
believe the latter was the real goal.


/TJ ... re-lurking



From sleibrand at internap.com  Wed Oct 22 12:19:40 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 22 Oct 2008 09:19:40 -0700
Subject: [arin-ppml] ["Lying Idle"]
In-Reply-To: <20081022151040.GA23763@vacation.karoshi.com.>
References: <36790.1224363677@nsa.vix.com>	<20081019155104.GA23549@vacation.karoshi.com.>	<77143.1224436916@nsa.vix.com>	<185B7113-F0D7-428B-91E4-05F47B17DE93@svcolo.com>	<87466.1224546974@nsa.vix.com>	<F4CC10E2-F892-40DD-BB0A-6E6AC7D720A6@svcolo.com>	<36202.1224615272@nsa.vix.com>	<B17175B1-7411-4B63-85A8-E8BF8335845D@svcolo.com>	<20081021225338.GA16319@vacation.karoshi.com.>	<9BD7A07D-EC05-4C9D-8325-CB9DA144A9D4@svcolo.com>
	<20081022151040.GA23763@vacation.karoshi.com.>
Message-ID: <48FF529C.2060201@internap.com>

bmanning at vacation.karoshi.com wrote:
> On Tue, Oct 21, 2008 at 11:03:56PM -0700, Jo Rhett wrote:
>> I had 3 legacy blocks which I was the primary  
>> contact for.  I had misunderstood the RSA contract to mean that these  
>> blocks were covered under the RSA I signed for new blocks assigned.   
>> This situation persisted for 13 years (admittedly 2 of which predate  
>> ARIN) without me ever *EVER* receiving a single e-mail from ARIN  
>> saying "This block is not covered by an RSA.  Would you please fill  
>> this out and return it?" or any variant thereof.
> 
> 	then our experiences differ. I've received mail from ARIN
> 	about a series of resources that were assigned pre-ARIN and would	
> 	would I be willing to place them under some form of RSA.
> 	Granted, the contacts have been in the last 24 months, so there
> 	have been years when ARIN was busy w/ other things.
> 
> 	perhaps I was part of a pilot group, I don't know.  I do know
> 	that Leslie reported that some 14,000 cases were in process
> 	(where process was identification, notification, etc...)
> 
> 	Its clear that you have not had the same experience as I have.
> 	I am confident that soon you will.  I have found that using the 
> 	secure login capability is very helpful in maintaining accurate 
> 	data about the resources under ones stewardship.

Per one of the presentations (Leslie's?), ARIN started with Class A legacy 
holders, then Class B, and is now just starting with Class C.  Most likely 
that accounts for the differences in whether/when each of you got notices.

-Scott


From tedm at ipinc.net  Wed Oct 22 12:52:07 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 22 Oct 2008 09:52:07 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are Lying
	Idle"(slashdot)
In-Reply-To: <FB2C3912-A97B-4877-8D47-AD9E0521E78B@svcolo.com>
Message-ID: <033EBA35EE7844A2953554339A31303F@tedsdesk>



> -----Original Message-----
> From: Jo Rhett [mailto:jrhett at svcolo.com] 
> Sent: Tuesday, October 21, 2008 10:57 PM
> To: Ted Mittelstaedt
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] "Millions of Internet Addresses Are 
> Lying Idle"(slashdot)
> 
> 
> On Oct 21, 2008, at 2:39 PM, Ted Mittelstaedt wrote:
> > They ARE doing it.  Anyone who has allocated space gets a 
> bill every 
> > year.  If their contact info becomes invalid, the bill then gets
> > returned
> > by USPS and after 6 months or whatever, the account goes to  
> > collections
> > and the allocated IP addressing becomes forfeit.
> 
> 
> That is the billing contact, entirely separate from the POC data.
> 

So you are saying that ARIN still has entries in it's POC database for
orgs that paid for allocations then stopped paying for them a few
years later when those orgs went bankrupt or otherwise disappeared?

I am sure ARIN staff would be most interested in this facinating
interpretation of how badly they mis-manage the WHOIS database.

Ted



From tedm at ipinc.net  Wed Oct 22 13:12:26 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 22 Oct 2008 10:12:26 -0700
Subject: [arin-ppml] Why not NAT for Dorms (Was: Suggestion: charging
	for IPv4 space)
In-Reply-To: <48FE30FA.22080.55CC496@farmer.umn.edu>
Message-ID: <D7BC51477FCB4A939F6E237544CFFDC6@tedsdesk>



> -----Original Message-----
> From: David Farmer [mailto:farmer at umn.edu] 
> Sent: Tuesday, October 21, 2008 5:44 PM
> To: Ted Mittelstaedt
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Why not NAT for Dorms (Was: 
> Suggestion: charging for IPv4 space)
> 
> 
> On 21 Oct 2008 Ted Mittelstaedt wrote:
> 
> > For myself I do not understand why all of these academic users keep 
> > throwing up examples of student dormotories that chew up 
> vast blocks 
> > of IPv4.  Why does ANY student that is getting Internet 
> connectivity 
> > for free from the college expect to get a public IPv4 number?
> 
> There are so many reasons, let me educate you on just a few;
> 

Hi David,

  Thank you very much for this specific example of the
financial disincentives of a large IPv4 holder to release
IPv4.  As you may possibly have guessed, I threw that question
out there as much as a rhetorical question as anything else.

  I could have simply responded to the people posting to this
list that large IPv4 holders aren't going to give up their
allocations, no matter how much plum jam or prune juice
they think is out there.

  But, you did a much better job of it for me.

  Hopefully the plum eaters take note and will drop their
insistence that there's millions of IPv4 out there just
waiting for the picking.

Ted




From stephen at sprunk.org  Wed Oct 22 13:35:30 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 22 Oct 2008 12:35:30 -0500
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <033EBA35EE7844A2953554339A31303F@tedsdesk>
References: <033EBA35EE7844A2953554339A31303F@tedsdesk>
Message-ID: <48FF6462.2040705@sprunk.org>

Ted Mittelstaedt wrote:
>> -----Original Message-----
>> From: Jo Rhett [mailto:jrhett at svcolo.com] 
>>
>> On Oct 21, 2008, at 2:39 PM, Ted Mittelstaedt wrote:
>>     
>>> They ARE doing it.  Anyone who has allocated space gets a bill every year.  If their contact info becomes invalid, the bill then gets returned by USPS and after 6 months or whatever, the account goes to collections and the allocated IP addressing becomes forfeit.
>>>       
>> That is the billing contact, entirely separate from the POC data.
>>     
>
> So you are saying that ARIN still has entries in it's POC database for orgs that paid for allocations then stopped paying for them a few years later when those orgs went bankrupt or otherwise disappeared?
>
> I am sure ARIN staff would be most interested in this facinating interpretation of how badly they mis-manage the WHOIS database.
>   

Interpretation?  Mis-management?  There was a recent presentations (I 
forget by who) which called out the number of "orphan" POC entries.  
This isn't news, nor is it necessarily bad.  Orphan POCs do not cause 
any problems other than taking up a few extra bytes in the database.

However, I don't think that is the problem Jo was referring to.  That an 
org's Accounts Payable department pays an invoice on time does _not_ 
guarantee that all the various POCs listed on each of their 
registrations are still valid.

S


From stephen at sprunk.org  Wed Oct 22 13:40:33 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 22 Oct 2008 12:40:33 -0500
Subject: [arin-ppml] "Millions
	of	Internet	AddressesAre	LyingIdle"	(slashdot)
In-Reply-To: <48FEDE99.4070607@usfamily.net>
References: <C0F2465B4F386241A58321C884AC7ECC08D33EEF@E03MVZ2-UKDY.domain1.systemhost.net>
	<48FEDE99.4070607@usfamily.net>
Message-ID: <48FF6591.5050704@sprunk.org>

Ron Cleven wrote:
> michael.dillon at bt.com wrote:
>   
>>> Obviously nobody on this list cares about establishing simple market-based incentives to get IPv6 moving.
>>>       
>> That is not ARIN's job.
>>     
>
> This must be ARINv4 list.  Is there an ARINv6 list?  How did all that 
> IPv6 crap get on the ARIN.NET web site?

ARIN is chartered to steward number resources; it is not chartered to 
promote one type of resource over the others.  Mr. Curran has made that 
quite clear in past discussions.

> I forgot about your previous point that ARIN does not worry about any solutions being practical. Hence, I compounded my error, as obviously using simple market-based incentives to get IPv6 moving falls dangerously into the realm of the practical.

ARIN already _does_ offer incentives (through policy and fee schedule) 
for IPv6 adoption, and IMHO that is already leaning a bit over the line.

> Don't worry, I promise I will never make any more suggestions that violate that tenet.  Heaven help us if someone (as another example of such stupidity) actually suggested that ARIN would phase out IPv4 allocations to organizations who do not, in parallel, support IPv6

IMHO, that would not meet ARIN's responsibility of stewardship for the 
IPv4 space.  Incentives are one thing, but punishment is quite another.

S


From tedm at ipinc.net  Wed Oct 22 14:19:01 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 22 Oct 2008 11:19:01 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <48FF6462.2040705@sprunk.org>
Message-ID: <1A34D6582AB94873AEF3304FFF1A3AAB@tedsdesk>



> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
> Sent: Wednesday, October 22, 2008 10:36 AM
> To: Ted Mittelstaedt
> Cc: 'Jo Rhett'; ppml at arin.net
> Subject: Re: [arin-ppml] "Millions of Internet Addresses Are 
> Lying Idle"(slashdot)
> 
> 
> Ted Mittelstaedt wrote:
> >> -----Original Message-----
> >> From: Jo Rhett [mailto:jrhett at svcolo.com]
> >>
> >> On Oct 21, 2008, at 2:39 PM, Ted Mittelstaedt wrote:
> >>     
> >>> They ARE doing it.  Anyone who has allocated space gets a 
> bill every 
> >>> year.  If their contact info becomes invalid, the bill 
> then gets returned by USPS and after 6 months or whatever, 
> the account goes to collections and the allocated IP 
> addressing becomes forfeit.
> >>>       
> >> That is the billing contact, entirely separate from the POC data.
> >>     
> >
> > So you are saying that ARIN still has entries in it's POC 
> database for 
> > orgs that paid for allocations then stopped paying for them a few 
> > years later when those orgs went bankrupt or otherwise disappeared?
> >
> > I am sure ARIN staff would be most interested in this facinating 
> > interpretation of how badly they mis-manage the WHOIS database.
> >   
> 
> Interpretation?  Mis-management?  There was a recent presentations (I 
> forget by who) which called out the number of "orphan" POC entries.  

Stephen,

  You missed Jo's original statement, I'll repost it here:

"...Asking ARIN to  
validate POC data for RSA contractees is like reminding the teacher to  
show up in class.  It is function 1 of their job.  Why aren't they  
doing it?..."

Jo wasn't concerned with orphaned POCs but rather with RSA contractees
that had stale POC data.  By definition, an org that isn't paying it's
bill is no longer a RSA contractee.  (ie: they have broken their contract)
and ARIN would remove numbering resources allocated to it, thus
"orphaning" all the POCs.  I presumed she wouldn't care if orphan
POC data was stale. 

> This isn't news, nor is it necessarily bad.  Orphan POCs do not cause 
> any problems other than taking up a few extra bytes in the database.
> 

Well, actually there is one problem and that is of searching, it makes
it a bit more difficult.  A minor one, though.

> However, I don't think that is the problem Jo was referring 
> to.  That an 
> org's Accounts Payable department pays an invoice on time does _not_ 
> guarantee that all the various POCs listed on each of their 
> registrations are still valid.
> 

Both you and Jo are asserting here that ARIN billing addressing info
is separate from the POC info associated with that org.  Do EITHER of you
have ANY authoratative statement from anyone at ARIN that states this?

Because if you do, I feel another NPRM policy proposal change suggestion
coming on...

Ted



From Lee.Howard at stanleyassociates.com  Wed Oct 22 14:35:32 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Wed, 22 Oct 2008 14:35:32 -0400
Subject: [arin-ppml] [was Re: Millions of slashdotters are idle]
In-Reply-To: <48FF6591.5050704@sprunk.org>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A56B@CL-S-EX-1.stanleyassociates.com>

> >>> Obviously nobody on this list cares about establishing 
> simple market-based incentives to get IPv6 moving.
> >>>       
> >> That is not ARIN's job.

I should've chimed in a couple of messages ago; ARIN's job is
not to establish market-based incentives for anything.  There's
nothing inherently wrong with doing so, it's just that we'd
need community consensus that we should do so.  To date, there
has not been member consensus that ARIN should increase fees
by order(s) of magnitude in order to drive organizations away
from IPv4.

IMHO.

> > This must be ARINv4 list.  Is there an ARINv6 list?  How 
> did all that
> > IPv6 crap get on the ARIN.NET web site?
> 
> ARIN is chartered to steward number resources; it is not 
> chartered to promote one type of resource over the others.  
> Mr. Curran has made that quite clear in past discussions.

Well, the Board has said that while you are quite welcome to
continue using any IPv4 addresses that are assigned/allocated
to you, you should plan to use IPv6 soon, if you will need 
more addresses later.  Or even if you want to be reachable or
to reach people who only get IPv6 addresses later.

I don't think we'll say that IPv6 is better than IPv4, but I
do think we have a responsibility to warn everyone about some
changes that will be happening in the not-too-distant future,
and suggest actions in preparation.

> > I forgot about your previous point that ARIN does not worry 
> about any solutions being practical. Hence, I compounded my 
> error, as obviously using simple market-based incentives to 
> get IPv6 moving falls dangerously into the realm of the practical.
> 
> ARIN already _does_ offer incentives (through policy and fee 
> schedule) for IPv6 adoption, and IMHO that is already leaning 
> a bit over the line.

In the cases of fee waivers, we were pretty strongly urged to make
sure that fees would not be a disincentive to IPv6 adoption.  You
may note that the amount of IPv6 fee waived is declining again at
the end of the year--get yours now!
http://www.arin.net/billing/fee_schedule.html#waivers
 
 
> > Don't worry, I promise I will never make any more suggestions that 
> > violate that tenet.  Heaven help us if someone (as another 
> example of 
> > such stupidity) actually suggested that ARIN would phase out IPv4 
> > allocations to organizations who do not, in parallel, support IPv6
> 
> IMHO, that would not meet ARIN's responsibility of stewardship for the
> IPv4 space.  Incentives are one thing, but punishment is 
> quite another.

There was a proposal along those lines,
http://www.arin.net/policy/proposals/2007_16.html
but the author withdrew it before it had a chance to be discussed at a
meeting.

IMHO.  One could argue:

Good stewardship on behalf of the community means allocating to 
those who will be good stewards.  Anyone who is not preparing to 
avoid future IPv4 requests is not a good steward.  

IMHO. I cannot emphasize enough how these comments are mine alone, and
have never been discussed with or presented to the Board.  IMHO.  So
nobody has yet had a chance to convince me how wrong I am.  IMHO. IMHO,
IMHO, IMHO, IMHO.

Lee



From tedm at ipinc.net  Wed Oct 22 14:52:10 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 22 Oct 2008 11:52:10 -0700
Subject: [arin-ppml] [was Re: Millions of slashdotters are idle]
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A56B@CL-S-EX-1.stanleyassociates.com>
Message-ID: <44C3BECE5EAA4548AFC2F7822244C94D@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee
> Sent: Wednesday, October 22, 2008 11:36 AM
> To: Stephen Sprunk; Ron Cleven
> Cc: ppml at arin.net
> Subject: [arin-ppml] [was Re: Millions of slashdotters are idle]
> 
> 
> > >>> Obviously nobody on this list cares about establishing
> > simple market-based incentives to get IPv6 moving.
> > >>>       
> > >> That is not ARIN's job.
> 
> I should've chimed in a couple of messages ago; ARIN's job is 
> not to establish market-based incentives for anything.  
> There's nothing inherently wrong with doing so, it's just 
> that we'd need community consensus that we should do so.  To 
> date, there has not been member consensus that ARIN should 
> increase fees by order(s) of magnitude in order to drive 
> organizations away from IPv4.
> 

It is disingenuous to claim that ARIN's job is not to establish
market-based incentives for anything.  ARIN already engages in this,
the IPv6 fee waiver a market-based incentive, and the "greater
of IPv4 or IPv6 costs" registration policy is also a market-based
incentive.  And as I recall both of those were from the ARIN board,
not from the membership.

In addition, the sliding fees on IPv4 are also a market-based
incentive, although you may deny this, the fact of the matter is that
on a per-IP-address basis, the larger allocations are cheaper.  ARIN
favors the larger ISPs and networks in this manner.

Further, the requirement that orgs go to upstream providers for
IP numbering unless they are large is also a market incentive for
the org to become large before obtaining a portable allocation.

Also, as I understand it, fee amounts are not set in the NPRM and
there is thus no mechanism for the membership to have any
consensus on fee amounts.



Ted



From stephen at sprunk.org  Wed Oct 22 14:52:40 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 22 Oct 2008 13:52:40 -0500
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <1A34D6582AB94873AEF3304FFF1A3AAB@tedsdesk>
References: <1A34D6582AB94873AEF3304FFF1A3AAB@tedsdesk>
Message-ID: <48FF7678.6090206@sprunk.org>

Ted Mittelstaedt wrote:
>> -----Original Message-----
>> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
>>
>> Ted Mittelstaedt wrote:
>>     
>>>> -----Original Message-----
>>>> From: Jo Rhett [mailto:jrhett at svcolo.com]
>>>>
>>>> On Oct 21, 2008, at 2:39 PM, Ted Mittelstaedt wrote:
>>>>     
>>>>         
>>>>> They ARE doing it.  Anyone who has allocated space gets a bill every year.  If their contact info becomes invalid, the bill then gets returned by USPS and after 6 months or whatever, the account goes to collections and the allocated IP addressing becomes forfeit.
>>>>>           
>>>> That is the billing contact, entirely separate from the POC data.   
>>>>         
>>> So you are saying that ARIN still has entries in it's POC database for orgs that paid for allocations then stopped paying for them a few years later when those orgs went bankrupt or otherwise disappeared?
>>>
>>> I am sure ARIN staff would be most interested in this facinating 
>>> interpretation of how badly they mis-manage the WHOIS database.
>>>       
>> Interpretation?  Mis-management?  There was a recent presentations (I 
>> forget by who) which called out the number of "orphan" POC entries.  
>>     
>
> Stephen,
>
>   You missed Jo's original statement, I'll repost it here:
>
> "...Asking ARIN to validate POC data for RSA contractees is like reminding the teacher to show up in class.  It is function 1 of their job.  Why aren't they doing it?..."
>
> Jo wasn't concerned with orphaned POCs but rather with RSA contractees
> that had stale POC data.

There are many orphaned POCs and even OrgIDs that are (or were) 
associated with an RSA contractee somehow.  Most are probably stale.

> By definition, an org that isn't paying it's bill is no longer a RSA contractee.  (ie: they have broken their contract) and ARIN would remove numbering resources allocated to it, thus "orphaning" all the POCs.

That's not the only reason that records get orphaned.

> I presumed she wouldn't care if orphan POC data was stale. 
>   

IMHO _any_ stale information in a database is a Bad Thing(tm).  If we 
don't want to spend the effort to clean up stale orphans, they should be 
deleted.

>> However, I don't think that is the problem Jo was referring to.  That an org's Accounts Payable department pays an invoice on time does _not_ 
>> guarantee that all the various POCs listed on each of their 
>> registrations are still valid.
>>     
>
> Both you and Jo are asserting here that ARIN billing addressing info
> is separate from the POC info associated with that org.  Do EITHER of you
> have ANY authoratative statement from anyone at ARIN that states this?
>   

Directly from ARIN staff?  Not me.  However, it's a trivial thing to 
look up my own employer's records and see stale and/or orphaned POCs and 
OrgIDs, and if we weren't paying our bills I presume our ASN would have 
been taken away by now.  I thus deduce it is possible, though I'm open 
to correction.

> Because if you do, I feel another NPRM policy proposal change suggestion
> coming on...
>   

Are you proposing that a "billing" contact be added, in addition to the 
"admin", "tech", "abuse", and "noc" contacts?

None of the existing (or at least visible) POC types necessarily has 
anything to do with the name/address where invoices are mailed, which is 
all that receipt of payment validates.  Besides, an org could have 
hundreds or thousands of networks, each with different tech/abuse/noc 
contacts, any one of which could be stale; how could paying one invoice, 
sent to some Accounts Payable person, validate all of them?

S


From kkargel at polartel.com  Wed Oct 22 14:54:36 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 22 Oct 2008 13:54:36 -0500
Subject: [arin-ppml] [was Re: Millions of slashdotters are idle]
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A56B@CL-S-EX-1.stanleyassociates.com>
References: <48FF6591.5050704@sprunk.org>
	<369EB04A0951824ABE7D8BAC67AF9BB40BB7A56B@CL-S-EX-1.stanleyassociates.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AAE4@mail>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee
> Sent: Wednesday, October 22, 2008 1:36 PM
> To: Stephen Sprunk; Ron Cleven
> Cc: ppml at arin.net
> Subject: [arin-ppml] [was Re: Millions of slashdotters are idle]
> 
> > >>> Obviously nobody on this list cares about establishing
> > simple market-based incentives to get IPv6 moving.
> > >>>       
> > >> That is not ARIN's job.
> 
> I should've chimed in a couple of messages ago; ARIN's job is 
> not to establish market-based incentives for anything.  
> There's nothing inherently wrong with doing so, it's just 
> that we'd need community consensus that we should do so.  To 
> date, there has not been member consensus that ARIN should 
> increase fees by order(s) of magnitude in order to drive 
> organizations away from IPv4.
> 
> IMHO.
> 
> > > This must be ARINv4 list.  Is there an ARINv6 list?  How
> > did all that
> > > IPv6 crap get on the ARIN.NET web site?
> > 
> > ARIN is chartered to steward number resources; it is not 
> chartered to 
> > promote one type of resource over the others.
> > Mr. Curran has made that quite clear in past discussions.
> 

I personally agree with what you are saying.  In The ARIN bylaws the ARIN
mission is explicitly stated as:

"ARIN shall be operated exclusively for nonprofit educational, charitable,
and scientific
purposes, including, without limitation, the purposes stated in ARIN's
Articles of
Incorporation..."

There is nothing in there about promoting one protocol over another with
fees or other incentives, there is nothing about concern for profit
enterprises.



However, in the Articles of Incorporation the task charging ARIN "to manage
the allocation and registration of Internet resource" is eighth on the list,
well under the task in fifth place "to do all and everything necessary to
enhance the growth of the Internet and the prospects for competition among
Internet Service Providers by encouraging the exploration and implementation
of solutions to Internet Protocol number scarcity issues".

Depending on interpretation of that task it could be well within the charter
to promote IPv6 via unrestricted means.

-------------- 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/20081022/829ee10a/attachment.bin>

From jrhett at svcolo.com  Wed Oct 22 15:33:42 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 22 Oct 2008 12:33:42 -0700
Subject: [arin-ppml] fee schedule
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A56B@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A56B@CL-S-EX-1.stanleyassociates.com>
Message-ID: <F5773552-BD79-4C0F-A81B-C26F54836F68@svcolo.com>

On Oct 22, 2008, at 11:35 AM, Howard, W. Lee wrote:
> http://www.arin.net/billing/fee_schedule.html#waivers


Howard, I'd like to point out that this page is darn near  
indecipherable by most people.  It has confused every person in our  
company who tried to read it, and frankly I only learned what we would  
be paying by calling ARIN and having it explained to me.

And it's not the math -- I'm great at math.  It's the in-out-who-is- 
what-huh? nature of the document.  This is a build-your-own-path story  
that someone forgot to include the junctions in.

And I just reread it, and now I'm even more confused than I was  
originally.  From what I can see, acquiring a simple IPv6 block for  
testing/deployment in our network will make us liable for $9k a year  
within 4 years.  Why on god's green earth would I want to do that?

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From info at arin.net  Wed Oct 22 15:34:09 2008
From: info at arin.net (Member Services)
Date: Wed, 22 Oct 2008 15:34:09 -0400
Subject: [arin-ppml] 2008-5: Dedicated IPv4 block to facilitate IPv6
 deployment - Last Call
Message-ID: <48FF8031.4010807@arin.net>

Policy Proposal 2008-5
Dedicated IPv4 block to facilitate IPv6 deployment

On 17 October 2008 the ARIN Advisory Council (AC), acting under the
provisions of the ARIN Internet Resource Policy Evaluation Process,
determined that the community supports this proposal and moves it to
last call.

Feedback is encouraged during this last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire at 23:59 EDT, 7 November 2008.

The policy proposal text is provided below and is also available at:
http://www.arin.net/policy/proposals/2008_5.html

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 2008-5
Dedicated IPv4 block to facilitate IPv6 deployment

Author: Alain Durand

Date: 6 June 2008

Proposal type: New

Policy term: Permanent

Policy statement:

When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
or NAT464 translators. ARIN staff will use their discretion when
evaluating justifications.

This block will be subject to a minimum size allocation of /28 and a
maximum size allocation of /24. ARIN should use sparse allocation when
possible within that /10 block.

In order to receive an allocation or assignment under this policy:

   1. the applicant may not have received resources under this policy in
      the preceding six months;
   2. previous allocations/assignments under this policy must continue
      to meet the justification requirements of this policy;
   3. previous allocations/assignments under this policy must meet the
      utilization requirements of end user assignments;
   4. the applicant must demonstrate that no other allocations or
      assignments will meet this need;
   5. on subsequent allocation under this policy, ARIN staff may require
      applicants to renumber out of previously allocated / assigned
      space under this policy in order to minimize non-contiguous
      allocations;
   6. recipient organizations must be members in good standing of ARIN.

Rationale for reserving IPv4 space:

This policy provides predictability on how the end game of IPv4 is going
to be played after IANA completion. It will facilitate IPv6 deployment
by ensuring that some small chunks of IPv4 space will remain available
for a long time to ease the co-existence of IPv4 & IPv6.

Rationale for reserving a contiguous /10

This is a balance between setting aside too much space and not having
enough to facilitate IPv6 deployment for many years. Out of the last /8,
that would leave the equivalent of 3 /10 to ARIN either for business as
usual or for other policies in the spirit of this one.

A /10 represents 4,194,304 IP addresses, If all of them were to be used
in NAT-PT or NAT464 type devices with a consolidation factor of 100
users behind each IP address, that would represent about 400 million users.

Most networks today filter IPv4 announcements more specific than /24.
This policy creates allocations & assignment prefixes as long as /28.
Allocating out of a contiguous block will mitigate the impact of this
policy on filter lists.

Rationale for minimum size allocation of /28

This minimum size allocation will put a cap at 250k additional entries
in the global IPv4 routing table.

Rationale for maximum size allocation of /24 and for the 6 month delay
between allocations

This maximum allocation size coupled with the requirement of a 6 months
delay between allocations will prevent hoarding and make sure this pool
will last several years.

Rationale for forced renumbering for further allocation

The minimum allocation size of /28 may create a huge increase in the
IPv4 routing table size. Forcing renumbering for subsequent allocations
under this policy will somehow limit the growth of the routing table
size by enabling the announcement of aggregated space. It is expected
that the savings in routing table entries will outweigh the pain of
forced renumbering.

However, renumbering is never an easy task, so it should only be
considered as last resort. it is expected that sparse allocation
techniques will prevent the need of force renumbering for a fairly long
time.

Note: This policy proposal hints that the /10 should come out of the
last /8 received by ARIN from IANA. However, it does not say so
explicitly, leaving the final decision up to the ARIN staff.

Timetable for implementation:

As soon as ARIN gets its last /8 allocation from IANA.







From info at arin.net  Wed Oct 22 15:39:25 2008
From: info at arin.net (Member Services)
Date: Wed, 22 Oct 2008 15:39:25 -0400
Subject: [arin-ppml] 2008-4: Minimum Allocation in the Caribbean Region -
	Last Call
Message-ID: <48FF816D.7060207@arin.net>

Policy Proposal 2008-4
Minimum Allocation in the Caribbean Region

On 17 October 2008 the ARIN Advisory Council (AC), acting under the
provisions of the ARIN Internet Resource Policy Evaluation Process,
determined that the community supports this proposal and moves it to
last call as amended. The AC removed the second bullet from the 4.8.1
text because it was redundant, and modified the region to refer to it as
the Caribbean and North Atlantic Islands.

Feedback is encouraged during this last call period. All comments should
be provided to the Public Policy Mailing List. This last call will
expire at 23:59 EDT, 7 November 2008.

The policy proposal text is provided below and is also available at:
http://www.arin.net/policy/proposals/2008_4.html

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##

Policy Proposal 2008-4
Minimum Allocation in the Caribbean Region

Author: Cathy Aronson and Paul Andersen

Date: 22 October 2008

Proposal type: new

Policy term: renewable

Policy statement:

Add the following as section 4.8 of NRPM:

4.8.   Minimum Allocation for the Caribbean and North Atlantic Islands
The minimum IPv4 allocation size for ISPs from the Caribbean and North
Atlantic Islands sector of the ARIN region is /22.

       4.8.1. Allocation Criteria

        *  The requesting organization must show the efficient
        utilization of an entire previously allocated /22 from their
        upstream ISP. This allocation (/22) may have been provided
        by an ISP's upstream provider(s), and does not have to be
        contiguous address space. The organization must meet the
        requirement of efficient use of 4 /24s.

        *  Utilization Reporting and Justification. All other ARIN policies
        regarding the reporting of justification information for the
        allocation of IPv4 and IPv6 address space will remain in effect.

Rationale:

ARIN staff have noted that organizations in the Caribbean region have
problems meeting the current criteria due to the fact that the
population in the region is smaller than that of Canada and the US.
There is also a lack of competition with many countries in the region
faced with a monopoly or duopoly situation in terms of transport providers.

To spur development in the region a similar proposal was passed in this
region for the portion of the African region that ARIN administered
prior to the formation of AfriNIC. This proposal seeks a similar outcome.

Timetable for implementation: immediate






From info at arin.net  Wed Oct 22 15:40:18 2008
From: info at arin.net (Member Services)
Date: Wed, 22 Oct 2008 15:40:18 -0400
Subject: [arin-ppml] AC to work with proposal authors
Message-ID: <48FF81A2.70307@arin.net>

On 17 October 2008 the ARIN Advisory Council (AC), acting under the
provisions of the ARIN Internet Resource Policy Evaluation Process,
determined that the following policy proposals need to be revised:

2008-7: Whois Integrity Policy Proposal

2008-6: Emergency Transfer Policy for IPv4 Addresses

2008-3: Community Networks IPv6 Allocation

2007-14: Resource Review Process

The policy proposal texts are available at the Policy Proposal Archive,
located at:
http://www.arin.net/policy/proposal_archive.html

The AC postponed making a decision on the following proposals in order
to work with the authors with the intent to merge the proposals:

Annual WHOIS POC Validation
Whois POC e-mail cleanup
Whois Authentication Alternatives

These proposals are in the AC Initial Review stage and can be found at:
http://www.arin.net/policy/proposals/submission_archive.html

Regards,

Member Services Department
American Registry for Internet Numbers (ARIN)



From info at arin.net  Wed Oct 22 15:40:54 2008
From: info at arin.net (Member Services)
Date: Wed, 22 Oct 2008 15:40:54 -0400
Subject: [arin-ppml] 2008-2: IPv4 Transfer Policy Proposal - Abandoned
Message-ID: <48FF81C6.2010902@arin.net>

Policy Proposal 2008-2
IPv4 Transfer Policy Proposal

On 17 October 2008 the ARIN Advisory Council (AC), acting under the
provisions of the ARIN Internet Resource Policy Evaluation Process,
determined that this proposal did not have the support of the community
and decided to abandon it. The AC stated that they are not abandoning
the concept of transfers, however they are abandoning this specific
proposal.

At this time the author of the proposal may elect to use the petition
process to attempt to advance the proposal. The deadline for the author
to initiate a petition is 23:59 EDT, 29 October 2008. If the author
chooses not to petition or the petition is unsuccessful, then the
determination of the AC stands and the proposal is abandoned.

The policy proposal text is provided below and is also available at:
http://www.arin.net/policy/proposals/2008_2.html

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.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: 18 September 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 De-aggregation 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
de-aggregation.

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 tedm at ipinc.net  Wed Oct 22 15:41:30 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 22 Oct 2008 12:41:30 -0700
Subject: [arin-ppml] "Millions of Internet Addresses Are
	Lying	Idle"(slashdot)
In-Reply-To: <48FF7678.6090206@sprunk.org>
Message-ID: <06B53642A99740DAB51F19539B1E5F6E@tedsdesk>



> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
> Sent: Wednesday, October 22, 2008 11:53 AM
> To: Ted Mittelstaedt
> Cc: 'Jo Rhett'; ppml at arin.net
> Subject: Re: [arin-ppml] "Millions of Internet Addresses Are 
> Lying Idle"(slashdot)
> 
> 
> Ted Mittelstaedt wrote:
> >> -----Original Message-----
> >> From: Stephen Sprunk [mailto:stephen at sprunk.org]
> >>
> >> Ted Mittelstaedt wrote:
> >>     
> >>>> -----Original Message-----
> >>>> From: Jo Rhett [mailto:jrhett at svcolo.com]
> >>>>
> >>>> On Oct 21, 2008, at 2:39 PM, Ted Mittelstaedt wrote:
> >>>>     
> >>>>         
> >>>>> They ARE doing it.  Anyone who has allocated space gets a bill 
> >>>>> every year.  If their contact info becomes invalid, the 
> bill then gets returned by USPS and after 6 months or 
> whatever, the account goes to collections and the allocated 
> IP addressing becomes forfeit.
> >>>>>           
> >>>> That is the billing contact, entirely separate from the 
> POC data.   
> >>>>         
> >>> So you are saying that ARIN still has entries in it's POC 
> database 
> >>> for orgs that paid for allocations then stopped paying for them a 
> >>> few years later when those orgs went bankrupt or otherwise 
> >>> disappeared?
> >>>
> >>> I am sure ARIN staff would be most interested in this facinating
> >>> interpretation of how badly they mis-manage the WHOIS database.
> >>>       
> >> Interpretation?  Mis-management?  There was a recent 
> presentations (I
> >> forget by who) which called out the number of "orphan" POC 
> entries.  
> >>     
> >
> > Stephen,
> >
> >   You missed Jo's original statement, I'll repost it here:
> >
> > "...Asking ARIN to validate POC data for RSA contractees is like 
> > reminding the teacher to show up in class.  It is function 
> 1 of their 
> > job.  Why aren't they doing it?..."
> >
> > Jo wasn't concerned with orphaned POCs but rather with RSA 
> contractees 
> > that had stale POC data.
> 
> There are many orphaned POCs and even OrgIDs that are (or were) 
> associated with an RSA contractee somehow.  Most are probably stale.
> 
> > By definition, an org that isn't paying it's bill is no 
> longer a RSA 
> > contractee.  (ie: they have broken their contract) and ARIN would 
> > remove numbering resources allocated to it, thus 
> "orphaning" all the 
> > POCs.
> 
> That's not the only reason that records get orphaned.
> 
> > I presumed she wouldn't care if orphan POC data was stale.
> >   
> 
> IMHO _any_ stale information in a database is a Bad Thing(tm).  If we 
> don't want to spend the effort to clean up stale orphans, 
> they should be 
> deleted.
> 
> >> However, I don't think that is the problem Jo was 
> referring to.  That an org's Accounts Payable department pays 
> an invoice on time does _not_ 
> >> guarantee that all the various POCs listed on each of their 
> >> registrations are still valid.
> >>     
> >
> > Both you and Jo are asserting here that ARIN billing addressing info
> > is separate from the POC info associated with that org.  Do 
> EITHER of you
> > have ANY authoratative statement from anyone at ARIN that 
> states this?
> >   
> 
> Directly from ARIN staff?  Not me.  However, it's a trivial thing to 
> look up my own employer's records and see stale and/or 
> orphaned POCs and 
> OrgIDs, and if we weren't paying our bills I presume our ASN 
> would have 
> been taken away by now.  I thus deduce it is possible, though 
> I'm open 
> to correction.
> 
> > Because if you do, I feel another NPRM policy proposal 
> change suggestion
> > coming on...
> >   
> 
> Are you proposing that a "billing" contact be added, in 
> addition to the 
> "admin", "tech", "abuse", and "noc" contacts?
> 
> None of the existing (or at least visible) POC types necessarily has 
> anything to do with the name/address where invoices are 
> mailed, which is 
> all that receipt of payment validates.  Besides, an org could have 
> hundreds or thousands of networks, each with different tech/abuse/noc 
> contacts, any one of which could be stale; how could paying 
> one invoice, 
> sent to some Accounts Payable person, validate all of them?
> 

whois is a relational database.

When you request numbering and receive it and an account is opened
that you start paying a bill on, ARIN assigns you an ORG id and
relates that to the network numbering you got.  When you create your
POCs you relate them to the network numbering.  When the numbering is
queried it shows those relations.

When the legacy networks were put into whois at ARINs formation they
were assigned POC handles as well.

It is a simple matter to take the list of currently billed orgs and
query whois for all of the POC handles, then take that list of POC
handles and query every non-legacy network to make sure that one
of those POC handles is related to a network.

Fundamentally, every allocated network either needs to be related to
a currently billed org or be on the inherited legacy list.

Sure, it's true a particular POC data might go stale, but for us to care
about it, that POC must be related to a network, that network is related
to an ORG id and if that org ID is no longer paying their bills and
not on the legacy list, then that network and all related POCs need to
go away from whois.

Ted



From Lee.Howard at stanleyassociates.com  Wed Oct 22 15:42:01 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Wed, 22 Oct 2008 15:42:01 -0400
Subject: [arin-ppml] [was Re: Millions of slashdotters are idle]
In-Reply-To: <44C3BECE5EAA4548AFC2F7822244C94D@tedsdesk>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A692@CL-S-EX-1.stanleyassociates.com>

> > ARIN's job is not to 
> > establish market-based incentives for anything.
> > There's nothing inherently wrong with doing so, it's just that we'd 
> > need community consensus that we should do so.  To date, 
> there has not 
> > been member consensus that ARIN should increase fees by order(s) of 
> > magnitude in order to drive organizations away from IPv4.
> > 
> 
> It is disingenuous to claim that ARIN's job is not to 
> establish market-based incentives for anything.  ARIN already 
> engages in this, the IPv6 fee waiver a market-based 
> incentive, and the "greater of IPv4 or IPv6 costs" 
> registration policy is also a market-based incentive. 

I was pretty careful with my words there.  
You could not fairly say, "ARIN's job is to establish market-based
incentives."  You could argue that ARIN should (or should not)
make use of such incentives in pursuit of ARIN's mission.  You may
say that ARIN has used that particular tool in the past, but use
of that tool is not ARIN's primary objective.


>  And as 
> I recall both of those were from the ARIN board, not from the 
> membership.

No, both were clearly requested (you could say demanded) by the
community, mostly by the members.

> In addition, the sliding fees on IPv4 are also a market-based 
> incentive, although you may deny this, the fact of the matter 
> is that on a per-IP-address basis, the larger allocations are 
> cheaper.  ARIN favors the larger ISPs and networks in this manner.

That is an adventitious artifact of the intent of the fee schedule,
which was to roughly recover costs without creating too complex a
cost-recovery mechanism.  

> Further, the requirement that orgs go to upstream providers 
> for IP numbering unless they are large is also a market 
> incentive for the org to become large before obtaining a 
> portable allocation.

That's a policy requirement, not a market requirement.  Nobody
would increase their customer base just so they could get a 
postable allocation--that's backwards.

> Also, as I understand it, fee amounts are not set in the NPRM 
> and there is thus no mechanism for the membership to have any 
> consensus on fee amounts.

Fees are set by the Board, not the members directly.  That's 
because the Board pays close attention to the organization's 
finances, and while some members pay attention to ARIN's
finances, it would be unreasonable to expect all 3000 members 
to pay as much attention.  Many of you do, and I appreciate it.


ARIN-discuss is the mailing list for members.  The Finance 
Committee of the Board of Trustees has discussed every fee 
proposal that has been sent, whether via the formal Suggestion 
Process, by email to individual FinCom or Board members, or 
discussed on an ARIN mailing list.  

The fee structure is intended to recover costs, because that's 
what the members told the Board to do a long time ago.  If 
members want to direct the Board to do something else, it might 
be interesting for a member to raise the issue on ARIN-discuss.

Lee


From heather.skanks at gmail.com  Wed Oct 22 16:42:45 2008
From: heather.skanks at gmail.com (heather skanks)
Date: Wed, 22 Oct 2008 16:42:45 -0400
Subject: [arin-ppml] fee schedule
In-Reply-To: <F5773552-BD79-4C0F-A81B-C26F54836F68@svcolo.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A56B@CL-S-EX-1.stanleyassociates.com>
	<F5773552-BD79-4C0F-A81B-C26F54836F68@svcolo.com>
Message-ID: <616812070810221342k7935812v8cd825ba4f67dc82@mail.gmail.com>

To wind up paying 9k/year you'd have to get a little more than a "simple
IPv6 block for testing/deployment"

"Large" bills at 9k/year - and a large is defined as "blocks equal to or
larger than a /29, up to and including a /27"

I believe typical allocation is either a /48 or a /32

/48 is X-small -> $1,250
/32 is small -> $2,250

This is the actual fee schedule:
http://www.arin.net/billing/fee_schedule.html#ipv6_alloc

The link you posted is the waiver schedule - in short.. they slowly ramp you
up over the next 4 years to paying the full amount for whatever level you
are at:

Year    You Pay
2008 - 10%
2009 - 25%
2010 - 50%
2011 - 75%
2012 - 100%

--Heather

On Wed, Oct 22, 2008 at 3:33 PM, Jo Rhett <jrhett at svcolo.com> wrote:

> On Oct 22, 2008, at 11:35 AM, Howard, W. Lee wrote:
> > http://www.arin.net/billing/fee_schedule.html#waivers
>
>
> Howard, I'd like to point out that this page is darn near
> indecipherable by most people.  It has confused every person in our
> company who tried to read it, and frankly I only learned what we would
> be paying by calling ARIN and having it explained to me.
>
> And it's not the math -- I'm great at math.  It's the in-out-who-is-
> what-huh? nature of the document.  This is a build-your-own-path story
> that someone forgot to include the junctions in.
>
> And I just reread it, and now I'm even more confused than I was
> originally.  From what I can see, acquiring a simple IPv6 block for
> testing/deployment in our network will make us liable for $9k a year
> within 4 years.  Why on god's green earth would I want to do that?
>
> --
> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081022/d15e9521/attachment.htm>

From tedm at ipinc.net  Wed Oct 22 16:43:12 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 22 Oct 2008 13:43:12 -0700
Subject: [arin-ppml] [was Re: Millions of slashdotters are idle]
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A692@CL-S-EX-1.stanleyassociates.com>
Message-ID: <ED44A836E65D4BD9B63231AB100B58E3@tedsdesk>



> -----Original Message-----
> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] 
> Sent: Wednesday, October 22, 2008 12:42 PM
> To: Ted Mittelstaedt; Stephen Sprunk; Ron Cleven
> Cc: ppml at arin.net
> Subject: RE: [arin-ppml] [was Re: Millions of slashdotters are idle]
> 
> 
> > > ARIN's job is not to
> > > establish market-based incentives for anything.
> > > There's nothing inherently wrong with doing so, it's just 
> that we'd 
> > > need community consensus that we should do so.  To date, 
> > there has not
> > > been member consensus that ARIN should increase fees by 
> order(s) of
> > > magnitude in order to drive organizations away from IPv4.
> > > 
> > 
> > It is disingenuous to claim that ARIN's job is not to
> > establish market-based incentives for anything.  ARIN already 
> > engages in this, the IPv6 fee waiver a market-based 
> > incentive, and the "greater of IPv4 or IPv6 costs" 
> > registration policy is also a market-based incentive. 
> 
> I was pretty careful with my words there.  
> You could not fairly say, "ARIN's job is to establish 
> market-based incentives." 

Did I say this?  No.

> You could argue that ARIN should 
> (or should not) make use of such incentives in pursuit of 
> ARIN's mission.  You may say that ARIN has used that 
> particular tool in the past, but use of that tool is not 
> ARIN's primary objective.
> 

Is your goal to define the term disingenuous? ;-) 

> 
> >  And as
> > I recall both of those were from the ARIN board, not from the 
> > membership.
> 
> No, both were clearly requested (you could say demanded) by 
> the community, mostly by the members.
> 

Welllll....

As I recall, I was one of the ones who pointed out the uncertainty
of a waiver.  But you probably are correct that the suggestion on
most cost was from the membership, I had thought the board suggested
it though and the membership liked it and ran with it.

> > In addition, the sliding fees on IPv4 are also a market-based
> > incentive, although you may deny this, the fact of the matter 
> > is that on a per-IP-address basis, the larger allocations are 
> > cheaper.  ARIN favors the larger ISPs and networks in this manner.
> 
> That is an adventitious artifact of the intent of the fee 
> schedule, which was to roughly recover costs without creating 
> too complex a cost-recovery mechanism.  
> 

And this is exactly why a flat tax isn't used for the federal
income tax in the US - the rich get the bulk of the benefit of
the federal government largess, so they should pay more.  It is
a theme that the current US population is rediscovering at this
very moment, as a matter of fact, for those who are following
the current US federal election race.

IMHO there is no question that the larger ISP's benefit more
from the existence of ARIN than the smaller ISPs.  For starters
the obvious - a small ISP that does not qualify for direct
allocation must go to a large ISP for numbering, thus they pay
what the larger ISP decides they pay, not what ARIN or the ARIN
community decides is fair.  But even for the ISP's that are not
so small and do qualify for allocation, those ISP's simply are
not grossing as much money off selling Internet access as the
larger ISPs because they have fewer customers.  Sure, you can
have inefficient large ISPs who cannot control their margins who
lose money - witness AOL for example - but it's a lot easier to make
a larger profit if your gross is higher.  That's fundamental
business 101.

Yet, the smaller ISPs pay more per IP address.  This is fundamentally
unfair and is only tolerated because the yearly cost on IPs
is in the pennies.

But, the people wanting to mine the legacy holders for saleable IPv4
are engaged in scratching up pennies.  I am amazed they are so
gung-ho to dig up loose /24's here and there yet ignore this
issue.

> > Further, the requirement that orgs go to upstream providers
> > for IP numbering unless they are large is also a market 
> > incentive for the org to become large before obtaining a 
> > portable allocation.
> 
> That's a policy requirement, not a market requirement.  
> Nobody would increase their customer base just so they could get a 
> postable allocation--that's backwards.
> 

I'll give you that one.

> > Also, as I understand it, fee amounts are not set in the NPRM
> > and there is thus no mechanism for the membership to have any 
> > consensus on fee amounts.
> 
> Fees are set by the Board, not the members directly.  That's 
> because the Board pays close attention to the organization's 
> finances, and while some members pay attention to ARIN's 
> finances, it would be unreasonable to expect all 3000 members 
> to pay as much attention.  Many of you do, and I appreciate it.
> 
> 
> ARIN-discuss is the mailing list for members.  The Finance 
> Committee of the Board of Trustees has discussed every fee 
> proposal that has been sent, whether via the formal Suggestion 
> Process, by email to individual FinCom or Board members, or 
> discussed on an ARIN mailing list.  
> 
> The fee structure is intended to recover costs, because that's 
> what the members told the Board to do a long time ago.  If 
> members want to direct the Board to do something else, it might 
> be interesting for a member to raise the issue on ARIN-discuss.
> 

Hint taken.

Ted



From jrhett at svcolo.com  Wed Oct 22 16:52:28 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 22 Oct 2008 13:52:28 -0700
Subject: [arin-ppml] fee schedule
In-Reply-To: <616812070810221342k7935812v8cd825ba4f67dc82@mail.gmail.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A56B@CL-S-EX-1.stanleyassociates.com>
	<F5773552-BD79-4C0F-A81B-C26F54836F68@svcolo.com>
	<616812070810221342k7935812v8cd825ba4f67dc82@mail.gmail.com>
Message-ID: <96A17410-455C-46CD-B5CE-C09AF3F5D41E@svcolo.com>

So take it as my vote that this document is very hard to parse.  Just  
in reading the top 3 paragraphs I am left confused about the initial  
registration fee versus the annual maintenance fee, among others.   
There's a lot of lines of thought that just dead end when you're  
trying to figure things out.  I would try to help with the document,  
but I seriously don't understand it.

On Oct 22, 2008, at 1:42 PM, heather skanks wrote:
> To wind up paying 9k/year you'd have to get a little more than a  
> "simple
> IPv6 block for testing/deployment"
>
> "Large" bills at 9k/year - and a large is defined as "blocks equal  
> to or
> larger than a /29, up to and including a /27"
>
> I believe typical allocation is either a /48 or a /32
>
> /48 is X-small -> $1,250
> /32 is small -> $2,250
>
> This is the actual fee schedule:
> http://www.arin.net/billing/fee_schedule.html#ipv6_alloc
>
> The link you posted is the waiver schedule - in short.. they slowly  
> ramp you
> up over the next 4 years to paying the full amount for whatever  
> level you
> are at:
>
> Year    You Pay
> 2008 - 10%
> 2009 - 25%
> 2010 - 50%
> 2011 - 75%
> 2012 - 100%
>
> --Heather
>
> On Wed, Oct 22, 2008 at 3:33 PM, Jo Rhett <jrhett at svcolo.com> wrote:
>
>> On Oct 22, 2008, at 11:35 AM, Howard, W. Lee wrote:
>>> http://www.arin.net/billing/fee_schedule.html#waivers
>>
>>
>> Howard, I'd like to point out that this page is darn near
>> indecipherable by most people.  It has confused every person in our
>> company who tried to read it, and frankly I only learned what we  
>> would
>> be paying by calling ARIN and having it explained to me.
>>
>> And it's not the math -- I'm great at math.  It's the in-out-who-is-
>> what-huh? nature of the document.  This is a build-your-own-path  
>> story
>> that someone forgot to include the junctions in.
>>
>> And I just reread it, and now I'm even more confused than I was
>> originally.  From what I can see, acquiring a simple IPv6 block for
>> testing/deployment in our network will make us liable for $9k a year
>> within 4 years.  Why on god's green earth would I want to do that?
>>
>> --
>> 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 Lee.Howard at stanleyassociates.com  Wed Oct 22 17:00:15 2008
From: Lee.Howard at stanleyassociates.com (Howard, W. Lee)
Date: Wed, 22 Oct 2008 17:00:15 -0400
Subject: [arin-ppml] fee schedule
In-Reply-To: <F5773552-BD79-4C0F-A81B-C26F54836F68@svcolo.com>
Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>

> Jo Rhett said:
> > http://www.arin.net/billing/fee_schedule.html#waivers
> 
> Howard, I'd like to point out that this page is darn near 
> indecipherable by most people.  

Yeah.  I'm sorry.  I've spent hours trying to simplify it, 
to make it easier to read.  I took a day off of work to 
spend time with writers at ARIN to make it make more sense.  
The fact that it's hard to read already is part of the
reason I resist additional complexity.


> And I just reread it, and now I'm even more confused than I 
> was originally.  From what I can see, acquiring a simple IPv6 
> block for testing/deployment in our network will make us 
> liable for $9k a year within 4 years.  Why on god's green 
> earth would I want to do that?

I'm going to use several cases, even though most of them don't
apply to you. . .

If you're an end-user, you pay a one-time fee for your IPv6
assignment, then $100 maintenance per year.  Most 
organizations who aren't ISPs fall in this category, and 
probably qualify for an IPv6 /32, for which the initial fee 
is $2,250.
http://www.arin.net/billing/fee_schedule.html#ipv6_assign

If you're an ISP, and already have an IPv4 allocation from
ARIN that you're paying for annually ($1250-18000 per year),
you pay no initial allocation fee for you IPv6 allocation.
You then only pay the renewal fee on your IPv4 or your IPv6
allocation, whichever fee is larger.
http://www.arin.net/billing/fee_schedule.html#ipv6_alloc
http://www.arin.net/billing/fee_schedule.html#waivers

If you're an ISP and not paying annual renewal fees to ARIN
(either because you have a legacy allocation or because you
only have space from your upstream), then you pay the
initial IPv6 allocation fee ($2250 up to an IPv6 /32, 
$4500 up to an IPv6 /30, $9000 up to an IPv6 /27).  The
annual renewal fee is the same as the initial fee, but we've
waived part of it for the next few years (waived 75% for 2009,
50% for 2010, 25% for 2011).


If you're in the latter category, I could speculate on why 
you might or might not want to get an IPv6 allocation from
ARIN, but I'm not sure my speculation would be useful.  You
might want to be able to reach IPv6 hosts, or you might
need address space when there are no more IPv4 addresses to
allocate.  If you just want some for lab testing, there are
several blocks reserved by RFC5156 (and other RFCs) you 
might use.


I know you'd already figured out your situation, but I 
hope this helps somebody.

Lee





From tedm at ipinc.net  Wed Oct 22 17:05:04 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 22 Oct 2008 14:05:04 -0700
Subject: [arin-ppml] fee schedule
In-Reply-To: <96A17410-455C-46CD-B5CE-C09AF3F5D41E@svcolo.com>
Message-ID: <FE99C98C5744460799EF29BCD12176F0@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jo Rhett
> Sent: Wednesday, October 22, 2008 1:52 PM
> To: heather skanks
> Cc: arin ppml
> Subject: Re: [arin-ppml] fee schedule
> 
> 
> So take it as my vote that this document is very hard to 
> parse.  Just  
> in reading the top 3 paragraphs I am left confused about the initial  
> registration fee versus the annual maintenance fee, among others.   
> There's a lot of lines of thought that just dead end when you're  
> trying to figure things out.  I would try to help with the document,  
> but I seriously don't understand it.
> 

It's like a UNIX man page.  If you have never encountered the
particular software program, the man page for it is indecipherable.
But once you understand the program the man page becomes obvious.


Ted



From alan at batie.org  Wed Oct 22 17:38:41 2008
From: alan at batie.org (Alan Batie)
Date: Wed, 22 Oct 2008 14:38:41 -0700
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
Message-ID: <48FF9D61.3040909@batie.org>

Howard, W. Lee wrote:

> I'm going to use several cases, even though most of them don't
> apply to you. . .
> 
> If you're an end-user, you pay a one-time fee for your IPv6
> assignment, then $100 maintenance per year.  Most 
> organizations who aren't ISPs fall in this category, and 
> probably qualify for an IPv6 /32, for which the initial fee 
> is $2,250.
> http://www.arin.net/billing/fee_schedule.html#ipv6_assign
> 
> If you're an ISP, and already have an IPv4 allocation from
> ARIN that you're paying for annually ($1250-18000 per year),
> you pay no initial allocation fee for you IPv6 allocation.
> You then only pay the renewal fee on your IPv4 or your IPv6
> allocation, whichever fee is larger.
> http://www.arin.net/billing/fee_schedule.html#ipv6_alloc
> http://www.arin.net/billing/fee_schedule.html#waivers

Having just done so under the latter case, I have a couple of questions,
ok, one question derived from two cases:

1.  One of our customers said something about trying to get an end-user
block and couldn't.

2.  I thought /32, i.e. 4 billion networks, was insanely large for us
and we're an ISP (albeit a small regional).  I'd asked for a /48 and was
told that /32 was the minimum being given out (which I can almost
understand, actually, though I think /40 would have still been plenty).

What is actually being handed out now?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3263 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081022/ad3ccf59/attachment.bin>

From ocl at gih.com  Wed Oct 22 17:47:18 2008
From: ocl at gih.com (Olivier MJ Crepin-Leblond)
Date: Wed, 22 Oct 2008 23:47:18 +0200
Subject: [arin-ppml] Suggestion: charging for IPv4 space
References: <12E2E00F6C2E40738EFA2CD08601DC61@tedsdesk>
Message-ID: <001301c9348f$c6e16e00$8a01a8c0@gih.co.uk>


----- Original Message ----- 
From: "Ted Mittelstaedt" <tedm at ipinc.net>
To: "'Olivier MJ Crepin-Leblond'" <ocl at gih.com>; <ppml at arin.net>
Sent: Wednesday, October 22, 2008 1:06 AM
Subject: RE: [arin-ppml] Suggestion: charging for IPv4 space


[...]
> EDUCATION and EMPOWERMENT is the only answer.
> 
> We need to identify the people in the orgs that are the decision
> makers, educate them on the upcoming IPv4 runout, and they
> need to complain to who they are paying for connectivity to 
> get to work on IPv6.

I agree but this is only one of the elements to make it happen,
especially since the only language that decision makers understand
is the one about money. That language is universal. From experience,
I have found that nothing else quite hits the spot, especially
forecasts involving technical linguo. (IPv4? Why 4? Why 6 now?)

> I think your being very colorful with the metaphors.  I also think
> you would be excellent at identifying the people in the orgs that
> are the decision makers, educating them on the upcoming IPv4 runout,
> and telling them to complain to who they are paying for connectivity to 
> get to work on IPv6.
> 
> This is your mission Oliver, should you decide to accept it! ;-)

...and this takes us back to the issue at hand: Fund me and I'm ready
to do it.  :-)

Olivier


From sleibrand at internap.com  Wed Oct 22 17:55:16 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 22 Oct 2008 14:55:16 -0700
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <48FF9D61.3040909@batie.org>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
	<48FF9D61.3040909@batie.org>
Message-ID: <48FFA144.5060808@internap.com>

Alan Batie wrote:
> Having just done so under the latter case, I have a couple of questions,
> ok, one question derived from two cases:
> 
> 1.  One of our customers said something about trying to get an end-user
> block and couldn't.

In IPv6, the current policy is that you have to either qualify for an IPv4 
assignment (~1000 hosts multihomed, or ~4000 singly-homed), or already 
have an efficiently used direct IPv4 assignment under RSA.  For smaller 
networks, current policy encourages them to get an assignment from one of 
their upstreams.

There have been proposals to make v6 assignment criteria independent of 
the v4 criteria, and I suspect at some point we'll pass something along 
those lines.

> 2.  I thought /32, i.e. 4 billion networks, was insanely large for us
> and we're an ISP (albeit a small regional).  I'd asked for a /48 and was
> told that /32 was the minimum being given out (which I can almost
> understand, actually, though I think /40 would have still been plenty).
> 
> What is actually being handed out now?

That's still correct.  ISP (LIR) assignments are /32 or larger, and 
end-user are /48 or larger.  The main justification for the LIR /32 
minimum is to make sure that they never have to come back for space, even 
when using a hierarchical assignment model on byte boundaries (i.e. a /40 
per region, and /48 per customer).  It's also somewhat helpful to have the 
same size on most allocations, for ease of filtering.

-Scott


From jrhett at svcolo.com  Wed Oct 22 18:02:23 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 22 Oct 2008 15:02:23 -0700
Subject: [arin-ppml] fee schedule
In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
Message-ID: <C7208BD8-0B33-40AD-AE16-5D04B4C84A3F@svcolo.com>

On Oct 22, 2008, at 2:00 PM, Howard, W. Lee wrote:
> Yeah.  I'm sorry.  I've spent hours trying to simplify it,
> to make it easier to read.  I took a day off of work to
> spend time with writers at ARIN to make it make more sense.
> The fact that it's hard to read already is part of the
> reason I resist additional complexity.

> I'm going to use several cases, even though most of them don't
> apply to you. . .
>
> If you're an end-user, you pay a one-time fee for your IPv6
> assignment, then $100 maintenance per year.  Most
> ...
> annual renewal fee is the same as the initial fee, but we've
> waived part of it for the next few years (waived 75% for 2009,
> 50% for 2010, 25% for 2011).

I actually do understand the pricing, but only because it has been  
explained to me.  When you mentioned pricing had changed I went to go  
read this page and got lost and confused inside it.

> If you're in the latter category, I could speculate on why
> you might or might not want to get an IPv6 allocation from

Oh, I'm going to end up with a /32 either way.  I'm just pointing out  
that rereading that page confused and scared me that I was committing  
the company to an expensive proposition that not everyone in the  
company supports.  It seems to be not different than before, so  
*shrug* but wow it was hard to get that clear.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Wed Oct 22 18:12:49 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 22 Oct 2008 15:12:49 -0700
Subject: [arin-ppml] fee schedule
In-Reply-To: <FE99C98C5744460799EF29BCD12176F0@tedsdesk>
References: <FE99C98C5744460799EF29BCD12176F0@tedsdesk>
Message-ID: <41F2A831-2BD8-466F-B023-030C3D55FABE@svcolo.com>

On Oct 22, 2008, at 2:05 PM, Ted Mittelstaedt wrote:
> It's like a UNIX man page.  If you have never encountered the
> particular software program, the man page for it is indecipherable.
> But once you understand the program the man page becomes obvious.


No, that's not it at all.  The page has numerous "follow-me" paths  
that dead end.

Example: starting with the heading "Initial Assignment Registration Fee"

> ARIN charges an initial registration fee to organizations that  
> receive an assignment of IPv6 address space directly from ARIN. ARIN  
> will only complete the assignment of the address space upon its  
> receipt of this payment and a signed Registration Services Agreement  
> (RSA).
> The initial registration fee is based on the amount of address space  
> assigned as outlined below.

Okay, nice table showing the assignment fee.

> Annual Maintenance Fee


Ah, okay, so how much is the annual maintenance fee?

> Organizations must pay a consolidated annual maintenance fee to  
> cover all AS numbers, IPv4 or IPv6 assignments, or network transfers  
> associated with an Org ID. However if the Org ID is also associated  
> with a direct allocation of IP address space from ARIN, this fee is  
> not charged.
>
> For details about this fee, please see the Annual Maintenance Fee  
> section of this Fee Schedule.

Okay, so I click the "Annual Maintenance Fee" link and jump to there:

> Annual Maintenance Fee
>
> An organization will receive an invoice for its ARIN annual  
> maintenance fee two months before the fee is due. The due date for  
> fees is the last day of the month in which an organization's  
> anniversary date occurs.  An anniversary date is the day on which an  
> organization received its first resource from ARIN. Payment must be  
> made by the due date, in accordance with the Registration Services  
> Agreement. If fees are not paid, the number resources related to the  
> invoice will be subject to revocation.
>
> When a single Org ID has more than one resource registered with ARIN  
> (e.g. AS numbers, IPv4 or IPv6 assignments, or network transfers),  
> ARIN charges only a single maintenance fee of $100 annually.

The next section is online payments.  So my question is not answered.   
So I scan the entire document and .. guess what, there's not a single  
table in the document labeled "annual maintenance fees".  What is my  
annual maintenance fee?  How do I figure this out?

NOTE: I do personally know the answer for my company.  But this  
doesn't change the fact that I couldn't use this page to document  
that, because you can't get from here to there without information not  
available in the page.

The entire document is riddled with "follow-me -> dead end" paths like  
this.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550


From jrhett at svcolo.com  Wed Oct 22 18:15:32 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 22 Oct 2008 15:15:32 -0700
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <48FFA144.5060808@internap.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
	<48FF9D61.3040909@batie.org> <48FFA144.5060808@internap.com>
Message-ID: <4AB6631E-D761-476A-B4B7-F7C31F3CEF4D@svcolo.com>

On Oct 22, 2008, at 2:55 PM, Scott Leibrand wrote:
> The main justification for the ... minimum is to make sure that they
> never have to come back for space

<humor>
I heard that exact sentence uttered almost 20 years ago, and let me  
tell you... that worked out just fine!
</humor>

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From sleibrand at internap.com  Wed Oct 22 18:20:26 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Wed, 22 Oct 2008 15:20:26 -0700
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <4AB6631E-D761-476A-B4B7-F7C31F3CEF4D@svcolo.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
	<48FF9D61.3040909@batie.org> <48FFA144.5060808@internap.com>
	<4AB6631E-D761-476A-B4B7-F7C31F3CEF4D@svcolo.com>
Message-ID: <48FFA72A.4020703@internap.com>

Jo Rhett wrote:
> On Oct 22, 2008, at 2:55 PM, Scott Leibrand wrote:
>> The main justification for the ... minimum is to make sure that they
>> never have to come back for space
> 
> <humor>
> I heard that exact sentence uttered almost 20 years ago, and let me tell 
> you... that worked out just fine!
> </humor>

Do you think we got it right this time, with 340 trillion, trillion, 
trillion addresses (or 35 trillion /48's)?  :)

-Scott


From randy at psg.com  Wed Oct 22 18:26:05 2008
From: randy at psg.com (Randy Bush)
Date: Wed, 22 Oct 2008 15:26:05 -0700
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <48FFA72A.4020703@internap.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>	<48FF9D61.3040909@batie.org>
	<48FFA144.5060808@internap.com>	<4AB6631E-D761-476A-B4B7-F7C31F3CEF4D@svcolo.com>
	<48FFA72A.4020703@internap.com>
Message-ID: <48FFA87D.30208@psg.com>

>>> The main justification for the ... minimum is to make sure that they
>>> never have to come back for space
>> I heard that exact sentence uttered almost 20 years ago, and let me tell 
>> you... that worked out just fine!
> Do you think we got it right this time, with 340 trillion, trillion, 
> trillion addresses (or 35 trillion /48's)?  :)

as danny cohen said last wednesday
  first it was 8 bits
  then times four to 32 bits
  then times four to 128 bits
  and he assumes times four to 512 bits

rinse repeat

randy



From alan at batie.org  Wed Oct 22 19:14:02 2008
From: alan at batie.org (Alan Batie)
Date: Wed, 22 Oct 2008 16:14:02 -0700
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <48FFA144.5060808@internap.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
	<48FF9D61.3040909@batie.org> <48FFA144.5060808@internap.com>
Message-ID: <48FFB3BA.4050908@batie.org>

Scott Leibrand wrote:

> In IPv6, the current policy is that you have to either qualify for an
> IPv4 assignment (~1000 hosts multihomed, or ~4000 singly-homed),

That makes sense from a route table perspective.

> make sure that they never have to come back for space,
> even when using a hierarchical assignment model on byte boundaries (i.e.
> a /40 per region, and /48 per customer).

;-)  I'm planning on nibble boundaries, but that makes sense too, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3263 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081022/9328aef5/attachment.bin>

From stephen at sprunk.org  Wed Oct 22 19:19:36 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 22 Oct 2008 18:19:36 -0500
Subject: [arin-ppml] fee schedule
In-Reply-To: <41F2A831-2BD8-466F-B023-030C3D55FABE@svcolo.com>
References: <FE99C98C5744460799EF29BCD12176F0@tedsdesk>
	<41F2A831-2BD8-466F-B023-030C3D55FABE@svcolo.com>
Message-ID: <48FFB508.7070604@sprunk.org>

Jo Rhett wrote:
> On Oct 22, 2008, at 2:05 PM, Ted Mittelstaedt wrote:
>   
>> It's like a UNIX man page.  If you have never encountered the
>> particular software program, the man page for it is indecipherable.
>> But once you understand the program the man page becomes obvious.
>>     
>
>
> No, that's not it at all.  The page has numerous "follow-me" paths  
> that dead end.
>   

Hmm.  I don't see the dead ends...

> Example: starting with the heading "Initial [IPv4] Assignment Registration Fee"
>   

This is at: 
http://www.arin.net/billing/fee_schedule.html#ipv4_assign_initial

>> ARIN charges an initial registration fee to organizations that  
>> receive an assignment of IPv6 address space directly from ARIN. ARIN  
>> will only complete the assignment of the address space upon its  
>> receipt of this payment and a signed Registration Services Agreement  
>> (RSA).
>> The initial registration fee is based on the amount of address space  
>> assigned as outlined below.
>>     
>
> Okay, nice table showing the assignment fee.
>   

Good so far.

>> Annual Maintenance Fee
>>     
> Ah, okay, so how much is the annual maintenance fee?
>   

Next Heading: Annual Maintenance Fee

>> Organizations must pay a consolidated annual maintenance fee to  
>> cover all AS numbers, IPv4 or IPv6 assignments, or network transfers  
>> associated with an Org ID. However if the Org ID is also associated  
>> with a direct allocation of IP address space from ARIN, this fee is  
>> not charged.
>>
>> For details about this fee, please see the Annual Maintenance Fee  
>> section of this Fee Schedule.
>>     
> Okay, so I click the "Annual Maintenance Fee" link and jump to there:
>   

Link to: http://www.arin.net/billing/fee_schedule.html#annual_maint

>> Annual Maintenance Fee
>>     

Hmm...  That's two sections with the same heading; very confusing.

>> An organization will receive an invoice for its ARIN annual  
>> maintenance fee two months before the fee is due. The due date for  
>> fees is the last day of the month in which an organization's  
>> anniversary date occurs.  An anniversary date is the day on which an  
>> organization received its first resource from ARIN. Payment must be  
>> made by the due date, in accordance with the Registration Services  
>> Agreement. If fees are not paid, the number resources related to the  
>> invoice will be subject to revocation.
>>
>> When a single Org ID has more than one resource registered with ARIN  
>> (e.g. AS numbers, IPv4 or IPv6 assignments, or network transfers),  
>> ARIN charges only a single maintenance fee of $100 annually.
>>     
>
> The next section is online payments.  So my question is not answered.   
> So I scan the entire document and .. guess what, there's not a single  
> table in the document labeled "annual maintenance fees".  What is my  
> annual maintenance fee?  How do I figure this out?
>   

See above (in your own quote) where it says "ARIN charges only a single 
maintenance fee of $100 annually."  That is the maintenance fee for 
end-user orgs, regardless of how many resources you have or how big they 
are.

I do think the wording could be a bit clearer, and the differences 
between end-user and LIR fees are definitely not clear enough for those 
who aren't aware of the distinction between "assignment" and 
"allocation".  Even here on PPML, folks use the wrong term on a daily basis.

Suggestion to Lee: Break up the document into an LIR section, an 
End-User section and a Legacy End-User section.  Each section would 
describe the fees for new resources of each type (except legacy, 
obviously) and annual maintenance.  That would eliminate a lot of 
jumping around.

> NOTE: I do personally know the answer for my company.  But this  
> doesn't change the fact that I couldn't use this page to document  
> that, because you can't get from here to there without information not  
> available in the page.
>   

All the information is there.  However, it's sort of like a man page: 
you can't find it unless you already know the answer (and sometimes, not 
even then...).

> The entire document is riddled with "follow-me -> dead end" paths like  
> this.
>   

I haven't found any examples of that yet, but I agree that it's tough to 
read in its current arrangement.

S


From BillD at cait.wustl.edu  Wed Oct 22 19:38:37 2008
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 22 Oct 2008 18:38:37 -0500
Subject: [arin-ppml] fee schedule and allocation
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com><48FF9D61.3040909@batie.org>
	<48FFA144.5060808@internap.com><4AB6631E-D761-476A-B4B7-F7C31F3CEF4D@svcolo.com>
	<48FFA72A.4020703@internap.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087531C9C@ex1.cait.wustl.edu>

It clearly is not how many you start with, but how wastefully you distribute them.
bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Scott Leibrand
Sent: Wed 10/22/2008 5:20 PM
To: Jo Rhett
Cc: arin ppml
Subject: Re: [arin-ppml] fee schedule and allocation
 
Jo Rhett wrote:
> On Oct 22, 2008, at 2:55 PM, Scott Leibrand wrote:
>> The main justification for the ... minimum is to make sure that they
>> never have to come back for space
> 
> <humor>
> I heard that exact sentence uttered almost 20 years ago, and let me tell 
> you... that worked out just fine!
> </humor>

Do you think we got it right this time, with 340 trillion, trillion, 
trillion addresses (or 35 trillion /48's)?  :)

-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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081022/b57825b1/attachment.htm>

From jrhett at svcolo.com  Wed Oct 22 20:20:46 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 22 Oct 2008 17:20:46 -0700
Subject: [arin-ppml] fee schedule
In-Reply-To: <48FFB508.7070604@sprunk.org>
References: <FE99C98C5744460799EF29BCD12176F0@tedsdesk>
	<41F2A831-2BD8-466F-B023-030C3D55FABE@svcolo.com>
	<48FFB508.7070604@sprunk.org>
Message-ID: <FA9B53D0-0703-4E7E-872B-ED1B789C8ED5@svcolo.com>

On Oct 22, 2008, at 4:19 PM, Stephen Sprunk wrote:
>>> An organization will receive an invoice for its ARIN annual   
>>> maintenance fee two months before the fee is due. The due date  
>>> for  fees is the last day of the month in which an organization's   
>>> anniversary date occurs.  An anniversary date is the day on which  
>>> an  organization received its first resource from ARIN. Payment  
>>> must be  made by the due date, in accordance with the Registration  
>>> Services  Agreement. If fees are not paid, the number resources  
>>> related to the  invoice will be subject to revocation.
>>>
>>> When a single Org ID has more than one resource registered with  
>>> ARIN  (e.g. AS numbers, IPv4 or IPv6 assignments, or network  
>>> transfers),  ARIN charges only a single maintenance fee of $100  
>>> annually.
>>>
>>
>> The next section is online payments.  So my question is not  
>> answered.   So I scan the entire document and .. guess what,  
>> there's not a single  table in the document labeled "annual  
>> maintenance fees".  What is my  annual maintenance fee?  How do I  
>> figure this out?
>>
>
> See above (in your own quote) where it says "ARIN charges only a  
> single maintenance fee of $100 annually."  That is the maintenance  
> fee for end-user orgs, regardless of how many resources you have or  
> how big they are.

Ah, but this paragraph is not in the end-user section of the  
document.  It's in a completely different section.  So when I'm  
reading it, I'm thinking "okay, why are we paying >$4k a year then?"

> I do think the wording could be a bit clearer, and the differences  
> between end-user and LIR fees are definitely not clear enough for  
> those who aren't aware of the distinction between "assignment" and  
> "allocation".  Even here on PPML, folks use the wrong term on a  
> daily basis.
>
> Suggestion to Lee: Break up the document into an LIR section, an End- 
> User section and a Legacy End-User section.  Each section would  
> describe the fees for new resources of each type (except legacy,  
> obviously) and annual maintenance.  That would eliminate a lot of  
> jumping around.

I agree.

> I haven't found any examples of that yet, but I agree that it's  
> tough to read in its current arrangement.


Is that a challenge to find more?  I'm tempted, but frankly need to  
focus on other things right now :-(

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From michael.dillon at bt.com  Thu Oct 23 05:37:31 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 23 Oct 2008 10:37:31 +0100
Subject: [arin-ppml] "Millions of Internet Addresses
	AreLying	Idle"(slashdot)
In-Reply-To: <1A34D6582AB94873AEF3304FFF1A3AAB@tedsdesk>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08DA6AEF@E03MVZ2-UKDY.domain1.systemhost.net>

> Both you and Jo are asserting here that ARIN billing 
> addressing info is separate from the POC info associated with 
> that org.  Do EITHER of you have ANY authoratative statement 
> from anyone at ARIN that states this?

A. It is on the ARIN web pages
B. It is a business operations issue, not a policy issue
C. In many companies, the people who manage addresses do
   do not have anything to do with paying the bills. It 
   makes sense to send the bill to someone who is more 
   likely to get it paid promptly.

--Michael Dillon


From farmer at umn.edu  Thu Oct 23 09:30:48 2008
From: farmer at umn.edu (David Farmer)
Date: Thu, 23 Oct 2008 08:30:48 -0500
Subject: [arin-ppml] 2008-4: Minimum Allocation in the Caribbean Region
	- Last Call
In-Reply-To: <48FF816D.7060207@arin.net>
References: <48FF816D.7060207@arin.net>
Message-ID: <49003638.339.379491A@farmer.umn.edu>

On 22 Oct 2008 Member Services wrote:

> Policy Proposal 2008-4
> Minimum Allocation in the Caribbean Region
> 
> On 17 October 2008 the ARIN Advisory Council (AC), acting under the
> provisions of the ARIN Internet Resource Policy Evaluation Process,
> determined that the community supports this proposal and moves it to
> last call as amended. The AC removed the second bullet from the 4.8.1
> text because it was redundant, and modified the region to refer to it as
> the Caribbean and North Atlantic Islands.

Does this minor change have any affect on Staff's Assessment of the 
policy?

Specifically, what is their understanding as it relates to ST. HELENA and 
ST. PIERRE AND MIQUELON, as these are the only other islands with 
permanent inhabitants in the ARIN region that were not already included in 
their original Assessment? 

I support this minor change and the Policy overall.
 
> Feedback is encouraged during this last call period. All comments should
> be provided to the Public Policy Mailing List. This last call will
> expire at 23:59 EDT, 7 November 2008.



=======================================================
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 bicknell at ufp.org  Thu Oct 23 11:11:01 2008
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 23 Oct 2008 11:11:01 -0400
Subject: [arin-ppml] 2008-4: Minimum Allocation in the Caribbean Region
	- Last Call
In-Reply-To: <48FF816D.7060207@arin.net>
References: <48FF816D.7060207@arin.net>
Message-ID: <20081023151101.GA35416@ussenterprise.ufp.org>

In a message written on Wed, Oct 22, 2008 at 03:39:25PM -0400, Member Services wrote:
> On 17 October 2008 the ARIN Advisory Council (AC), acting under the
> provisions of the ARIN Internet Resource Policy Evaluation Process,
> determined that the community supports this proposal and moves it to
> last call as amended. The AC removed the second bullet from the 4.8.1
> text because it was redundant, and modified the region to refer to it as
> the Caribbean and North Atlantic Islands.

At the AC meeting the AC was informed that ARIN staff was going to
update the ARIN web site (specifically
http://www.arin.net/community/ARINcountries.html) to include a group
of countries under the banner "Caribbean and North Atlantic Islands".
The AC chose to use the exact same description as that way the
policy manual and web site would match and there would be a list
of countries, which should eliminate confusion.

Hopefully the web site will be updated soon so everyone can evaluate
this proposal properly in last-call.

-- 
       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/20081023/7dcc7783/attachment.sig>

From dlw+arin at tellme.com  Thu Oct 23 15:15:13 2008
From: dlw+arin at tellme.com (David Williamson)
Date: Thu, 23 Oct 2008 12:15:13 -0700
Subject: [arin-ppml] 2008-4: Minimum Allocation in the Caribbean Region
	- Last Call
In-Reply-To: <20081023151101.GA35416@ussenterprise.ufp.org>
References: <48FF816D.7060207@arin.net>
	<20081023151101.GA35416@ussenterprise.ufp.org>
Message-ID: <20081023191513.GZ11494@shell02.cell.sv2.tellme.com>

On Thu, Oct 23, 2008 at 11:11:01AM -0400, Leo Bicknell wrote:
> At the AC meeting the AC was informed that ARIN staff was going to
> update the ARIN web site (specifically
> http://www.arin.net/community/ARINcountries.html) to include a group
> of countries under the banner "Caribbean and North Atlantic Islands".
> The AC chose to use the exact same description as that way the
> policy manual and web site would match and there would be a list
> of countries, which should eliminate confusion.
> 
> Hopefully the web site will be updated soon so everyone can evaluate
> this proposal properly in last-call.

It is updated.  (Thanks, staff folks!)  This is, of course, how this
should work - minor wordsmithing for clarity by the AC has resulted in
a proposal that fully reflects the original intent and is unambiguous.

As I stated in LA, this has my full support.

-David


From ipgoddess.arin at gmail.com  Thu Oct 23 19:45:28 2008
From: ipgoddess.arin at gmail.com (Stacy Hughes)
Date: Thu, 23 Oct 2008 16:45:28 -0700
Subject: [arin-ppml] 2008-5: Dedicated IPv4 block to facilitate IPv6
	deployment - Last Call
In-Reply-To: <48FF8031.4010807@arin.net>
References: <48FF8031.4010807@arin.net>
Message-ID: <24c86a5f0810231645o780531ccg1c601042c791fed5@mail.gmail.com>

Hello All,I continue to disagree with this proposal with regard to the size
of block needed.  I acknowledge the desire for filtering for this purpose,
and I think that's great, but /10 is too big.  With my LIR/ISP hat on, who
among us does not have a /24, or /28 to spare for this purpose?  The way I
see it, this proposal is germane to organizations that don't already have v4
space.   I think this proposal is accounting for all possible organizations,
the overwhelming majority of which will already have some spare v4 for this
purpose.

Further, in AC deliberations, it was pointed out that there is no mechanism
to acquire any space for this purpose, if the Board ratifies it or not.  The
experimental policy does not provide justification for v4/v6 transition.
http://www.arin.net/policy/nrpm.html#eleven

I acknowledge we're running out of time, and by the same token the need for
anything we can do to encourage v6 adoption.

We may have gotten the cart before the horse on this one.  First, we must
have the mechanism to acquire the space for v4/v6 transition, then we must
assess the constituent base for this policy, then reserve the block.

Thank you,
Stacy


On Wed, Oct 22, 2008 at 12:34 PM, Member Services <info at arin.net> wrote:

> Policy Proposal 2008-5
> Dedicated IPv4 block to facilitate IPv6 deployment
>
> On 17 October 2008 the ARIN Advisory Council (AC), acting under the
> provisions of the ARIN Internet Resource Policy Evaluation Process,
> determined that the community supports this proposal and moves it to
> last call.
>
> Feedback is encouraged during this last call period. All comments should
> be provided to the Public Policy Mailing List. This last call will
> expire at 23:59 EDT, 7 November 2008.
>
> The policy proposal text is provided below and is also available at:
> http://www.arin.net/policy/proposals/2008_5.html
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal 2008-5
> Dedicated IPv4 block to facilitate IPv6 deployment
>
> Author: Alain Durand
>
> Date: 6 June 2008
>
> Proposal type: New
>
> Policy term: Permanent
>
> Policy statement:
>
> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
> deployment. Allocations and assignments from this block must be
> justified by immediate IPv6 deployment requirements. Examples of such
> needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
> or NAT464 translators. ARIN staff will use their discretion when
> evaluating justifications.
>
> This block will be subject to a minimum size allocation of /28 and a
> maximum size allocation of /24. ARIN should use sparse allocation when
> possible within that /10 block.
>
> In order to receive an allocation or assignment under this policy:
>
>   1. the applicant may not have received resources under this policy in
>      the preceding six months;
>   2. previous allocations/assignments under this policy must continue
>      to meet the justification requirements of this policy;
>   3. previous allocations/assignments under this policy must meet the
>      utilization requirements of end user assignments;
>   4. the applicant must demonstrate that no other allocations or
>      assignments will meet this need;
>   5. on subsequent allocation under this policy, ARIN staff may require
>      applicants to renumber out of previously allocated / assigned
>      space under this policy in order to minimize non-contiguous
>      allocations;
>   6. recipient organizations must be members in good standing of ARIN.
>
> Rationale for reserving IPv4 space:
>
> This policy provides predictability on how the end game of IPv4 is going
> to be played after IANA completion. It will facilitate IPv6 deployment
> by ensuring that some small chunks of IPv4 space will remain available
> for a long time to ease the co-existence of IPv4 & IPv6.
>
> Rationale for reserving a contiguous /10
>
> This is a balance between setting aside too much space and not having
> enough to facilitate IPv6 deployment for many years. Out of the last /8,
> that would leave the equivalent of 3 /10 to ARIN either for business as
> usual or for other policies in the spirit of this one.
>
> A /10 represents 4,194,304 IP addresses, If all of them were to be used
> in NAT-PT or NAT464 type devices with a consolidation factor of 100
> users behind each IP address, that would represent about 400 million users.
>
> Most networks today filter IPv4 announcements more specific than /24.
> This policy creates allocations & assignment prefixes as long as /28.
> Allocating out of a contiguous block will mitigate the impact of this
> policy on filter lists.
>
> Rationale for minimum size allocation of /28
>
> This minimum size allocation will put a cap at 250k additional entries
> in the global IPv4 routing table.
>
> Rationale for maximum size allocation of /24 and for the 6 month delay
> between allocations
>
> This maximum allocation size coupled with the requirement of a 6 months
> delay between allocations will prevent hoarding and make sure this pool
> will last several years.
>
> Rationale for forced renumbering for further allocation
>
> The minimum allocation size of /28 may create a huge increase in the
> IPv4 routing table size. Forcing renumbering for subsequent allocations
> under this policy will somehow limit the growth of the routing table
> size by enabling the announcement of aggregated space. It is expected
> that the savings in routing table entries will outweigh the pain of
> forced renumbering.
>
> However, renumbering is never an easy task, so it should only be
> considered as last resort. it is expected that sparse allocation
> techniques will prevent the need of force renumbering for a fairly long
> time.
>
> Note: This policy proposal hints that the /10 should come out of the
> last /8 received by ARIN from IANA. However, it does not say so
> explicitly, leaving the final decision up to the ARIN staff.
>
> Timetable for implementation:
>
> As soon as ARIN gets its last /8 allocation from IANA.
>
>
>
>
>
> _______________________________________________
> 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/20081023/48d97056/attachment.htm>

From sleibrand at internap.com  Thu Oct 23 20:05:02 2008
From: sleibrand at internap.com (Scott Leibrand)
Date: Thu, 23 Oct 2008 17:05:02 -0700
Subject: [arin-ppml] 2008-5: Dedicated IPv4 block to facilitate
 IPv6	deployment - Last Call
In-Reply-To: <24c86a5f0810231645o780531ccg1c601042c791fed5@mail.gmail.com>
References: <48FF8031.4010807@arin.net>
	<24c86a5f0810231645o780531ccg1c601042c791fed5@mail.gmail.com>
Message-ID: <4901112E.8080804@internap.com>

The way I read it, this policy proposal does both: upon receipt of the 
last /8 from IANA, it reserves an IPv4 /10 for use in "IPv6 deployment" 
scenarios, and directs ARIN to begin allocating /24-/28 blocks out of the /10.

Given that the policy doesn't go into effect until IANA free pool 
exhaustion, it's worth noting that when it does go into effect, IPv4 
resources will be considered "scarce", and shortly afterward ARIN's free 
pool will likely be exhausted as well.   So it won't be too long after the 
policy takes effect that clause #4 ("the applicant must demonstrate that 
no other allocations or assignments will meet this need") will begun to be 
met, and demand will start to pick up for allocations from this block.

I agree that additional policy work is warranted here, but I don't think 
that's any reason to hold up ratification of 2008-5.  (Examples of such 
follow-up policies might be things like: a policy to allow 
micro-allocations for IPv6 transition purposes immediately, or a policy to 
adjust the reserved block size from /10 to something smaller or larger.)

-Scott

Stacy Hughes wrote:
> Hello All,
> I continue to disagree with this proposal with regard to the size of 
> block needed.  I acknowledge the desire for filtering for this purpose, 
> and I think that's great, but /10 is too big.  With my LIR/ISP hat on, 
> who among us does not have a /24, or /28 to spare for this purpose?  The 
> way I see it, this proposal is germane to organizations that don't 
> already have v4 space.   I think this proposal is accounting for all 
> possible organizations, the overwhelming majority of which will already 
> have some spare v4 for this purpose.
> 
> Further, in AC deliberations, it was pointed out that there is no 
> mechanism to acquire any space for this purpose, if the Board ratifies 
> it or not.  The experimental policy does not provide justification for 
> v4/v6 transition.  
> http://www.arin.net/policy/nrpm.html#eleven
> 
> I acknowledge we're running out of time, and by the same token the need 
> for anything we can do to encourage v6 adoption.
> 
> We may have gotten the cart before the horse on this one.  First, we 
> must have the mechanism to acquire the space for v4/v6 transition, then 
> we must assess the constituent base for this policy, then reserve the block.
> 
> Thank you,
> Stacy
> 
> 
> On Wed, Oct 22, 2008 at 12:34 PM, Member Services <info at arin.net 
> <mailto:info at arin.net>> wrote:
> 
>     Policy Proposal 2008-5
>     Dedicated IPv4 block to facilitate IPv6 deployment
> 
>     On 17 October 2008 the ARIN Advisory Council (AC), acting under the
>     provisions of the ARIN Internet Resource Policy Evaluation Process,
>     determined that the community supports this proposal and moves it to
>     last call.
> 
>     Feedback is encouraged during this last call period. All comments should
>     be provided to the Public Policy Mailing List. This last call will
>     expire at 23:59 EDT, 7 November 2008.
> 
>     The policy proposal text is provided below and is also available at:
>     http://www.arin.net/policy/proposals/2008_5.html
> 
>     The ARIN Internet Resource Policy Evaluation Process can be found at:
>     http://www.arin.net/policy/irpep.html
> 
>     Regards,
> 
>     Member Services
>     American Registry for Internet Numbers (ARIN)
> 
> 
>     ## * ##
> 
> 
>     Policy Proposal 2008-5
>     Dedicated IPv4 block to facilitate IPv6 deployment
> 
>     Author: Alain Durand
> 
>     Date: 6 June 2008
> 
>     Proposal type: New
> 
>     Policy term: Permanent
> 
>     Policy statement:
> 
>     When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
>     /10 IPv4 block will be set aside and dedicated to facilitate IPv6
>     deployment. Allocations and assignments from this block must be
>     justified by immediate IPv6 deployment requirements. Examples of such
>     needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT
>     or NAT464 translators. ARIN staff will use their discretion when
>     evaluating justifications.
> 
>     This block will be subject to a minimum size allocation of /28 and a
>     maximum size allocation of /24. ARIN should use sparse allocation when
>     possible within that /10 block.
> 
>     In order to receive an allocation or assignment under this policy:
> 
>       1. the applicant may not have received resources under this policy in
>          the preceding six months;
>       2. previous allocations/assignments under this policy must continue
>          to meet the justification requirements of this policy;
>       3. previous allocations/assignments under this policy must meet the
>          utilization requirements of end user assignments;
>       4. the applicant must demonstrate that no other allocations or
>          assignments will meet this need;
>       5. on subsequent allocation under this policy, ARIN staff may require
>          applicants to renumber out of previously allocated / assigned
>          space under this policy in order to minimize non-contiguous
>          allocations;
>       6. recipient organizations must be members in good standing of ARIN.
> 
>     Rationale for reserving IPv4 space:
> 
>     This policy provides predictability on how the end game of IPv4 is going
>     to be played after IANA completion. It will facilitate IPv6 deployment
>     by ensuring that some small chunks of IPv4 space will remain available
>     for a long time to ease the co-existence of IPv4 & IPv6.
> 
>     Rationale for reserving a contiguous /10
> 
>     This is a balance between setting aside too much space and not having
>     enough to facilitate IPv6 deployment for many years. Out of the last /8,
>     that would leave the equivalent of 3 /10 to ARIN either for business as
>     usual or for other policies in the spirit of this one.
> 
>     A /10 represents 4,194,304 IP addresses, If all of them were to be used
>     in NAT-PT or NAT464 type devices with a consolidation factor of 100
>     users behind each IP address, that would represent about 400 million
>     users.
> 
>     Most networks today filter IPv4 announcements more specific than /24.
>     This policy creates allocations & assignment prefixes as long as /28.
>     Allocating out of a contiguous block will mitigate the impact of this
>     policy on filter lists.
> 
>     Rationale for minimum size allocation of /28
> 
>     This minimum size allocation will put a cap at 250k additional entries
>     in the global IPv4 routing table.
> 
>     Rationale for maximum size allocation of /24 and for the 6 month delay
>     between allocations
> 
>     This maximum allocation size coupled with the requirement of a 6 months
>     delay between allocations will prevent hoarding and make sure this pool
>     will last several years.
> 
>     Rationale for forced renumbering for further allocation
> 
>     The minimum allocation size of /28 may create a huge increase in the
>     IPv4 routing table size. Forcing renumbering for subsequent allocations
>     under this policy will somehow limit the growth of the routing table
>     size by enabling the announcement of aggregated space. It is expected
>     that the savings in routing table entries will outweigh the pain of
>     forced renumbering.
> 
>     However, renumbering is never an easy task, so it should only be
>     considered as last resort. it is expected that sparse allocation
>     techniques will prevent the need of force renumbering for a fairly long
>     time.
> 
>     Note: This policy proposal hints that the /10 should come out of the
>     last /8 received by ARIN from IANA. However, it does not say so
>     explicitly, leaving the final decision up to the ARIN staff.
> 
>     Timetable for implementation:
> 
>     As soon as ARIN gets its last /8 allocation from IANA.
> 
> 
> 
> 
> 
>     _______________________________________________
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto: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 <mailto: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 Oct 23 20:07:24 2008
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Oct 2008 17:07:24 -0700
Subject: [arin-ppml] 2008-5: Dedicated IPv4 block to facilitate IPv6
	deployment - Last Call
In-Reply-To: <24c86a5f0810231645o780531ccg1c601042c791fed5@mail.gmail.com>
References: <48FF8031.4010807@arin.net>
	<24c86a5f0810231645o780531ccg1c601042c791fed5@mail.gmail.com>
Message-ID: <BD9E5114-D085-4878-90BD-2E9EE4FCBE03@delong.com>

If we reserve it, then, we can create policy at any point for how
best to use it.  If we fail to reserve it, then, that ship has sailed.

This is a good policy.  A /10 is not too much space when you
consider that it might be decades worth of new IPv6 only entrants
into the marketplace that need support from this space. Indeed,
I think a /8 is the more appropriate size.

Stacy, you're assuming that this space is needed for existing
organizations that will be deploying transitional technologies.
I'm assuming that this space is for new organizations that arrive
after IPv4 free pool exhaustion and need transitional technologies
just to talk to the portion of the internet that hasn't yet gained
any form of IPv6 capability.

Looking at the potential number of those organizations makes
me think there's a much larger demand than looking at it from
your stated perspective.

Owen

On Oct 23, 2008, at 4:45 PM, Stacy Hughes wrote:

> Hello All,
> I continue to disagree with this proposal with regard to the size of  
> block needed.  I acknowledge the desire for filtering for this  
> purpose, and I think that's great, but /10 is too big.  With my LIR/ 
> ISP hat on, who among us does not have a /24, or /28 to spare for  
> this purpose?  The way I see it, this proposal is germane to  
> organizations that don't already have v4 space.   I think this  
> proposal is accounting for all possible organizations, the  
> overwhelming majority of which will already have some spare v4 for  
> this purpose.
>
> Further, in AC deliberations, it was pointed out that there is no  
> mechanism to acquire any space for this purpose, if the Board  
> ratifies it or not.  The experimental policy does not provide  
> justification for v4/v6 transition.
> http://www.arin.net/policy/nrpm.html#eleven
>
> I acknowledge we're running out of time, and by the same token the  
> need for anything we can do to encourage v6 adoption.
>
> We may have gotten the cart before the horse on this one.  First, we  
> must have the mechanism to acquire the space for v4/v6 transition,  
> then we must assess the constituent base for this policy, then  
> reserve the block.
>
> Thank you,
> Stacy
>
>
> On Wed, Oct 22, 2008 at 12:34 PM, Member Services <info at arin.net>  
> wrote:
> Policy Proposal 2008-5
> Dedicated IPv4 block to facilitate IPv6 deployment
>
> On 17 October 2008 the ARIN Advisory Council (AC), acting under the
> provisions of the ARIN Internet Resource Policy Evaluation Process,
> determined that the community supports this proposal and moves it to
> last call.
>
> Feedback is encouraged during this last call period. All comments  
> should
> be provided to the Public Policy Mailing List. This last call will
> expire at 23:59 EDT, 7 November 2008.
>
> The policy proposal text is provided below and is also available at:
> http://www.arin.net/policy/proposals/2008_5.html
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal 2008-5
> Dedicated IPv4 block to facilitate IPv6 deployment
>
> Author: Alain Durand
>
> Date: 6 June 2008
>
> Proposal type: New
>
> Policy term: Permanent
>
> Policy statement:
>
> When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
> /10 IPv4 block will be set aside and dedicated to facilitate IPv6
> deployment. Allocations and assignments from this block must be
> justified by immediate IPv6 deployment requirements. Examples of such
> needs include: IPv4 addresses for key dual stack DNS servers, and  
> NAT-PT
> or NAT464 translators. ARIN staff will use their discretion when
> evaluating justifications.
>
> This block will be subject to a minimum size allocation of /28 and a
> maximum size allocation of /24. ARIN should use sparse allocation when
> possible within that /10 block.
>
> In order to receive an allocation or assignment under this policy:
>
>   1. the applicant may not have received resources under this policy  
> in
>      the preceding six months;
>   2. previous allocations/assignments under this policy must continue
>      to meet the justification requirements of this policy;
>   3. previous allocations/assignments under this policy must meet the
>      utilization requirements of end user assignments;
>   4. the applicant must demonstrate that no other allocations or
>      assignments will meet this need;
>   5. on subsequent allocation under this policy, ARIN staff may  
> require
>      applicants to renumber out of previously allocated / assigned
>      space under this policy in order to minimize non-contiguous
>      allocations;
>   6. recipient organizations must be members in good standing of ARIN.
>
> Rationale for reserving IPv4 space:
>
> This policy provides predictability on how the end game of IPv4 is  
> going
> to be played after IANA completion. It will facilitate IPv6 deployment
> by ensuring that some small chunks of IPv4 space will remain available
> for a long time to ease the co-existence of IPv4 & IPv6.
>
> Rationale for reserving a contiguous /10
>
> This is a balance between setting aside too much space and not having
> enough to facilitate IPv6 deployment for many years. Out of the  
> last /8,
> that would leave the equivalent of 3 /10 to ARIN either for business  
> as
> usual or for other policies in the spirit of this one.
>
> A /10 represents 4,194,304 IP addresses, If all of them were to be  
> used
> in NAT-PT or NAT464 type devices with a consolidation factor of 100
> users behind each IP address, that would represent about 400 million  
> users.
>
> Most networks today filter IPv4 announcements more specific than /24.
> This policy creates allocations & assignment prefixes as long as /28.
> Allocating out of a contiguous block will mitigate the impact of this
> policy on filter lists.
>
> Rationale for minimum size allocation of /28
>
> This minimum size allocation will put a cap at 250k additional entries
> in the global IPv4 routing table.
>
> Rationale for maximum size allocation of /24 and for the 6 month delay
> between allocations
>
> This maximum allocation size coupled with the requirement of a 6  
> months
> delay between allocations will prevent hoarding and make sure this  
> pool
> will last several years.
>
> Rationale for forced renumbering for further allocation
>
> The minimum allocation size of /28 may create a huge increase in the
> IPv4 routing table size. Forcing renumbering for subsequent  
> allocations
> under this policy will somehow limit the growth of the routing table
> size by enabling the announcement of aggregated space. It is expected
> that the savings in routing table entries will outweigh the pain of
> forced renumbering.
>
> However, renumbering is never an easy task, so it should only be
> considered as last resort. it is expected that sparse allocation
> techniques will prevent the need of force renumbering for a fairly  
> long
> time.
>
> Note: This policy proposal hints that the /10 should come out of the
> last /8 received by ARIN from IANA. However, it does not say so
> explicitly, leaving the final decision up to the ARIN staff.
>
> Timetable for implementation:
>
> As soon as ARIN gets its last /8 allocation from IANA.
>
>
>
>
>
> _______________________________________________
> 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/20081023/62e9f629/attachment.htm>

From jrhett at svcolo.com  Thu Oct 23 20:50:33 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Thu, 23 Oct 2008 17:50:33 -0700
Subject: [arin-ppml] "Millions of Internet Addresses
	AreLying	Idle"(slashdot)
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08DA6AEF@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC08DA6AEF@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <0E13F096-45DC-489C-9C3F-E754B8B45994@svcolo.com>

On Oct 23, 2008, at 2:37 AM, <michael.dillon at bt.com> <michael.dillon at bt.com 
 > wrote:
> Both you and Jo are asserting here that ARIN billing
> addressing info is separate from the POC info associated with
> that org.  Do EITHER of you have ANY authoratative statement
> from anyone at ARIN that states this?


No, Michael.  I just assumed that ARIN hires full-time psychics.  I  
mean seriously, look at WHOIS for 64.13.128.0/18.  See any mention of billing at svcolo.com 
?

So ARIN sends the bills to that e-mail address.  I have no idea why.   
I figured they hired full-time psychics or something.
</sarcasm>

Yes, Michael I know that they do have a POC for billing.  Why?   
Because it's on the freaking forms.  And it's in the Secure Login  
area.  And everything else.  It's right in front of my face.

I know you enjoy being an argumentative SOB, but would you limit to  
things which aren't factually obvious right in front of us?  We all  
have better things to do.  Thanks.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From pauldotwall at gmail.com  Fri Oct 24 01:14:15 2008
From: pauldotwall at gmail.com (Paul Wall)
Date: Fri, 24 Oct 2008 01:14:15 -0400
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <48FFA87D.30208@psg.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
	<48FF9D61.3040909@batie.org> <48FFA144.5060808@internap.com>
	<4AB6631E-D761-476A-B4B7-F7C31F3CEF4D@svcolo.com>
	<48FFA72A.4020703@internap.com> <48FFA87D.30208@psg.com>
Message-ID: <620fd17c0810232214o6d4f28afue43ef36e590ce990@mail.gmail.com>

Yes.

Put differently, and as randy might say, we tried that 20 years ago.
It didn't work then.

Drive Slow,
Paul Wall

On 10/22/08, Randy Bush <randy at psg.com> wrote:
>>>> The main justification for the ... minimum is to make sure that they
>>>> never have to come back for space
>>> I heard that exact sentence uttered almost 20 years ago, and let me tell
>>> you... that worked out just fine!
>> Do you think we got it right this time, with 340 trillion, trillion,
>> trillion addresses (or 35 trillion /48's)?  :)
>
> as danny cohen said last wednesday
>   first it was 8 bits
>   then times four to 32 bits
>   then times four to 128 bits
>   and he assumes times four to 512 bits
>
> rinse repeat
>
> 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.
>

-- 
Sent from my mobile device


From martin.hannigan at batelnet.bs  Fri Oct 24 03:15:32 2008
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Fri, 24 Oct 2008 03:15:32 -0400
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <620fd17c0810232214o6d4f28afue43ef36e590ce990@mail.gmail.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
	<48FF9D61.3040909@batie.org> <48FFA144.5060808@internap.com>
	<4AB6631E-D761-476A-B4B7-F7C31F3CEF4D@svcolo.com>
	<48FFA72A.4020703@internap.com> <48FFA87D.30208@psg.com>
	<620fd17c0810232214o6d4f28afue43ef36e590ce990@mail.gmail.com>
Message-ID: <4607e1d50810240015m4f9b4097q7541a92652d95e96@mail.gmail.com>

A minor "perspective" comment.

With regards to all the of the fine people who have access to the 'Paul
Wall' email address, I'd be shocked if more than 99.2% of them were even a
twinkle in the stars 20 years ago.

Best,

Martin



On Fri, Oct 24, 2008 at 1:14 AM, Paul Wall <pauldotwall at gmail.com> wrote:

> Yes.
>
> Put differently, and as randy might say, we tried that 20 years ago.
> It didn't work then.
>
> Drive Slow,
> Paul Wall
>
> On 10/22/08, Randy Bush <randy at psg.com> wrote:
> >>>> The main justification for the ... minimum is to make sure that they
> >>>> never have to come back for space
> >>> I heard that exact sentence uttered almost 20 years ago, and let me
> tell
> >>> you... that worked out just fine!
> >> Do you think we got it right this time, with 340 trillion, trillion,
> >> trillion addresses (or 35 trillion /48's)?  :)
> >
> > as danny cohen said last wednesday
> >   first it was 8 bits
> >   then times four to 32 bits
> >   then times four to 128 bits
> >   and he assumes times four to 512 bits
> >
> > rinse repeat
> >
> > 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.
> >
>
> --
> Sent from my mobile device
> _______________________________________________
> 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/20081024/61f1d0d2/attachment.htm>

From ppml at rs.seastrom.com  Sun Oct 26 07:32:11 2008
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Sun, 26 Oct 2008 07:32:11 -0400
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <48FFA87D.30208@psg.com> (Randy Bush's message of "Wed,
	22 Oct 2008 15:26:05 -0700")
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
	<48FF9D61.3040909@batie.org> <48FFA144.5060808@internap.com>
	<4AB6631E-D761-476A-B4B7-F7C31F3CEF4D@svcolo.com>
	<48FFA72A.4020703@internap.com> <48FFA87D.30208@psg.com>
Message-ID: <86k5bvlhhg.fsf@seastrom.com>


Randy Bush <randy at psg.com> writes:

>>>> The main justification for the ... minimum is to make sure that they
>>>> never have to come back for space
>>> I heard that exact sentence uttered almost 20 years ago, and let me tell 
>>> you... that worked out just fine!
>> Do you think we got it right this time, with 340 trillion, trillion, 
>> trillion addresses (or 35 trillion /48's)?  :)
>
> as danny cohen said last wednesday
>   first it was 8 bits
>   then times four to 32 bits
>   then times four to 128 bits
>   and he assumes times four to 512 bits

Unfortunately, glib quips that conflate multiplication with
exponentiation help perpetuate people's gross underestimation of the
vastness of the address space we're talking about here.

Let's restate that quote as:

first it was 2^8
then 2^(8*4) = 4.2 * 10^9
then 2^(8*4*4) = 3.8 * 10^38
and he assumes 2^(8*4*4*4) = 1.3 * 10^154

(the last equation suggests enough addresses to give 10^74 addresses
to each atom in the visible universe.  dealing with a routing table to
do this or pinging each address in non-universe-epochal-time is out of
scope for this discussion).

-r



From tme at multicasttech.com  Sun Oct 26 12:25:08 2008
From: tme at multicasttech.com (Marshall Eubanks)
Date: Sun, 26 Oct 2008 12:25:08 -0400
Subject: [arin-ppml] fee schedule and allocation
In-Reply-To: <86k5bvlhhg.fsf@seastrom.com>
References: <369EB04A0951824ABE7D8BAC67AF9BB40BB7A7D9@CL-S-EX-1.stanleyassociates.com>
	<48FF9D61.3040909@batie.org> <48FFA144.5060808@internap.com>
	<4AB6631E-D761-476A-B4B7-F7C31F3CEF4D@svcolo.com>
	<48FFA72A.4020703@internap.com> <48FFA87D.30208@psg.com>
	<86k5bvlhhg.fsf@seastrom.com>
Message-ID: <8BBA2466-4465-4EE3-AB26-11297528041F@multicasttech.com>


On Oct 26, 2008, at 7:32 AM, Robert E. Seastrom wrote:

>
> Randy Bush <randy at psg.com> writes:
>
>>>>> The main justification for the ... minimum is to make sure that  
>>>>> they
>>>>> never have to come back for space
>>>> I heard that exact sentence uttered almost 20 years ago, and let  
>>>> me tell
>>>> you... that worked out just fine!
>>> Do you think we got it right this time, with 340 trillion, trillion,
>>> trillion addresses (or 35 trillion /48's)?  :)
>>
>> as danny cohen said last wednesday
>>  first it was 8 bits
>>  then times four to 32 bits
>>  then times four to 128 bits
>>  and he assumes times four to 512 bits
>
> Unfortunately, glib quips that conflate multiplication with
> exponentiation help perpetuate people's gross underestimation of the
> vastness of the address space we're talking about here.
>
> Let's restate that quote as:
>
> first it was 2^8
> then 2^(8*4) = 4.2 * 10^9
> then 2^(8*4*4) = 3.8 * 10^38
> and he assumes 2^(8*4*4*4) = 1.3 * 10^154
>
> (the last equation suggests enough addresses to give 10^74 addresses
> to each atom in the visible universe.  dealing with a routing table to
> do this or pinging each address in non-universe-epochal-time is out of
> scope for this discussion).

It would be perfect for steganography - just hide the true message in  
the address.

Regards
Marshall


>
>
> -r
>
> _______________________________________________
> 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 cgrundemann at gmail.com  Mon Oct 27 14:52:46 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 27 Oct 2008 12:52:46 -0600
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
Message-ID: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>

This is (yet another) a policy that may help us ease away from IPv4,
maintain contact between ARIN and it's members and maybe even avoid a
transfer market.  I have been kicking the general idea around for over six
months and it has recently matured with input from some very intelligent
folks.  I do not want to associate them with this particular idea
unwittingly so I won't name them here but I would like to thank them here
anonymously - thank you.  It is not an official proposal yet as I fear that
there won't be much support for it.  If you do think that this is a good
idea or at least on the right track, please let me know - on or off list.  I
don't want to bang my head against the wall too long if I am alone.  Also,
if you hate it, think I am crazy or just don't think it will work, I would
love to hear why.   Although many have influenced it, this is my work and my
opinion alone and does not represent the views of any organization or
individuals I may be affiliated with. ((IMHO))
Thank you,
~Chris


== Potential Proposal:

Once every 12months each holder of IPv4 addresses is required to fully
document their IP utilization and demonstrate that the current utilization
standard for IPv4 assignments and allocations is being met. This shall
include all currently held IPv4 space, regardless of origin or registration
status.

A fee shall be assessed for underutilization or insufficient documentation.

    * The fee for one 12m period shall be waived if the address holder
returns a contiguous block of IPv4 space equal to at least 1/256th of
currently held space and no less than one /24 (class C equivalent) to ARINs
free pool.
    * The fee for one 12m period shall be waived if the address holder signs
an ARIN RSA for any uncontested and unregistered IPv4 space, this waiver
shall be restricted to one use per member organization.


== Rationale:

IP space (v4, v6, vX) is a public resource and as such should be borrowed,
used and returned by those with a need for it. Think of IPv4 prefixes like
library books (another finite public resource): When you check out a book,
you are expected to return it on a certain date. If that date comes and you
are still actively using the book, you are allowed to state that and keep
the book. Since we are at a point now where IPv4 space is recognizably
finite, it makes sense to implement a similar policy at the RIR(s) - that is
a time frame. This policy would require that after X amount of time, the
LIR/EU would need to return to the RIR with justification if they wish to
keep the space. The burden should be on the LIR/EU to prove that they are
actively using the space.


== Some thoughts:

1) This policy should be part of a comprehensive plan including:
- A policy to identify abandoned space
- A policy to reclaim abandoned space
- A policy to restrict some (if not all) IPv4 space allocations/assignments
to new entrants deploying IPv6
- A continuing increase in utilization requirements

2) I do worry that some (perhaps many) will try to game the system by
exaggerating or falsifying 'proof' of efficient utilization. At the same
time I think that having that caveat will make this much easier for most to
swallow and hopefully accept than a similar proposal which assessed the fee
to all holders of IPv4 space regardless of utilization. The idea (hope) is
that as IPv4 becomes more and more scarce, the community will raise the
utilization requirements to include things like NAT and IPv6. This would
provide a constant pressure on all community members to become more
efficient in their IPv4 use which in turn should help keep some addresses
free for new entrants. This is the opposite effect of an unrestricted market
based approach which would encourage large holders of addresses to hold more
and more IPv4, to store value and bar new competition.

3) I am not sure what the fee should be or if it should be spelled out in
policy, this is probably something that ARIN staff should set and be able to
change when needed. Perhaps the policy should define simply how the fee is
assessed, ie: per IP or per % underutilized, etc. It may also be helpful or
necessary to add a statement in the policy requiring any proceeds from these
fees to be used for something in particular (legacy outreach, IPv6
promotion, payment/credit to orgs with utilization above the efficiency
requirement, etc).

4) I expect that some (possibly many) organizations will find it easier to
simply return some space than even trouble themselves with trying to justify
their current holdings. This will be especially true of organizations which
hold large amounts of space.

5) I am expecting that bringing resources under an ARIN RSA may be easier
and less painful for organizations which already hold other RSA covered
space than a full IP audit or returning space. Under this assumption the
final sentence has two goals:
A) To help incent organizations to secure legacy space in any existing or
inevitable grey/black market early on (and get it over with). If there are
no back-room deals for exchange of legacy space now or in the future, than
this is not an issue and can be ignored, this policy will have no affect in
this area.
B) To get any transfered legacy IPv4 space (see point A) under an RSA so
that we are all playing on the same field by the same rules. I think if
everyone had a more similar role in the game we might work together better.
I will note however that legacy holders with no RSA covered space have no
increased incentive to sign an RSA under this proposal then they do today
(and no increased risk in not signing one).

6) I originally considered a period of 24 months but shortened it to 12
months considering the rapid approach of IANA free pool exhaustion; 24
months will be far to long of an interval to have a significant impact on
IPv4 availability.


-- 
Chris Grundemann
www.chrisgrundemann.com
www.linkedin.com/in/cgrundemann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081027/ab2025bf/attachment.htm>

From kkargel at polartel.com  Mon Oct 27 15:14:26 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 27 Oct 2008 14:14:26 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
References: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB0E@mail>

I would not support this policy.  I have enough annual admin tasks the way
it is.  I remember the trouble I have had providing "sufficient"
documentation for each of my allocations.  I would resist any effort to
assess fees for "insufficient" documentation.


  _____  

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Chris Grundemann
Sent: Monday, October 27, 2008 1:53 PM
To: ARIN PPML
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity


This is (yet another) a policy that may help us ease away from IPv4,
maintain contact between ARIN and it's members and maybe even avoid a
transfer market.  I have been kicking the general idea around for over six
months and it has recently matured with input from some very intelligent
folks.  I do not want to associate them with this particular idea
unwittingly so I won't name them here but I would like to thank them here
anonymously - thank you.  It is not an official proposal yet as I fear that
there won't be much support for it.  If you do think that this is a good
idea or at least on the right track, please let me know - on or off list.  I
don't want to bang my head against the wall too long if I am alone.  Also,
if you hate it, think I am crazy or just don't think it will work, I would
love to hear why.   Although many have influenced it, this is my work and my
opinion alone and does not represent the views of any organization or
individuals I may be affiliated with. ((IMHO))
Thank you,
~Chris


== Potential Proposal:

Once every 12months each holder of IPv4 addresses is required to fully
document their IP utilization and demonstrate that the current utilization
standard for IPv4 assignments and allocations is being met. This shall
include all currently held IPv4 space, regardless of origin or registration
status.

A fee shall be assessed for underutilization or insufficient documentation.

    * The fee for one 12m period shall be waived if the address holder
returns a contiguous block of IPv4 space equal to at least 1/256th of
currently held space and no less than one /24 (class C equivalent) to ARINs
free pool.
    * The fee for one 12m period shall be waived if the address holder signs
an ARIN RSA for any uncontested and unregistered IPv4 space, this waiver
shall be restricted to one use per member organization.


== Rationale:

IP space (v4, v6, vX) is a public resource and as such should be borrowed,
used and returned by those with a need for it. Think of IPv4 prefixes like
library books (another finite public resource): When you check out a book,
you are expected to return it on a certain date. If that date comes and you
are still actively using the book, you are allowed to state that and keep
the book. Since we are at a point now where IPv4 space is recognizably
finite, it makes sense to implement a similar policy at the RIR(s) - that is
a time frame. This policy would require that after X amount of time, the
LIR/EU would need to return to the RIR with justification if they wish to
keep the space. The burden should be on the LIR/EU to prove that they are
actively using the space.


== Some thoughts:

1) This policy should be part of a comprehensive plan including:
- A policy to identify abandoned space
- A policy to reclaim abandoned space
- A policy to restrict some (if not all) IPv4 space allocations/assignments
to new entrants deploying IPv6
- A continuing increase in utilization requirements

2) I do worry that some (perhaps many) will try to game the system by
exaggerating or falsifying 'proof' of efficient utilization. At the same
time I think that having that caveat will make this much easier for most to
swallow and hopefully accept than a similar proposal which assessed the fee
to all holders of IPv4 space regardless of utilization. The idea (hope) is
that as IPv4 becomes more and more scarce, the community will raise the
utilization requirements to include things like NAT and IPv6. This would
provide a constant pressure on all community members to become more
efficient in their IPv4 use which in turn should help keep some addresses
free for new entrants. This is the opposite effect of an unrestricted market
based approach which would encourage large holders of addresses to hold more
and more IPv4, to store value and bar new competition.

3) I am not sure what the fee should be or if it should be spelled out in
policy, this is probably something that ARIN staff should set and be able to
change when needed. Perhaps the policy should define simply how the fee is
assessed, ie: per IP or per % underutilized, etc. It may also be helpful or
necessary to add a statement in the policy requiring any proceeds from these
fees to be used for something in particular (legacy outreach, IPv6
promotion, payment/credit to orgs with utilization above the efficiency
requirement, etc).

4) I expect that some (possibly many) organizations will find it easier to
simply return some space than even trouble themselves with trying to justify
their current holdings. This will be especially true of organizations which
hold large amounts of space.

5) I am expecting that bringing resources under an ARIN RSA may be easier
and less painful for organizations which already hold other RSA covered
space than a full IP audit or returning space. Under this assumption the
final sentence has two goals:
A) To help incent organizations to secure legacy space in any existing or
inevitable grey/black market early on (and get it over with). If there are
no back-room deals for exchange of legacy space now or in the future, than
this is not an issue and can be ignored, this policy will have no affect in
this area.
B) To get any transfered legacy IPv4 space (see point A) under an RSA so
that we are all playing on the same field by the same rules. I think if
everyone had a more similar role in the game we might work together better.
I will note however that legacy holders with no RSA covered space have no
increased incentive to sign an RSA under this proposal then they do today
(and no increased risk in not signing one).

6) I originally considered a period of 24 months but shortened it to 12
months considering the rapid approach of IANA free pool exhaustion; 24
months will be far to long of an interval to have a significant impact on
IPv4 availability.


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081027/584fc4cf/attachment.htm>
-------------- 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/20081027/584fc4cf/attachment.bin>

From ed at easent.net  Mon Oct 27 15:22:49 2008
From: ed at easent.net (Ed)
Date: Mon, 27 Oct 2008 15:22:49 -0400
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <mailman.171323.1225134879.29428.arin-ppml@arin.net>
Message-ID: <49061509.6020308@easent.net>

Chris,

I would be totally opposed to such an extreme proposal.  The 
administrative costs for both the holder of the resource and ARIN would 
be over the top, and I doubt this policy would have any significant 
benefit other than more cost.

--Ed

arin-ppml-request at arin.net wrote:
> Date: Mon, 27 Oct 2008 12:52:46 -0600
> From: "Chris Grundemann" <cgrundemann at gmail.com>
> Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> To: "ARIN PPML" <ppml at arin.net>
> Message-ID:
> 	<443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> This is (yet another) a policy that may help us ease away from IPv4,
> maintain contact between ARIN and it's members and maybe even avoid a
> transfer market.  I have been kicking the general idea around for over six
> months and it has recently matured with input from some very intelligent
> folks.  I do not want to associate them with this particular idea
> unwittingly so I won't name them here but I would like to thank them here
> anonymously - thank you.  It is not an official proposal yet as I fear that
> there won't be much support for it.  If you do think that this is a good
> idea or at least on the right track, please let me know - on or off list.  I
> don't want to bang my head against the wall too long if I am alone.  Also,
> if you hate it, think I am crazy or just don't think it will work, I would
> love to hear why.   Although many have influenced it, this is my work and my
> opinion alone and does not represent the views of any organization or
> individuals I may be affiliated with. ((IMHO))
> Thank you,
> ~Chris
> 
> 
> == Potential Proposal:
> 
> Once every 12months each holder of IPv4 addresses is required to fully
> document their IP utilization and demonstrate that the current utilization
> standard for IPv4 assignments and allocations is being met. This shall
> include all currently held IPv4 space, regardless of origin or registration
> status.
> 
> A fee shall be assessed for underutilization or insufficient documentation.
> 
>     * The fee for one 12m period shall be waived if the address holder
> returns a contiguous block of IPv4 space equal to at least 1/256th of
> currently held space and no less than one /24 (class C equivalent) to ARINs
> free pool.
>     * The fee for one 12m period shall be waived if the address holder signs
> an ARIN RSA for any uncontested and unregistered IPv4 space, this waiver
> shall be restricted to one use per member organization.
> 
> 
> == Rationale:
> 
> IP space (v4, v6, vX) is a public resource and as such should be borrowed,
> used and returned by those with a need for it. Think of IPv4 prefixes like
> library books (another finite public resource): When you check out a book,
> you are expected to return it on a certain date. If that date comes and you
> are still actively using the book, you are allowed to state that and keep
> the book. Since we are at a point now where IPv4 space is recognizably
> finite, it makes sense to implement a similar policy at the RIR(s) - that is
> a time frame. This policy would require that after X amount of time, the
> LIR/EU would need to return to the RIR with justification if they wish to
> keep the space. The burden should be on the LIR/EU to prove that they are
> actively using the space.
> 
> 
> == Some thoughts:
> 
> 1) This policy should be part of a comprehensive plan including:
> - A policy to identify abandoned space
> - A policy to reclaim abandoned space
> - A policy to restrict some (if not all) IPv4 space allocations/assignments
> to new entrants deploying IPv6
> - A continuing increase in utilization requirements
> 
> 2) I do worry that some (perhaps many) will try to game the system by
> exaggerating or falsifying 'proof' of efficient utilization. At the same
> time I think that having that caveat will make this much easier for most to
> swallow and hopefully accept than a similar proposal which assessed the fee
> to all holders of IPv4 space regardless of utilization. The idea (hope) is
> that as IPv4 becomes more and more scarce, the community will raise the
> utilization requirements to include things like NAT and IPv6. This would
> provide a constant pressure on all community members to become more
> efficient in their IPv4 use which in turn should help keep some addresses
> free for new entrants. This is the opposite effect of an unrestricted market
> based approach which would encourage large holders of addresses to hold more
> and more IPv4, to store value and bar new competition.
> 
> 3) I am not sure what the fee should be or if it should be spelled out in
> policy, this is probably something that ARIN staff should set and be able to
> change when needed. Perhaps the policy should define simply how the fee is
> assessed, ie: per IP or per % underutilized, etc. It may also be helpful or
> necessary to add a statement in the policy requiring any proceeds from these
> fees to be used for something in particular (legacy outreach, IPv6
> promotion, payment/credit to orgs with utilization above the efficiency
> requirement, etc).
> 
> 4) I expect that some (possibly many) organizations will find it easier to
> simply return some space than even trouble themselves with trying to justify
> their current holdings. This will be especially true of organizations which
> hold large amounts of space.
> 
> 5) I am expecting that bringing resources under an ARIN RSA may be easier
> and less painful for organizations which already hold other RSA covered
> space than a full IP audit or returning space. Under this assumption the
> final sentence has two goals:
> A) To help incent organizations to secure legacy space in any existing or
> inevitable grey/black market early on (and get it over with). If there are
> no back-room deals for exchange of legacy space now or in the future, than
> this is not an issue and can be ignored, this policy will have no affect in
> this area.
> B) To get any transfered legacy IPv4 space (see point A) under an RSA so
> that we are all playing on the same field by the same rules. I think if
> everyone had a more similar role in the game we might work together better.
> I will note however that legacy holders with no RSA covered space have no
> increased incentive to sign an RSA under this proposal then they do today
> (and no increased risk in not signing one).
> 
> 6) I originally considered a period of 24 months but shortened it to 12
> months considering the rapid approach of IANA free pool exhaustion; 24
> months will be far to long of an interval to have a significant impact on
> IPv4 availability.
> 
> 

-- 
-----------------------------------------------------------
EAS Enterprises LLC
World Class Web and Email Hosting Solutions
www.easent.net


From tedm at ipinc.net  Mon Oct 27 15:57:26 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 27 Oct 2008 12:57:26 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
Message-ID: <0E64B015C3A14403AB4C6B1ADC54B3D0@tedsdesk>

My concern with this embryonic proposal is as follows:
 
1) If it worked it would merely add fragmented blocks back into the IPv4
pool, thus
increasing the BGP route entries when those were reassigned.
 
2) You and I both have proposals in process to attempt to get a handle on
the amount
of abandonded IPv4 by verifying the POCs.  I would prefer to allow those to
mature and
(hopefully) be added to the NRPM first, and I think it is unwise for you,
particularly, to
get involved in pushing another controversial proposal until the dust has
settled on the
first.
 
3) Morally I do not think ARIN or the community has the right to press
holders for
unabandonded, unused IPv4 until ARIN can prove to the community's
satisfaction
that it has collected up abandoned IPv4.  I personally have a subnet on my
list that
I know for a fact is abandonded, and I have provided ARIN with the
documentation
to prove it i's abandonded, several years ago, yet the subnet has not been
absorbed into
the free pool.  I would strenuously object to ARIN bugging me about possibly
unused
numbers we have in our allocated block, while doing nothing about a block I
know
is abandonded, and have the documentation to prove is abandonded.
 
4) I feel this proposal diverts from energy spent on work to get IPv6 online
and
routed.
 
Ted

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Chris Grundemann
Sent: Monday, October 27, 2008 11:53 AM
To: ARIN PPML
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity


This is (yet another) a policy that may help us ease away from IPv4,
maintain contact between ARIN and it's members and maybe even avoid a
transfer market.  I have been kicking the general idea around for over six
months and it has recently matured with input from some very intelligent
folks.  I do not want to associate them with this particular idea
unwittingly so I won't name them here but I would like to thank them here
anonymously - thank you.  It is not an official proposal yet as I fear that
there won't be much support for it.  If you do think that this is a good
idea or at least on the right track, please let me know - on or off list.  I
don't want to bang my head against the wall too long if I am alone.  Also,
if you hate it, think I am crazy or just don't think it will work, I would
love to hear why.   Although many have influenced it, this is my work and my
opinion alone and does not represent the views of any organization or
individuals I may be affiliated with. ((IMHO))
Thank you,
~Chris


== Potential Proposal:

Once every 12months each holder of IPv4 addresses is required to fully
document their IP utilization and demonstrate that the current utilization
standard for IPv4 assignments and allocations is being met. This shall
include all currently held IPv4 space, regardless of origin or registration
status.

A fee shall be assessed for underutilization or insufficient documentation.

    * The fee for one 12m period shall be waived if the address holder
returns a contiguous block of IPv4 space equal to at least 1/256th of
currently held space and no less than one /24 (class C equivalent) to ARINs
free pool.
    * The fee for one 12m period shall be waived if the address holder signs
an ARIN RSA for any uncontested and unregistered IPv4 space, this waiver
shall be restricted to one use per member organization.


== Rationale:

IP space (v4, v6, vX) is a public resource and as such should be borrowed,
used and returned by those with a need for it. Think of IPv4 prefixes like
library books (another finite public resource): When you check out a book,
you are expected to return it on a certain date. If that date comes and you
are still actively using the book, you are allowed to state that and keep
the book. Since we are at a point now where IPv4 space is recognizably
finite, it makes sense to implement a similar policy at the RIR(s) - that is
a time frame. This policy would require that after X amount of time, the
LIR/EU would need to return to the RIR with justification if they wish to
keep the space. The burden should be on the LIR/EU to prove that they are
actively using the space.


== Some thoughts:

1) This policy should be part of a comprehensive plan including:
- A policy to identify abandoned space
- A policy to reclaim abandoned space
- A policy to restrict some (if not all) IPv4 space allocations/assignments
to new entrants deploying IPv6
- A continuing increase in utilization requirements

2) I do worry that some (perhaps many) will try to game the system by
exaggerating or falsifying 'proof' of efficient utilization. At the same
time I think that having that caveat will make this much easier for most to
swallow and hopefully accept than a similar proposal which assessed the fee
to all holders of IPv4 space regardless of utilization. The idea (hope) is
that as IPv4 becomes more and more scarce, the community will raise the
utilization requirements to include things like NAT and IPv6. This would
provide a constant pressure on all community members to become more
efficient in their IPv4 use which in turn should help keep some addresses
free for new entrants. This is the opposite effect of an unrestricted market
based approach which would encourage large holders of addresses to hold more
and more IPv4, to store value and bar new competition.

3) I am not sure what the fee should be or if it should be spelled out in
policy, this is probably something that ARIN staff should set and be able to
change when needed. Perhaps the policy should define simply how the fee is
assessed, ie: per IP or per % underutilized, etc. It may also be helpful or
necessary to add a statement in the policy requiring any proceeds from these
fees to be used for something in particular (legacy outreach, IPv6
promotion, payment/credit to orgs with utilization above the efficiency
requirement, etc).

4) I expect that some (possibly many) organizations will find it easier to
simply return some space than even trouble themselves with trying to justify
their current holdings. This will be especially true of organizations which
hold large amounts of space.

5) I am expecting that bringing resources under an ARIN RSA may be easier
and less painful for organizations which already hold other RSA covered
space than a full IP audit or returning space. Under this assumption the
final sentence has two goals:
A) To help incent organizations to secure legacy space in any existing or
inevitable grey/black market early on (and get it over with). If there are
no back-room deals for exchange of legacy space now or in the future, than
this is not an issue and can be ignored, this policy will have no affect in
this area.
B) To get any transfered legacy IPv4 space (see point A) under an RSA so
that we are all playing on the same field by the same rules. I think if
everyone had a more similar role in the game we might work together better.
I will note however that legacy holders with no RSA covered space have no
increased incentive to sign an RSA under this proposal then they do today
(and no increased risk in not signing one).

6) I originally considered a period of 24 months but shortened it to 12
months considering the rapid approach of IANA free pool exhaustion; 24
months will be far to long of an interval to have a significant impact on
IPv4 availability.


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


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

From jrhett at svcolo.com  Mon Oct 27 18:13:10 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Mon, 27 Oct 2008 15:13:10 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
References: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
Message-ID: <3F70B71A-A5EF-4E27-864A-E38FD9B5B587@svcolo.com>

Too complex, too much hand-holding of ARIN staff.  I'd support a much  
simpler, straightforward audit and recovery of space not used.  And no  
"fees".  Any business would pay the fee and keep the space.  Recovery  
should be the failure action.

On Oct 27, 2008, at 11:52 AM, Chris Grundemann wrote:
> This is (yet another) a policy that may help us ease away from IPv4,
> maintain contact between ARIN and it's members and maybe even avoid a
> transfer market.  I have been kicking the general idea around for  
> over six
> months and it has recently matured with input from some very  
> intelligent
> folks.  I do not want to associate them with this particular idea
> unwittingly so I won't name them here but I would like to thank them  
> here
> anonymously - thank you.  It is not an official proposal yet as I  
> fear that
> there won't be much support for it.  If you do think that this is a  
> good
> idea or at least on the right track, please let me know - on or off  
> list.  I
> don't want to bang my head against the wall too long if I am alone.   
> Also,
> if you hate it, think I am crazy or just don't think it will work, I  
> would
> love to hear why.   Although many have influenced it, this is my  
> work and my
> opinion alone and does not represent the views of any organization or
> individuals I may be affiliated with. ((IMHO))
> Thank you,
> ~Chris
>
>
> == Potential Proposal:
>
> Once every 12months each holder of IPv4 addresses is required to fully
> document their IP utilization and demonstrate that the current  
> utilization
> standard for IPv4 assignments and allocations is being met. This shall
> include all currently held IPv4 space, regardless of origin or  
> registration
> status.
>
> A fee shall be assessed for underutilization or insufficient  
> documentation.
>
>    * The fee for one 12m period shall be waived if the address holder
> returns a contiguous block of IPv4 space equal to at least 1/256th of
> currently held space and no less than one /24 (class C equivalent)  
> to ARINs
> free pool.
>    * The fee for one 12m period shall be waived if the address  
> holder signs
> an ARIN RSA for any uncontested and unregistered IPv4 space, this  
> waiver
> shall be restricted to one use per member organization.
>
>
> == Rationale:
>
> IP space (v4, v6, vX) is a public resource and as such should be  
> borrowed,
> used and returned by those with a need for it. Think of IPv4  
> prefixes like
> library books (another finite public resource): When you check out a  
> book,
> you are expected to return it on a certain date. If that date comes  
> and you
> are still actively using the book, you are allowed to state that and  
> keep
> the book. Since we are at a point now where IPv4 space is recognizably
> finite, it makes sense to implement a similar policy at the RIR(s) -  
> that is
> a time frame. This policy would require that after X amount of time,  
> the
> LIR/EU would need to return to the RIR with justification if they  
> wish to
> keep the space. The burden should be on the LIR/EU to prove that  
> they are
> actively using the space.
>
>
> == Some thoughts:
>
> 1) This policy should be part of a comprehensive plan including:
> - A policy to identify abandoned space
> - A policy to reclaim abandoned space
> - A policy to restrict some (if not all) IPv4 space allocations/ 
> assignments
> to new entrants deploying IPv6
> - A continuing increase in utilization requirements
>
> 2) I do worry that some (perhaps many) will try to game the system by
> exaggerating or falsifying 'proof' of efficient utilization. At the  
> same
> time I think that having that caveat will make this much easier for  
> most to
> swallow and hopefully accept than a similar proposal which assessed  
> the fee
> to all holders of IPv4 space regardless of utilization. The idea  
> (hope) is
> that as IPv4 becomes more and more scarce, the community will raise  
> the
> utilization requirements to include things like NAT and IPv6. This  
> would
> provide a constant pressure on all community members to become more
> efficient in their IPv4 use which in turn should help keep some  
> addresses
> free for new entrants. This is the opposite effect of an  
> unrestricted market
> based approach which would encourage large holders of addresses to  
> hold more
> and more IPv4, to store value and bar new competition.
>
> 3) I am not sure what the fee should be or if it should be spelled  
> out in
> policy, this is probably something that ARIN staff should set and be  
> able to
> change when needed. Perhaps the policy should define simply how the  
> fee is
> assessed, ie: per IP or per % underutilized, etc. It may also be  
> helpful or
> necessary to add a statement in the policy requiring any proceeds  
> from these
> fees to be used for something in particular (legacy outreach, IPv6
> promotion, payment/credit to orgs with utilization above the  
> efficiency
> requirement, etc).
>
> 4) I expect that some (possibly many) organizations will find it  
> easier to
> simply return some space than even trouble themselves with trying to  
> justify
> their current holdings. This will be especially true of  
> organizations which
> hold large amounts of space.
>
> 5) I am expecting that bringing resources under an ARIN RSA may be  
> easier
> and less painful for organizations which already hold other RSA  
> covered
> space than a full IP audit or returning space. Under this assumption  
> the
> final sentence has two goals:
> A) To help incent organizations to secure legacy space in any  
> existing or
> inevitable grey/black market early on (and get it over with). If  
> there are
> no back-room deals for exchange of legacy space now or in the  
> future, than
> this is not an issue and can be ignored, this policy will have no  
> affect in
> this area.
> B) To get any transfered legacy IPv4 space (see point A) under an  
> RSA so
> that we are all playing on the same field by the same rules. I think  
> if
> everyone had a more similar role in the game we might work together  
> better.
> I will note however that legacy holders with no RSA covered space  
> have no
> increased incentive to sign an RSA under this proposal then they do  
> today
> (and no increased risk in not signing one).
>
> 6) I originally considered a period of 24 months but shortened it to  
> 12
> months considering the rapid approach of IANA free pool exhaustion; 24
> months will be far to long of an interval to have a significant  
> impact on
> IPv4 availability.
>
>
> -- 
> Chris Grundemann
> www.chrisgrundemann.com
> 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.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From cgrundemann at gmail.com  Mon Oct 27 18:14:39 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 27 Oct 2008 16:14:39 -0600
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB0E@mail>
References: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB0E@mail>
Message-ID: <443de7ad0810271514k309b2eb4q7c6c93d9c9bfb546@mail.gmail.com>

On Mon, Oct 27, 2008 at 1:22 PM, Ed <ed at easent.net> wrote:
>
> Chris,
>
> I would be totally opposed to such an extreme proposal.  The
> administrative costs for both the holder of the resource and ARIN would
> be over the top, and I doubt this policy would have any significant
> benefit other than more cost.
>
> --Ed

On Mon, Oct 27, 2008 at 1:14 PM, Kevin Kargel <kkargel at polartel.com> wrote:
> I would not support this policy.  I have enough annual admin tasks the way
> it is.  I remember the trouble I have had providing "sufficient"
> documentation for each of my allocations.  I would resist any effort to
> assess fees for "insufficient" documentation.

I was attempting to address this by allowing the return of a fraction
of IPv4 space to waive the fee.  In other words if you have a /10 for
example and you returned a /18 to ARIN, you would not need to provide
any documentation whatsoever.

[...]
>     * The fee for one 12m period shall be waived if the address holder
> returns a contiguous block of IPv4 space equal to at least 1/256th of
> currently held space and no less than one /24 (class C equivalent) to ARINs
> free pool.
[...]
> 4) I expect that some (possibly many) organizations will find it easier to
> simply return some space than even trouble themselves with trying to justify
> their current holdings. This will be especially true of organizations which
> hold large amounts of space.
[...]

> _______________________________________________
> 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 cgrundemann at gmail.com  Mon Oct 27 18:31:36 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 27 Oct 2008 16:31:36 -0600
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <0E64B015C3A14403AB4C6B1ADC54B3D0@tedsdesk>
References: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
	<0E64B015C3A14403AB4C6B1ADC54B3D0@tedsdesk>
Message-ID: <443de7ad0810271531x3a365440v13339b3dd2f1de2a@mail.gmail.com>

On Mon, Oct 27, 2008 at 1:57 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> My concern with this embryonic proposal is as follows:
>
> 1) If it worked it would merely add fragmented blocks back into the IPv4
> pool, thus
> increasing the BGP route entries when those were reassigned.

True.

> 2) You and I both have proposals in process to attempt to get a handle on
> the amount
> of abandonded IPv4 by verifying the POCs.  I would prefer to allow those to
> mature and
> (hopefully) be added to the NRPM first, and I think it is unwise for you,
> particularly, to
> get involved in pushing another controversial proposal until the dust has
> settled on the
> first.

I completely agree but decided to post this anyway (after a few days
of wrestling with it) because we just have so little time left at this
point.  If this proposal were to be adopted or were to spark a better
idea in someone else, it has to happen soon; the longer we wait, the
less effective any policy change will be.  To borrow an analogy; the
Titanic sunk in part because they initiated the turn too late.

> 3) Morally I do not think ARIN or the community has the right to press
> holders for
> unabandonded, unused IPv4 until ARIN can prove to the community's
> satisfaction
> that it has collected up abandoned IPv4.  I personally have a subnet on my
> list that
> I know for a fact is abandonded, and I have provided ARIN with the
> documentation
> to prove it i's abandonded, several years ago, yet the subnet has not been
> absorbed into
> the free pool.  I would strenuously object to ARIN bugging me about possibly
> unused
> numbers we have in our allocated block, while doing nothing about a block I
> know
> is abandonded, and have the documentation to prove is abandonded.

Again, time is of the essence; this is also why my first point of
explanation was to state that, imo:
[...]
> 1) This policy should be part of a comprehensive plan including:
> - A policy to identify abandoned space
> - A policy to reclaim abandoned space
> - A policy to restrict some (if not all) IPv4 space allocations/assignments
> to new entrants deploying IPv6
> - A continuing increase in utilization requirements
[...]

> 4) I feel this proposal diverts from energy spent on work to get IPv6 online
> and
> routed.
>
> Ted
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Chris Grundemann
> Sent: Monday, October 27, 2008 11:53 AM
> To: ARIN PPML
> Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
>
> This is (yet another) a policy that may help us ease away from IPv4,
> maintain contact between ARIN and it's members and maybe even avoid a
> transfer market.  I have been kicking the general idea around for over six
> months and it has recently matured with input from some very intelligent
> folks.  I do not want to associate them with this particular idea
> unwittingly so I won't name them here but I would like to thank them here
> anonymously - thank you.  It is not an official proposal yet as I fear that
> there won't be much support for it.  If you do think that this is a good
> idea or at least on the right track, please let me know - on or off list.  I
> don't want to bang my head against the wall too long if I am alone.  Also,
> if you hate it, think I am crazy or just don't think it will work, I would
> love to hear why.   Although many have influenced it, this is my work and my
> opinion alone and does not represent the views of any organization or
> individuals I may be affiliated with. ((IMHO))
> Thank you,
> ~Chris
>
>
> == Potential Proposal:
>
> Once every 12months each holder of IPv4 addresses is required to fully
> document their IP utilization and demonstrate that the current utilization
> standard for IPv4 assignments and allocations is being met. This shall
> include all currently held IPv4 space, regardless of origin or registration
> status.
>
> A fee shall be assessed for underutilization or insufficient documentation.
>
>     * The fee for one 12m period shall be waived if the address holder
> returns a contiguous block of IPv4 space equal to at least 1/256th of
> currently held space and no less than one /24 (class C equivalent) to ARINs
> free pool.
>     * The fee for one 12m period shall be waived if the address holder signs
> an ARIN RSA for any uncontested and unregistered IPv4 space, this waiver
> shall be restricted to one use per member organization.
>
>
> == Rationale:
>
> IP space (v4, v6, vX) is a public resource and as such should be borrowed,
> used and returned by those with a need for it. Think of IPv4 prefixes like
> library books (another finite public resource): When you check out a book,
> you are expected to return it on a certain date. If that date comes and you
> are still actively using the book, you are allowed to state that and keep
> the book. Since we are at a point now where IPv4 space is recognizably
> finite, it makes sense to implement a similar policy at the RIR(s) - that is
> a time frame. This policy would require that after X amount of time, the
> LIR/EU would need to return to the RIR with justification if they wish to
> keep the space. The burden should be on the LIR/EU to prove that they are
> actively using the space.
>
>
> == Some thoughts:
>
> 1) This policy should be part of a comprehensive plan including:
> - A policy to identify abandoned space
> - A policy to reclaim abandoned space
> - A policy to restrict some (if not all) IPv4 space allocations/assignments
> to new entrants deploying IPv6
> - A continuing increase in utilization requirements
>
> 2) I do worry that some (perhaps many) will try to game the system by
> exaggerating or falsifying 'proof' of efficient utilization. At the same
> time I think that having that caveat will make this much easier for most to
> swallow and hopefully accept than a similar proposal which assessed the fee
> to all holders of IPv4 space regardless of utilization. The idea (hope) is
> that as IPv4 becomes more and more scarce, the community will raise the
> utilization requirements to include things like NAT and IPv6. This would
> provide a constant pressure on all community members to become more
> efficient in their IPv4 use which in turn should help keep some addresses
> free for new entrants. This is the opposite effect of an unrestricted market
> based approach which would encourage large holders of addresses to hold more
> and more IPv4, to store value and bar new competition.
>
> 3) I am not sure what the fee should be or if it should be spelled out in
> policy, this is probably something that ARIN staff should set and be able to
> change when needed. Perhaps the policy should define simply how the fee is
> assessed, ie: per IP or per % underutilized, etc. It may also be helpful or
> necessary to add a statement in the policy requiring any proceeds from these
> fees to be used for something in particular (legacy outreach, IPv6
> promotion, payment/credit to orgs with utilization above the efficiency
> requirement, etc).
>
> 4) I expect that some (possibly many) organizations will find it easier to
> simply return some space than even trouble themselves with trying to justify
> their current holdings. This will be especially true of organizations which
> hold large amounts of space.
>
> 5) I am expecting that bringing resources under an ARIN RSA may be easier
> and less painful for organizations which already hold other RSA covered
> space than a full IP audit or returning space. Under this assumption the
> final sentence has two goals:
> A) To help incent organizations to secure legacy space in any existing or
> inevitable grey/black market early on (and get it over with). If there are
> no back-room deals for exchange of legacy space now or in the future, than
> this is not an issue and can be ignored, this policy will have no affect in
> this area.
> B) To get any transfered legacy IPv4 space (see point A) under an RSA so
> that we are all playing on the same field by the same rules. I think if
> everyone had a more similar role in the game we might work together better.
> I will note however that legacy holders with no RSA covered space have no
> increased incentive to sign an RSA under this proposal then they do today
> (and no increased risk in not signing one).
>
> 6) I originally considered a period of 24 months but shortened it to 12
> months considering the rapid approach of IANA free pool exhaustion; 24
> months will be far to long of an interval to have a significant impact on
> IPv4 availability.
>
>
> --
> Chris Grundemann
> www.chrisgrundemann.com
> www.linkedin.com/in/cgrundemann
>



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


From tedm at ipinc.net  Mon Oct 27 18:59:44 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 27 Oct 2008 15:59:44 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810271531x3a365440v13339b3dd2f1de2a@mail.gmail.com>
Message-ID: <248142C4333A40DDB1C55BD2C2064A71@tedsdesk>



> -----Original Message-----
> From: Chris Grundemann [mailto:cgrundemann at gmail.com] 
> Sent: Monday, October 27, 2008 3:32 PM
> To: Ted Mittelstaedt
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> On Mon, Oct 27, 2008 at 1:57 PM, Ted Mittelstaedt 
> <tedm at ipinc.net> wrote:
> > My concern with this embryonic proposal is as follows:
> >
> > 1) If it worked it would merely add fragmented blocks back into the 
> > IPv4 pool, thus increasing the BGP route entries when those were 
> > reassigned.
> 
> True.
> 
> > 2) You and I both have proposals in process to attempt to 
> get a handle 
> > on the amount of abandonded IPv4 by verifying the POCs.  I would 
> > prefer to allow those to mature and
> > (hopefully) be added to the NRPM first, and I think it is 
> unwise for you,
> > particularly, to
> > get involved in pushing another controversial proposal 
> until the dust has
> > settled on the
> > first.
> 
> I completely agree but decided to post this anyway (after a 
> few days of wrestling with it) because we just have so little 
> time left at this point.  If this proposal were to be adopted 
> or were to spark a better idea in someone else, it has to 
> happen soon; the longer we wait, the less effective any 
> policy change will be.  To borrow an analogy; the Titanic 
> sunk in part because they initiated the turn too late.
> 

I think in this instance the analogy is more along the lines
of when the US Continental Congress wrote the US Constitution.

Many people save constitutional scholars are unaware that the
original Declaration of Independence contained a clause outlawing
slavery, but due to Southern colonies resistance that clause was
dropped, Thomas Jefferson again tried to introduce an anti-slavery
proposal in 1784 but was rejected by South Carolina, Maryland and Virgina,
voting against it.  Benjamin Franklin helped found the Pennsylvania
abolitionists society in 1774.  Yet, the continental congress punted
on this issue - because it was controversal they left it for the
future.

The result, a century later, was civil war.

When ARIN was founded, if they had fought the Legacy battle then,
as well as the battle to make efficient resource use then, a lot
of the grey today on IPv4 probably would not exist.  Proposals
like yours are sparked precisely because the IPv4 runout definition
itself is very grey.

Fundamentally the problem isn't so much that we are running out of
IPv4.  If this was a completely black and white issue - like for
example, a car running out of gasoline, there would be no argument.
Your either out of gas or your not - and the passengers don't then
engage in a debate on whether there's a flask of gasoline in the
glovebox that might get us another mile to the gas station.  IPv4
by contrast, there's enough greyness in whether or not that we are
really "out" that people are arguing over it.

Ted



From michael at rancid.berkeley.edu  Mon Oct 27 20:23:44 2008
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Mon, 27 Oct 2008 17:23:44 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
References: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
Message-ID: <49065B90.8000202@rancid.berkeley.edu>


On 10/27/08 11:52 AM, Chris Grundemann wrote:

> IP space (v4, v6, vX) is a public resource and as such should be borrowed,
> used and returned by those with a need for it. Think of IPv4 prefixes like
> library books (another finite public resource): When you check out a book,
> you are expected to return it on a certain date. If that date comes and you
> are still actively using the book, you are allowed to state that and keep
> the book. Since we are at a point now where IPv4 space is recognizably
> finite, it makes sense to implement a similar policy at the RIR(s) - that is
> a time frame. This policy would require that after X amount of time, the
> LIR/EU would need to return to the RIR with justification if they wish to
> keep the space. The burden should be on the LIR/EU to prove that they are
> actively using the space.

Just a philosophical question here: The above seems to imply that the 
expected behavior by an organization or service provider who makes the 
transition to IPv6 will eventually be to give back space as part of that 
transition.  Two alternative possibilities exist that I can think of:

2. [#1 is already listed above] Organizations that transition to IPv6 
are allowed to keep their IPv4 space (in the absence of a transfer 
market) as they transition away from it.  RIRs become less concerned 
with IPv4 as IPv6 takes hold, and eventually all IPv4 holdings become 
irrelevant.  (I realize I am condensing possibly 10-15 years into two 
sentences.)

3. Organizations that quickly transition to IPv6 can recoup some of the 
cost of the transition by selling IPv4 addresses in a transfer market. 
Such a market would then provide incentives for transitioning to IPv6 at 
a certain time (i.e. once enough IPv6 services and/or transition 
mechanisms exist to make it feasible, and after IPv4 free-pool runout, 
but before all of the wealthy laggards have transitioned--otherwise 
there will be no buyers) because "early-to-middle adopters" can sell 
their unused v4 space to wealthy late-adopters who need it.  Eventually 
enough entities will transition and start rolling out v6-only services 
that the laggards will find it in their best interests to transition. 
The market for IPv4 eventually collapses and nobody cares.

All three assume a largely successful transition to IPv6.  Outcomes that 
don't assume a successful transition are out of scope of this immediate 
discussion.

I think that my assumption had always been that #2 and #3 were much more 
likely and feasible than #1.  It's not that I am necessarily in favor of 
a market address exchange, but I recognize that it may be a lot more 
likely to just happen than an voluntary return of resources to ARIN. 
Moreover, once IPv4 resources can no longer be monetized because IPv6 is 
the dominant protocol, returning resources to ARIN will be a waste of 
{ARIN's, the member's} time because they will basically be worthless.

I'd like to hear from other folks who think that #1 is a viable option 
and should be pursued, but at this point, I oppose the policy because I 
think it rests on a not-very-likely assumption.

michael


From farmer at umn.edu  Mon Oct 27 20:58:14 2008
From: farmer at umn.edu (David Farmer)
Date: Mon, 27 Oct 2008 19:58:14 -0500
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
Message-ID: <49061D56.6358.FF331AB@farmer.umn.edu>

Geoff,

You make a persuasive argument for the separation of the Registry and the 
Allocation functions in the RIR and that the Regulatory functions are tied to 
the Allocation functions and not to the Registry functions.

When I look at the construction of RIPE and APNIC Policy, I easily see this 
separation. However, when I look at the construction of ARIN Policy, I don't 
as easily see this separation.  It may actually be there, but just hidden and 
maybe this is a defect in ARIN Policy, or maybe it is a strength in the way 
ARIN policy was structured.  At the very least I believe this would need to be 
clarified in ARIN policy to create the outcome you are suggesting.

Second, you analogize the Registry Function with the function of a title 
office, and I tend to agree with this, especially in the transfer of whole 
Allocated block of addresses.   But unless a whole block that was already 
Allocated is being transferred, then we are talking about a Subdivision 
process, and for land there is defiantly a regulatory regime involved in doing 
that.  The title office may or may not be directly involved in the regulation of 
the subdivision process, honestly I am not sure how that works everywhere.  
But even if the title office is not directly involved in the regulation of the 
subdivision process, it is not free to register the subdivision of the land 
without the necessary regulatory approvals. 

So while I think agree with you about the separation of the Allocation and 
Registry functions.  I don't think IPv4 Address Exhaustion implies the end of 
the Regulatory processes and responsibilities of the RIRs for IPv4, it may  
change the focus, more to the Sub-Allocation process.  This Sub-Allocation 
process is already at least basically regulated in the current regulatory 
regime, all the RIRs place policy on what the LIRs (ISPs) do with the 
allocations granted to them.  If anything IPv4 Address Exhaustion reinforces 
the need for proper regulation of the important process of Sub-Allocation.  

So, at best I think the argument for separation the Registry and Allocation 
Functions provides a argument for the unrestricted transfer of whole IPv4 
address blocks as currently Allocated but does not provide a valid argument 
for deregulation of the Sub-Allocation or the dividing of IPv4 blocks into 
smaller ones.  

Just as with land and the fact that there are many valid reasons it is in the 
public interest to regulate Subdivision of land parcels, there are equally 
many reasons it is in the Internet Community's interest to regulate the Sub-
Allocation of IP address blocks.  And just as a title office can't register the 
subdivision of land without regulatory approval, an Internet Registry can't 
register the Sub-Allocation of IP address blocks without regulatory approval 
either.  In either case it, the title office or Internet Registry, would be acting 
outside of its separate role from the regulatory function and against the 
public interest.

Thanks

David Farmer

On 20 Oct 2008 Geoff Huston wrote:

> Hi,
> 
> At the ARIN meeting last week the question arose as to why the various  
> policy proposals related to address transfers in the different RIRs  
> were so different. I made some comments in response to this question  
> from my perspective and then I had some followup questions mailed to  
> me, so I thought maybe there is some value in writing up from my  
> perspective. After all there is still some difference between the  
> proposal(s) before ARIN and Proposal-50 before APNIC, and  the  
> question as to why this difference exists is an interesting one.
> 
> If you are interested its at: http://www.potaroo.net/ispcol/2008-11/transfers.html
> 
> thanks,
> 
>     Geoff Huston
> 
>     DIsclaimer: I'm speaking for myself, again!
 


=======================================================
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  Tue Oct 28 07:11:26 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 28 Oct 2008 11:11:26 -0000
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08FACA0B@E03MVZ2-UKDY.domain1.systemhost.net>


> Once every 12months each holder of IPv4 addresses is required 
> to fully document their IP utilization and demonstrate that 
> the current utilization standard for IPv4 assignments and 
> allocations is being met. This shall include all currently 
> held IPv4 space, regardless of origin or registration status.

I like this. It is broadly in line with the NANPA processes for
reporting on telephone number utilisation, i.e. there is precedent
for this kind of reporting.

> A fee shall be assessed for underutilization or insufficient 
> documentation.

I'm not sure punitive measures will pass.

>     * The fee for one 12m period shall be waived if the 
> address holder returns a contiguous block of IPv4 space equal 
> to at least 1/256th of currently held space and no less than 
> one /24 (class C equivalent) to ARINs free pool.
>     * The fee for one 12m period shall be waived if the 
> address holder signs an ARIN RSA for any uncontested and 
> unregistered IPv4 space, this waiver shall be restricted to 
> one use per member organization.

These points are completely separate from the main point.
Also, since ARIN members set the fees, not the policymakers,
this detail should not be in a policy proposal.

--Michael Dillon


From info at arin.net  Tue Oct 28 15:04:06 2008
From: info at arin.net (Member Services)
Date: Tue, 28 Oct 2008 15:04:06 -0400
Subject: [arin-ppml] ARIN XXII Meeting Report Now Available
Message-ID: <49076226.8020800@arin.net>

 From 15-17 October, the ARIN community took part in the ARIN XXII 
Public Policy and Members Meeting, held in Los Angeles. The report of 
that meeting, which includes presentations, summary notes, and 
transcripts of the entire meeting, is now available on the ARIN website 
at: http://www.arin.net/meetings/minutes/ARIN_XXII/

Please check back next week when an archive of the meeting's webcast 
will be available.

We thank everyone in the community who participated in person or 
remotely and those who responded to the surveys. We look forward to 
seeing you 26-29 April 2009 for ARIN XXIII in San Antonio, Texas.

Regards,


Member Services
American Registry for Internet Numbers (ARIN)





From jrhett at svcolo.com  Tue Oct 28 17:57:45 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 28 Oct 2008 14:57:45 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC08FACA0B@E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC08FACA0B@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <6DBA06FD-DBEC-43DF-A02E-23D11B06163C@svcolo.com>

I find myself agreeing with Michael on every point.  The utilization  
documentation is good.  Fees won't work, and the weird policy stuff is  
confusing.

On Oct 28, 2008, at 4:11 AM, <michael.dillon at bt.com> <michael.dillon at bt.com 
 > wrote:
>> Once every 12months each holder of IPv4 addresses is required
>> to fully document their IP utilization and demonstrate that
>> the current utilization standard for IPv4 assignments and
>> allocations is being met. This shall include all currently
>> held IPv4 space, regardless of origin or registration status.
>
> I like this. It is broadly in line with the NANPA processes for
> reporting on telephone number utilisation, i.e. there is precedent
> for this kind of reporting.
>
>> A fee shall be assessed for underutilization or insufficient
>> documentation.
>
> I'm not sure punitive measures will pass.
>
>>    * The fee for one 12m period shall be waived if the
>> address holder returns a contiguous block of IPv4 space equal
>> to at least 1/256th of currently held space and no less than
>> one /24 (class C equivalent) to ARINs free pool.
>>    * The fee for one 12m period shall be waived if the
>> address holder signs an ARIN RSA for any uncontested and
>> unregistered IPv4 space, this waiver shall be restricted to
>> one use per member organization.
>
> These points are completely separate from the main point.
> Also, since ARIN members set the fees, not the policymakers,
> this detail should not be in a policy proposal.
>
> --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.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From cgrundemann at gmail.com  Tue Oct 28 18:14:47 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 Oct 2008 16:14:47 -0600
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <6DBA06FD-DBEC-43DF-A02E-23D11B06163C@svcolo.com>
References: <C0F2465B4F386241A58321C884AC7ECC08FACA0B@E03MVZ2-UKDY.domain1.systemhost.net>
	<6DBA06FD-DBEC-43DF-A02E-23D11B06163C@svcolo.com>
Message-ID: <443de7ad0810281514k1729989ay2638adf1c5d0da2@mail.gmail.com>

On Tue, Oct 28, 2008 at 3:57 PM, Jo Rhett <jrhett at svcolo.com> wrote:
> I find myself agreeing with Michael on every point.  The utilization
> documentation is good.  Fees won't work, and the weird policy stuff is
> confusing.

Is it my explanation that is confusing or the policy wording itself?

I tried to keep the policy itself short and direct:

Once every 12months each holder of IPv4 addresses is required to fully
document their IP utilization and demonstrate that the current
utilization standard for IPv4 assignments and allocations is being
met. This shall include all currently held IPv4 space, regardless of
origin or registration status.

A fee shall be assessed for underutilization or insufficient documentation.

    * The fee for one 12m period shall be waived if the address holder
returns a contiguous block of IPv4 space equal to at least 1/256th of
currently held space and no less than one /24 (class C equivalent) to
ARINs free pool.
    * The fee for one 12m period shall be waived if the address holder
signs an ARIN RSA for any uncontested and unregistered IPv4 space,
this waiver shall be restricted to one use per member organization.


> On Oct 28, 2008, at 4:11 AM, <michael.dillon at bt.com> <michael.dillon at bt.com
>  > wrote:
>>> Once every 12months each holder of IPv4 addresses is required
>>> to fully document their IP utilization and demonstrate that
>>> the current utilization standard for IPv4 assignments and
>>> allocations is being met. This shall include all currently
>>> held IPv4 space, regardless of origin or registration status.
>>
>> I like this. It is broadly in line with the NANPA processes for
>> reporting on telephone number utilisation, i.e. there is precedent
>> for this kind of reporting.
>>
>>> A fee shall be assessed for underutilization or insufficient
>>> documentation.
>>
>> I'm not sure punitive measures will pass.
>>
>>>    * The fee for one 12m period shall be waived if the
>>> address holder returns a contiguous block of IPv4 space equal
>>> to at least 1/256th of currently held space and no less than
>>> one /24 (class C equivalent) to ARINs free pool.
>>>    * The fee for one 12m period shall be waived if the
>>> address holder signs an ARIN RSA for any uncontested and
>>> unregistered IPv4 space, this waiver shall be restricted to
>>> one use per member organization.
>>
>> These points are completely separate from the main point.
>> Also, since ARIN members set the fees, not the policymakers,
>> this detail should not be in a policy proposal.
>>
>> --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.
>
> --
> 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.
>



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


From michael.dillon at bt.com  Tue Oct 28 18:28:13 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 28 Oct 2008 22:28:13 -0000
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810281514k1729989ay2638adf1c5d0da2@mail.gmail.com>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC08FAD346@E03MVZ2-UKDY.domain1.systemhost.net>

> Is it my explanation that is confusing or the policy wording itself?

The policy wording is the problem. You took two entirely different
policy proposals and glued them together. It doesn't work.

In fact, your second proposal about fees might be out of scope
for policy entirely.

--Michael Dillon


From jrhett at svcolo.com  Tue Oct 28 19:08:42 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 28 Oct 2008 16:08:42 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810281514k1729989ay2638adf1c5d0da2@mail.gmail.com>
References: <C0F2465B4F386241A58321C884AC7ECC08FACA0B@E03MVZ2-UKDY.domain1.systemhost.net>
	<6DBA06FD-DBEC-43DF-A02E-23D11B06163C@svcolo.com>
	<443de7ad0810281514k1729989ay2638adf1c5d0da2@mail.gmail.com>
Message-ID: <4E05DED3-5469-42F1-AD61-2EAE5B4BB036@svcolo.com>

Stop at the first paragraph.   Fees won't work.   They will either be  
protested or people will happily pay them to avoid having to  
renumber.  And letting organizations return just part of their unused  
space is a very odd precedent.

I would support a proposal based around the first paragraph, without  
mention of fees or weird "dribble-back" schemes.

On Oct 28, 2008, at 3:14 PM, Chris Grundemann wrote:
> On Tue, Oct 28, 2008 at 3:57 PM, Jo Rhett <jrhett at svcolo.com> wrote:
>> I find myself agreeing with Michael on every point.  The utilization
>> documentation is good.  Fees won't work, and the weird policy stuff  
>> is
>> confusing.
>
> Is it my explanation that is confusing or the policy wording itself?
>
> I tried to keep the policy itself short and direct:
>
> Once every 12months each holder of IPv4 addresses is required to fully
> document their IP utilization and demonstrate that the current
> utilization standard for IPv4 assignments and allocations is being
> met. This shall include all currently held IPv4 space, regardless of
> origin or registration status.
>
> A fee shall be assessed for underutilization or insufficient  
> documentation.
>
>    * The fee for one 12m period shall be waived if the address holder
> returns a contiguous block of IPv4 space equal to at least 1/256th of
> currently held space and no less than one /24 (class C equivalent) to
> ARINs free pool.
>    * The fee for one 12m period shall be waived if the address holder
> signs an ARIN RSA for any uncontested and unregistered IPv4 space,
> this waiver shall be restricted to one use per member organization.
>
>
>> On Oct 28, 2008, at 4:11 AM, <michael.dillon at bt.com> <michael.dillon at bt.com
>>> wrote:
>>>> Once every 12months each holder of IPv4 addresses is required
>>>> to fully document their IP utilization and demonstrate that
>>>> the current utilization standard for IPv4 assignments and
>>>> allocations is being met. This shall include all currently
>>>> held IPv4 space, regardless of origin or registration status.
>>>
>>> I like this. It is broadly in line with the NANPA processes for
>>> reporting on telephone number utilisation, i.e. there is precedent
>>> for this kind of reporting.
>>>
>>>> A fee shall be assessed for underutilization or insufficient
>>>> documentation.
>>>
>>> I'm not sure punitive measures will pass.
>>>
>>>>   * The fee for one 12m period shall be waived if the
>>>> address holder returns a contiguous block of IPv4 space equal
>>>> to at least 1/256th of currently held space and no less than
>>>> one /24 (class C equivalent) to ARINs free pool.
>>>>   * The fee for one 12m period shall be waived if the
>>>> address holder signs an ARIN RSA for any uncontested and
>>>> unregistered IPv4 space, this waiver shall be restricted to
>>>> one use per member organization.
>>>
>>> These points are completely separate from the main point.
>>> Also, since ARIN members set the fees, not the policymakers,
>>> this detail should not be in a policy proposal.
>>>
>>> --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.
>>
>> --
>> 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.
>>
>
>
>
> -- 
> Chris Grundemann
> www.chrisgrundemann.com
> www.linkedin.com/in/cgrundemann

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From tedm at ipinc.net  Tue Oct 28 19:22:01 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 28 Oct 2008 16:22:01 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <4E05DED3-5469-42F1-AD61-2EAE5B4BB036@svcolo.com>
Message-ID: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk>


You CANNOT get people to do anything without a consequence if
they fail to do it.  If you subtract fees from this embryonic
proposal, the only thing ARIN has left to compel people to
document their network is the threat of not allowing them to
obtain more IPv4 numbering.  A threat that is meaningless unless
the requestor has need of more IPv4.

And guess what?  Requiring people to document their utilization
is ALREADY A REQUIREMENT for obtaining additional IPv4!!

Please refrain from re-inventing the wheel.

Ted


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jo Rhett
> Sent: Tuesday, October 28, 2008 4:09 PM
> To: Chris Grundemann
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> Stop at the first paragraph.   Fees won't work.   They will 
> either be  
> protested or people will happily pay them to avoid having to  
> renumber.  And letting organizations return just part of 
> their unused  
> space is a very odd precedent.
> 
> I would support a proposal based around the first paragraph, without  
> mention of fees or weird "dribble-back" schemes.
> 
> On Oct 28, 2008, at 3:14 PM, Chris Grundemann wrote:
> > On Tue, Oct 28, 2008 at 3:57 PM, Jo Rhett <jrhett at svcolo.com> wrote:
> >> I find myself agreeing with Michael on every point.  The 
> utilization 
> >> documentation is good.  Fees won't work, and the weird policy stuff
> >> is
> >> confusing.
> >
> > Is it my explanation that is confusing or the policy wording itself?
> >
> > I tried to keep the policy itself short and direct:
> >
> > Once every 12months each holder of IPv4 addresses is 
> required to fully 
> > document their IP utilization and demonstrate that the current 
> > utilization standard for IPv4 assignments and allocations is being 
> > met. This shall include all currently held IPv4 space, 
> regardless of 
> > origin or registration status.
> >
> > A fee shall be assessed for underutilization or insufficient
> > documentation.
> >
> >    * The fee for one 12m period shall be waived if the 
> address holder 
> > returns a contiguous block of IPv4 space equal to at least 
> 1/256th of 
> > currently held space and no less than one /24 (class C 
> equivalent) to 
> > ARINs free pool.
> >    * The fee for one 12m period shall be waived if the 
> address holder 
> > signs an ARIN RSA for any uncontested and unregistered IPv4 space, 
> > this waiver shall be restricted to one use per member organization.
> >
> >
> >> On Oct 28, 2008, at 4:11 AM, <michael.dillon at bt.com> 
> >> <michael.dillon at bt.com
> >>> wrote:
> >>>> Once every 12months each holder of IPv4 addresses is required to 
> >>>> fully document their IP utilization and demonstrate that the 
> >>>> current utilization standard for IPv4 assignments and 
> allocations 
> >>>> is being met. This shall include all currently held IPv4 space, 
> >>>> regardless of origin or registration status.
> >>>
> >>> I like this. It is broadly in line with the NANPA processes for 
> >>> reporting on telephone number utilisation, i.e. there is 
> precedent 
> >>> for this kind of reporting.
> >>>
> >>>> A fee shall be assessed for underutilization or insufficient 
> >>>> documentation.
> >>>
> >>> I'm not sure punitive measures will pass.
> >>>
> >>>>   * The fee for one 12m period shall be waived if the address 
> >>>> holder returns a contiguous block of IPv4 space equal to 
> at least 
> >>>> 1/256th of currently held space and no less than one /24 
> (class C 
> >>>> equivalent) to ARINs free pool.
> >>>>   * The fee for one 12m period shall be waived if the address 
> >>>> holder signs an ARIN RSA for any uncontested and 
> unregistered IPv4 
> >>>> space, this waiver shall be restricted to one use per member 
> >>>> organization.
> >>>
> >>> These points are completely separate from the main point. Also, 
> >>> since ARIN members set the fees, not the policymakers, 
> this detail 
> >>> should not be in a policy proposal.
> >>>
> >>> --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.
> >>
> >> --
> >> 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.
> >>
> >
> >
> >
> > --
> > Chris Grundemann
> > www.chrisgrundemann.com
> > www.linkedin.com/in/cgrundemann
> 
> -- 
> 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.
> 



From jrhett at svcolo.com  Tue Oct 28 23:21:11 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Tue, 28 Oct 2008 20:21:11 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk>
Message-ID: <97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>

I am suggesting that the space gets recovered for reassignment.   This  
is significantly more consequential to people than paying a fee, and  
achieves the original goal of the proposal.

On Oct 28, 2008, at 4:22 PM, Ted Mittelstaedt wrote:
> You CANNOT get people to do anything without a consequence if
> they fail to do it.  If you subtract fees from this embryonic
> proposal, the only thing ARIN has left to compel people to
> document their network is the threat of not allowing them to
> obtain more IPv4 numbering.  A threat that is meaningless unless
> the requestor has need of more IPv4.
>
> And guess what?  Requiring people to document their utilization
> is ALREADY A REQUIREMENT for obtaining additional IPv4!!
>
> Please refrain from re-inventing the wheel.
>
> Ted
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jo Rhett
>> Sent: Tuesday, October 28, 2008 4:09 PM
>> To: Chris Grundemann
>> Cc: ppml at arin.net
>> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
>>
>>
>> Stop at the first paragraph.   Fees won't work.   They will
>> either be
>> protested or people will happily pay them to avoid having to
>> renumber.  And letting organizations return just part of
>> their unused
>> space is a very odd precedent.
>>
>> I would support a proposal based around the first paragraph, without
>> mention of fees or weird "dribble-back" schemes.
>>
>> On Oct 28, 2008, at 3:14 PM, Chris Grundemann wrote:
>>> On Tue, Oct 28, 2008 at 3:57 PM, Jo Rhett <jrhett at svcolo.com> wrote:
>>>> I find myself agreeing with Michael on every point.  The
>> utilization
>>>> documentation is good.  Fees won't work, and the weird policy stuff
>>>> is
>>>> confusing.
>>>
>>> Is it my explanation that is confusing or the policy wording itself?
>>>
>>> I tried to keep the policy itself short and direct:
>>>
>>> Once every 12months each holder of IPv4 addresses is
>> required to fully
>>> document their IP utilization and demonstrate that the current
>>> utilization standard for IPv4 assignments and allocations is being
>>> met. This shall include all currently held IPv4 space,
>> regardless of
>>> origin or registration status.
>>>
>>> A fee shall be assessed for underutilization or insufficient
>>> documentation.
>>>
>>>   * The fee for one 12m period shall be waived if the
>> address holder
>>> returns a contiguous block of IPv4 space equal to at least
>> 1/256th of
>>> currently held space and no less than one /24 (class C
>> equivalent) to
>>> ARINs free pool.
>>>   * The fee for one 12m period shall be waived if the
>> address holder
>>> signs an ARIN RSA for any uncontested and unregistered IPv4 space,
>>> this waiver shall be restricted to one use per member organization.
>>>
>>>
>>>> On Oct 28, 2008, at 4:11 AM, <michael.dillon at bt.com>
>>>> <michael.dillon at bt.com
>>>>> wrote:
>>>>>> Once every 12months each holder of IPv4 addresses is required to
>>>>>> fully document their IP utilization and demonstrate that the
>>>>>> current utilization standard for IPv4 assignments and
>> allocations
>>>>>> is being met. This shall include all currently held IPv4 space,
>>>>>> regardless of origin or registration status.
>>>>>
>>>>> I like this. It is broadly in line with the NANPA processes for
>>>>> reporting on telephone number utilisation, i.e. there is
>> precedent
>>>>> for this kind of reporting.
>>>>>
>>>>>> A fee shall be assessed for underutilization or insufficient
>>>>>> documentation.
>>>>>
>>>>> I'm not sure punitive measures will pass.
>>>>>
>>>>>>  * The fee for one 12m period shall be waived if the address
>>>>>> holder returns a contiguous block of IPv4 space equal to
>> at least
>>>>>> 1/256th of currently held space and no less than one /24
>> (class C
>>>>>> equivalent) to ARINs free pool.
>>>>>>  * The fee for one 12m period shall be waived if the address
>>>>>> holder signs an ARIN RSA for any uncontested and
>> unregistered IPv4
>>>>>> space, this waiver shall be restricted to one use per member
>>>>>> organization.
>>>>>
>>>>> These points are completely separate from the main point. Also,
>>>>> since ARIN members set the fees, not the policymakers,
>> this detail
>>>>> should not be in a policy proposal.
>>>>>
>>>>> --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.
>>>>
>>>> --
>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> Chris Grundemann
>>> www.chrisgrundemann.com
>>> www.linkedin.com/in/cgrundemann
>>
>> -- 
>> 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 cgrundemann at gmail.com  Wed Oct 29 00:15:44 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 Oct 2008 22:15:44 -0600
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk>
	<97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>
Message-ID: <443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>

On Tue, Oct 28, 2008 at 9:21 PM, Jo Rhett <jrhett at svcolo.com> wrote:
> I am suggesting that the space gets recovered for reassignment.   This is
> significantly more consequential to people than paying a fee, and achieves
> the original goal of the proposal.

That is pretty much where I started; either you provide adequate
verifiable documentation of use, or you loose the space.  As I thought
about this though, I came to the conclusion that it would be too harsh
(for lack of a better word at the moment), at least at this point.
With the fear that no-excuses reclamation was too extreme, I
"softened" the penalty to a fee (to be set outside of the policy) and
further, gave a way (two actually) to avoid the fee (and even the
whole documentation process).  This was not intended to complicate the
policy, only to make it reach it's goal in a manner I hoped would be
more palatable (and easier to comply with) by the community as a
whole.

Perhaps there is a way to remove the penalty statement altogether and
still ensure that the policy is actually enforced (somehow)?

>
> --
> Jo Rhett
> senior geek
>
> Silicon Valley Colocation
> Support Phone: 408-400-0550


From cgrundemann at gmail.com  Wed Oct 29 00:55:18 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 Oct 2008 22:55:18 -0600
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <49065B90.8000202@rancid.berkeley.edu>
References: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
	<49065B90.8000202@rancid.berkeley.edu>
Message-ID: <443de7ad0810282155o2f351cb4n55eded034ed09e92@mail.gmail.com>

On Mon, Oct 27, 2008 at 6:23 PM, Michael Sinatra
<michael at rancid.berkeley.edu> wrote:
>
> On 10/27/08 11:52 AM, Chris Grundemann wrote:
>
>> IP space (v4, v6, vX) is a public resource and as such should be borrowed,
>> used and returned by those with a need for it. Think of IPv4 prefixes like
>> library books (another finite public resource): When you check out a book,
>> you are expected to return it on a certain date. If that date comes and
>> you
>> are still actively using the book, you are allowed to state that and keep
>> the book. Since we are at a point now where IPv4 space is recognizably
>> finite, it makes sense to implement a similar policy at the RIR(s) - that
>> is
>> a time frame. This policy would require that after X amount of time, the
>> LIR/EU would need to return to the RIR with justification if they wish to
>> keep the space. The burden should be on the LIR/EU to prove that they are
>> actively using the space.
>
> Just a philosophical question here: The above seems to imply that the
> expected behavior by an organization or service provider who makes the
> transition to IPv6 will eventually be to give back space as part of that
> transition.  Two alternative possibilities exist that I can think of:
>
> 2. [#1 is already listed above] Organizations that transition to IPv6 are
> allowed to keep their IPv4 space (in the absence of a transfer market) as
> they transition away from it.  RIRs become less concerned with IPv4 as IPv6
> takes hold, and eventually all IPv4 holdings become irrelevant.  (I realize
> I am condensing possibly 10-15 years into two sentences.)
>
> 3. Organizations that quickly transition to IPv6 can recoup some of the cost
> of the transition by selling IPv4 addresses in a transfer market. Such a
> market would then provide incentives for transitioning to IPv6 at a certain
> time (i.e. once enough IPv6 services and/or transition mechanisms exist to
> make it feasible, and after IPv4 free-pool runout, but before all of the
> wealthy laggards have transitioned--otherwise there will be no buyers)
> because "early-to-middle adopters" can sell their unused v4 space to wealthy
> late-adopters who need it.  Eventually enough entities will transition and
> start rolling out v6-only services that the laggards will find it in their
> best interests to transition. The market for IPv4 eventually collapses and
> nobody cares.
>
> All three assume a largely successful transition to IPv6.  Outcomes that
> don't assume a successful transition are out of scope of this immediate
> discussion.
>
> I think that my assumption had always been that #2 and #3 were much more
> likely and feasible than #1.  It's not that I am necessarily in favor of a
> market address exchange, but I recognize that it may be a lot more likely to
> just happen than an voluntary return of resources to ARIN. Moreover, once
> IPv4 resources can no longer be monetized because IPv6 is the dominant
> protocol, returning resources to ARIN will be a waste of {ARIN's, the
> member's} time because they will basically be worthless.
>
> I'd like to hear from other folks who think that #1 is a viable option and
> should be pursued, but at this point, I oppose the policy because I think it
> rests on a not-very-likely assumption.

I see three possibilities also, but from a little more basic angle:

1) Organizations will return all unused and/or unneeded IPv4 space to
the RIR as soon as it becomes so.
2) Organizations will only unused and/or unneeded IPv4 space to the
RIR with additional incentive.
3) Organizations will not ever unused and/or unneeded IPv4 space to the RIR.

While #1 is the best for the community as a whole, most have given up
hope that it is possible because it does not seem to be happening now
and as IPv4 becomes more scarce there will be even more resistance,
unfortunatly.  If #3 is the case than there is not much we can do, so
that possibility can probably be ignored when considering policy
changes.  Which leaves us with #2.  Paid transfers are one way to
provide that incentive, I am attempting to create an alternative (or
additional) incentive.  The more tools we have, the

I would say that returning unused and/or unneeded IPv4 space is the
_expected_ behavior from the standpoint that it is what _should_ be
happening but I agree that without additional incentive, it is
(highly) unlikely.

>
> michael
>



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


From michel at arneill-py.sacramento.ca.us  Wed Oct 29 01:27:08 2008
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Tue, 28 Oct 2008 22:27:08 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810282155o2f351cb4n55eded034ed09e92@mail.gmail.com>
References: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com><49065B90.8000202@rancid.berkeley.edu>
	<443de7ad0810282155o2f351cb4n55eded034ed09e92@mail.gmail.com>
Message-ID: <4C1746A1D20C3148B6434776DFFF06C55D31@newserver.arneill-py.local>

> Chris Grundemann wrote:
> I see three possibilities also, but from a little more basic angle:
> 1) Organizations will return all unused and/or unneeded IPv4 space
> to the RIR as soon as it becomes so.

Yeah right.


> 2) Organizations will only {return??} unused and/or unneeded IPv4
> space to the RIR with additional incentive.

How big a carrot? Bigger than 3a below?


> 3) Organizations will not ever unused and/or unneeded IPv4
> space to the RIR.

This serves no practical purpose. What about:

3a) Organizations will not ever {return??} unused and/or unneeded IPv4
space to the RIR because they will use said space to spin off a wholly
owned subsidiary ISP that would use said space to provide IPv4
connectivity to customers who [cough] happen to have cash to pay for it?

Michel.



From craig.finseth at state.mn.us  Wed Oct 29 08:34:37 2008
From: craig.finseth at state.mn.us (Craig Finseth)
Date: Wed, 29 Oct 2008 07:34:37 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <4C1746A1D20C3148B6434776DFFF06C55D31@newserver.arneill-py.local>
	(michel@arneill-py.sacramento.ca.us)
References: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com><49065B90.8000202@rancid.berkeley.edu>
	<443de7ad0810282155o2f351cb4n55eded034ed09e92@mail.gmail.com>
	<4C1746A1D20C3148B6434776DFFF06C55D31@newserver.arneill-py.local>
Message-ID: <200810291234.m9TCYb0v007433@inana.itg.state.mn.us>

	...
   > 3) Organizations will not ever unused and/or unneeded IPv4
   > space to the RIR.

   This serves no practical purpose. What about:

   3a) Organizations will not ever {return??} unused and/or unneeded IPv4
   space to the RIR because they will use said space to spin off a wholly
   owned subsidiary ISP that would use said space to provide IPv4
   connectivity to customers who [cough] happen to have cash to pay for it?
	...

Or, for those that aren't mercenaries:

   3b) Organizations will never return unused space (in a useful timeframe)
   because it costs little to keep it and the risk is that, if you give it
   up, you won't be able to get more.  The latter risk is so high (for
   most organizations) that the cost to keep it would have to be exhorbitantly
   high to offset it.  Once the organization has mostly converted to v6,
   they can get rid of the v4 space, but by then who cares?

Craig

   


From kkargel at polartel.com  Wed Oct 29 09:52:25 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 08:52:25 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>
	<443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>

Rants first, then content.. Top posted because it didn't fit well inline..

What you are proposing could easily turn in to an excessive annual manpower
requirement for an ISP.  It could easily be forgotten or mis-assigned with
terrible consequences.  

We have enough red tape in the IT world already.  Don't create more.

It amazes me how many people feel free to spend my money.  "Do what I want
or I will send you a bill"..  There is nothing wrong with charging for a
service rendered, I don't mind paying for something that I get value from,
but please keep niggling fingers out of my budget.

There is already a requirement to keep contact information updated.  ARIN
can already use existing policy to reclaim abandoned space.  ARIN is very
good at what they do and there are real reasons they have or have not taken
action on these networks.

As I have commented other places, if we want to restrict abandoned or bogon
networks a much better idea would be to publish the contact update date in
the network record.  This data could be used by the publishers of various
bogon lists that the community can take advantage of to prune routing
tables.  If the community is actively concerned ARIN could publish an
"official" bogon list that could be incorporated into routing decisions.
This would actually not hurt the network operators who are legitimately
using stale contact networks for peering connections, and would allow the
community to protect itself from hijackers.  As I think about it I am
surprised there is not an official ARIN bogon list already, it seems like a
natural function.  Maybe it does exist and I am ignorant of it.  Please feel
free to educate me.

This is an issue that would much more ethically be resolved by education and
community action than through punitive regulation. Let's continue to work
cooperatively as a community and avoid as many adversarial policies as
possible. Corporeal punishment is the refuge of the lazy parent.


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann
> Sent: Tuesday, October 28, 2008 11:16 PM
> To: Jo Rhett
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> On Tue, Oct 28, 2008 at 9:21 PM, Jo Rhett <jrhett at svcolo.com> wrote:
> > I am suggesting that the space gets recovered for 
> reassignment.   This is
> > significantly more consequential to people than paying a fee, and 
> > achieves the original goal of the proposal.
> 
> That is pretty much where I started; either you provide 
> adequate verifiable documentation of use, or you loose the 
> space.  As I thought about this though, I came to the 
> conclusion that it would be too harsh (for lack of a better 
> word at the moment), at least at this point.
> With the fear that no-excuses reclamation was too extreme, I 
> "softened" the penalty to a fee (to be set outside of the 
> policy) and further, gave a way (two actually) to avoid the 
> fee (and even the whole documentation process).  This was not 
> intended to complicate the policy, only to make it reach it's 
> goal in a manner I hoped would be more palatable (and easier 
> to comply with) by the community as a whole.
> 
> Perhaps there is a way to remove the penalty statement 
> altogether and still ensure that the policy is actually 
> enforced (somehow)?
> 
> >
> > --
> > 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/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081029/a47a6e71/attachment.bin>

From alan at batie.org  Wed Oct 29 12:54:46 2008
From: alan at batie.org (Alan Batie)
Date: Wed, 29 Oct 2008 09:54:46 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>	<443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
Message-ID: <49089556.5060308@batie.org>

Kevin Kargel wrote:

> This data could be used by the publishers of various
> bogon lists that the community can take advantage of to prune routing
> tables.  If the community is actively concerned ARIN could publish an
> "official" bogon list that could be incorporated into routing decisions.

Just make sure that the list management is responsive to corrections; 
though it looks like there would only be one to worry about with this 
idea, the morass of false positives in the spam blacklist world is 
enough to make one wary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3263 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081029/c865228a/attachment.bin>

From tedm at ipinc.net  Wed Oct 29 13:13:46 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Oct 2008 10:13:46 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
Message-ID: <6D4832AC271A4F7B8C3BD109DE9E0061@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Wednesday, October 29, 2008 6:52 AM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> Rants first, then content.. Top posted because it didn't fit 
> well inline..
> 
> What you are proposing could easily turn in to an excessive 
> annual manpower requirement for an ISP.  It could easily be 
> forgotten or mis-assigned with terrible consequences.  
> 
> We have enough red tape in the IT world already.  Don't create more.
> 
> It amazes me how many people feel free to spend my money.  
> "Do what I want or I will send you a bill"..

And, yet you see nothing hypocritical about your own participation
in a public forum that's intended to create rules that cost other
people money.

When orgs are using numbering on the Internet they are using a
public resource and the public has a right to tell them how to use it.
This is no different than the Law & Order people who tell me
that I can't speed 80Mph on the freeway, even though I know what
I'm doing and could do so safely.

When the day comes that those conservatives let me do what I want
on the freeway then I'll listen to them when they tell me that I
can't force them to accept flag burning as legal.

I disagree with the proposal myself but I am not trying to argue
that the community has no right to institute it if the community
decides it's in the best interest.

> There is 
> nothing wrong with charging for a service rendered, I don't 
> mind paying for something that I get value from, but please 
> keep niggling fingers out of my budget.
> 
> There is already a requirement to keep contact information 
> updated.  ARIN can already use existing policy to reclaim 
> abandoned space.  ARIN is very good at what they do and there 
> are real reasons they have or have not taken action on these networks.
> 
> As I have commented other places, if we want to restrict 
> abandoned or bogon networks a much better idea would be to 
> publish the contact update date in the network record.  This 
> data could be used by the publishers of various bogon lists 
> that the community can take advantage of to prune routing 
> tables.  If the community is actively concerned ARIN could 
> publish an "official" bogon list that could be incorporated 
> into routing decisions. This would actually not hurt the 
> network operators who are legitimately using stale contact 
> networks for peering connections, and would allow the 
> community to protect itself from hijackers.  As I think about 
> it I am surprised there is not an official ARIN bogon list 
> already, it seems like a natural function.  Maybe it does 
> exist and I am ignorant of it.  Please feel free to educate me.
> 

I an concerned that a bogon list is counterproductive,
the point is that when IPv4 runout happens, there will be much incentive
to identify and reclaim abandonded IPv4 space.  If a subnet is
discovered to be hijacked, then instead of listing it on a
bogon list, it should be immediately reclaimed and reassigned.

Creating an official bogon list may hinder the ability of
ISP's to absorb "dirty" subnets.

The situation is the same as when you have a large city (I'll
pick on Detroit for example) that has a core that is rotting
due to abandonded buildings.  The buildings become a mess and
get covered with graffitti.  If the city ignores it, then you
end up with block after block of run-down buildings that attract
more graffitti and vandalism.  It's much better to intitute
recovery proceedings on the land, take it back to public ownership,
and if necessary -GIVE AWAY-
the land if you can't sell it, to a property owner who is willing
to spend the money to go in and gut the building and put
something new there.

Ted



From jrhett at svcolo.com  Wed Oct 29 14:56:31 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 29 Oct 2008 11:56:31 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>
	<443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
Message-ID: <E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>

On Oct 29, 2008, at 6:52 AM, Kevin Kargel wrote:
> What you are proposing could easily turn in to an excessive annual  
> manpower
> requirement for an ISP.  It could easily be forgotten or mis- 
> assigned with
> terrible consequences.

Not unless the ISP throws away the information gained from the  
previous year every time and does it all from scratch.

And I mean seriously, have you ever worked at an ISP that didn't have  
an internal database with information about every single IP  
allocation?  ISPs are going to find this exercise trivial.

> I don't mind paying for something that I get value from,
> but please keep niggling fingers out of my budget.

This is the cost of your IP allocation.  It's actually right there in  
your contract, right now, today.  What is being proposed is simply  
enforcement of those contractual terms.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From sethm at rollernet.us  Wed Oct 29 14:59:25 2008
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 29 Oct 2008 11:59:25 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>
	<443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
	<E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>
Message-ID: <4908B28D.2050604@rollernet.us>

Jo Rhett wrote:
> On Oct 29, 2008, at 6:52 AM, Kevin Kargel wrote:
>> What you are proposing could easily turn in to an excessive annual  
>> manpower
>> requirement for an ISP.  It could easily be forgotten or mis- 
>> assigned with
>> terrible consequences.
> 
> Not unless the ISP throws away the information gained from the  
> previous year every time and does it all from scratch.
> 
> And I mean seriously, have you ever worked at an ISP that didn't have  
> an internal database with information about every single IP  
> allocation?  ISPs are going to find this exercise trivial.

I have. I once spent about 2 months getting all of their swips in order. 
The only documentation was comments in zone files. I think they just 
deleted all the swips later or something.

It's unlikely, but not impossible.

~Seth


From kkargel at polartel.com  Wed Oct 29 14:59:50 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 13:59:50 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <6D4832AC271A4F7B8C3BD109DE9E0061@tedsdesk>
References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
	<6D4832AC271A4F7B8C3BD109DE9E0061@tedsdesk>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB1D@mail>

 

> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] 
> Sent: Wednesday, October 29, 2008 12:14 PM
> To: Kevin Kargel; ppml at arin.net
> Subject: RE: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> > Sent: Wednesday, October 29, 2008 6:52 AM
> > To: ppml at arin.net
> > Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> > 
> > 
> > Rants first, then content.. Top posted because it didn't fit well 
> > inline..
> > 
> > What you are proposing could easily turn in to an excessive annual 
> > manpower requirement for an ISP.  It could easily be forgotten or 
> > mis-assigned with terrible consequences.
> > 
> > We have enough red tape in the IT world already.  Don't create more.
> > 
> > It amazes me how many people feel free to spend my money.  
> > "Do what I want or I will send you a bill"..
> 
> And, yet you see nothing hypocritical about your own 
> participation in a public forum that's intended to create 
> rules that cost other people money.

I see absolutely nothing hypocritical..  I see part of my role as advocate
for others like me to watchdog excessive rules and unecessary fees..  This
is how our community works.. I also do not accept that the purpose of this
forum is to make rules that cost money, that is rather disengenious..

The purpose of this forum is information exchange, and to provide a venue
where the community can work cooperatively for the betterment of the
community.  Another of my favorite rants you have heard many times --
"Cooperative Anarchy Works!"
 
Followed closely by--  "Evil Thrives When Good People Do Nothing"

> 
> When orgs are using numbering on the Internet they are using 
> a public resource and the public has a right to tell them how 
> to use it.
> This is no different than the Law & Order people who tell me 
> that I can't speed 80Mph on the freeway, even though I know 
> what I'm doing and could do so safely.

Umm, I am a member of ARIN, ARIN *is* the public..  This is a cooperative
effort, not a government..  ARIN cannot throw you in jail, ARIN does not
regulate your morality.  Following ARIN's rules is a behavior you choose
because it works better than the alternative.  Following governmental laws
is a behavior that is forced upon you.  If you choose not to follow
Government Laws you will eventually be removed from society.  While there
are limited corralaries there is a *huge* difference between the two..  

> 
> When the day comes that those conservatives let me do what I 
> want on the freeway then I'll listen to them when they tell 
> me that I can't force them to accept flag burning as legal.
> 
> I disagree with the proposal myself but I am not trying to 
> argue that the community has no right to institute it if the 
> community decides it's in the best interest.

The "Community" has every right to agree on rules and behaviors..  This is
the very basis of the concept of cooperative anarchy that has so far let the
internet function as well as it has..  

> 
> > There is
> > nothing wrong with charging for a service rendered, I don't mind 
> > paying for something that I get value from, but please keep 
> niggling 
> > fingers out of my budget.
> > 
> > There is already a requirement to keep contact information 
> updated.  
> > ARIN can already use existing policy to reclaim abandoned 
> space.  ARIN 
> > is very good at what they do and there are real reasons 
> they have or 
> > have not taken action on these networks.
> > 
> > As I have commented other places, if we want to restrict 
> abandoned or 
> > bogon networks a much better idea would be to publish the contact 
> > update date in the network record.  This data could be used by the 
> > publishers of various bogon lists that the community can take 
> > advantage of to prune routing tables.  If the community is actively 
> > concerned ARIN could publish an "official" bogon list that could be 
> > incorporated into routing decisions. This would actually 
> not hurt the 
> > network operators who are legitimately using stale contact networks 
> > for peering connections, and would allow the community to protect 
> > itself from hijackers.  As I think about it I am surprised there is 
> > not an official ARIN bogon list already, it seems like a natural 
> > function.  Maybe it does exist and I am ignorant of it.  
> Please feel 
> > free to educate me.
> > 
> 
> I an concerned that a bogon list is counterproductive, the 
> point is that when IPv4 runout happens, there will be much 
> incentive to identify and reclaim abandonded IPv4 space.  If 
> a subnet is discovered to be hijacked, then instead of 
> listing it on a bogon list, it should be immediately 
> reclaimed and reassigned.

You don't think it would be productive to have some mechanism in place to
restrict functionality of bogon networks in the period between reclamation
and reassignment?  I suspect that the norm for that transition will take
some period of time..  Not all unassigned space is issued the moment it is
available.  At this moment I believe there is considerable unassigned space
that doesn't need to be in our routing tables.

> 
> Creating an official bogon list may hinder the ability of 
> ISP's to absorb "dirty" subnets.

> 
> The situation is the same as when you have a large city (I'll 
> pick on Detroit for example) that has a core that is rotting 
> due to abandonded buildings.  The buildings become a mess and 
> get covered with graffitti.  If the city ignores it, then you 
> end up with block after block of run-down buildings that 
> attract more graffitti and vandalism.  It's much better to 
> intitute recovery proceedings on the land, take it back to 
> public ownership, and if necessary -GIVE AWAY- the land if 
> you can't sell it, to a property owner who is willing to 
> spend the money to go in and gut the building and put 
> something new there.

Ah, but wouldn't a bogon list of bad routables be similar to the city roping
off the slum section and putting up No Trespass signs while they tear down
the old stuff (reclamation) in preperation to selling or giving it away?
This would tend to (not absolutely I agree) protect ordinary citizens by
making it inconvenient to travel in that area.  Nothing is saying some
ne-er-do-wells aren't going to ignore the signs and go there anyway
(possibly even squat there), but it would keep the majority of decent folk
out and seperated..


 
> 
> Ted
> 
> 
-------------- 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/20081029/a74284ff/attachment.bin>

From tedm at ipinc.net  Wed Oct 29 15:11:18 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Oct 2008 12:11:18 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>
Message-ID: <6C20698679C7424583370862390DBD47@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jo Rhett
> Sent: Wednesday, October 29, 2008 11:57 AM
> To: Kevin Kargel
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 

> 
> This is the cost of your IP allocation.  It's actually right 
> there in  
> your contract, right now, today.  What is being proposed is simply  
> enforcement of those contractual terms.
> 

Not unless there is a financial penalty for not doing it.  No penalty,
no enforcement.

Ted



From kkargel at polartel.com  Wed Oct 29 15:19:24 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 14:19:24 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <49089556.5060308@batie.org>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>	<443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
	<49089556.5060308@batie.org>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB20@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alan Batie
> Sent: Wednesday, October 29, 2008 11:55 AM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> Kevin Kargel wrote:
> 
> > This data could be used by the publishers of various bogon 
> lists that 
> > the community can take advantage of to prune routing 
> tables.  If the 
> > community is actively concerned ARIN could publish an 
> "official" bogon 
> > list that could be incorporated into routing decisions.
> 
> Just make sure that the list management is responsive to 
> corrections; though it looks like there would only be one to 
> worry about with this idea, the morass of false positives in 
> the spam blacklist world is enough to make one wary.
> 

Yes, but in this case the maintainer is the same as the generator and the
inputer.  This would be closed loop as opposed to the open loop of email
RBL's..  ARIN would be evaluating their own data..  Not taking in data from
end users..  

The ARIN bogon list would just be (!allocated) ..  Or allocated not..
However your prefer to perceive it..  The likelihood of success and accuracy
are much greater than when trying to act on the evalutaions of end users. 
-------------- 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/20081029/94092963/attachment.bin>

From kkargel at polartel.com  Wed Oct 29 15:33:36 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 14:33:36 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>
	<443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
	<E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB23@mail>

 

> -----Original Message-----
> From: Jo Rhett [mailto:jrhett at svcolo.com] 
> Sent: Wednesday, October 29, 2008 1:57 PM
> To: Kevin Kargel
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> On Oct 29, 2008, at 6:52 AM, Kevin Kargel wrote:
> > What you are proposing could easily turn in to an excessive annual 
> > manpower requirement for an ISP.  It could easily be 
> forgotten or mis- 
> > assigned with terrible consequences.
> 
> Not unless the ISP throws away the information gained from 
> the previous year every time and does it all from scratch.
> 
> And I mean seriously, have you ever worked at an ISP that 
> didn't have an internal database with information about every 
> single IP allocation?  ISPs are going to find this exercise trivial.

Have you ever looked in an ISP's database and found inaccuracies or
mistakes?  Do you know of ANY database ANYWHERE that is 100% accurate or
100% up to date?  ISP's are going to find this exersice trivial as long as
they treat it like a paperwork function and fill in the blocks with right
looking numbers to get it over with.  (hmm, does that sound like what people
do now for justifications?)  If it is a matter of just filling out forms for
the sake of filling out forms then I suggest that the whole exercise is just
busywork.  I have enough of that already.  
> 
> > I don't mind paying for something that I get value from, but please 
> > keep niggling fingers out of my budget.
> 
> This is the cost of your IP allocation.  It's actually right 
> there in your contract, right now, today.  What is being 
> proposed is simply enforcement of those contractual terms.

I already have a cost for my IP allocation..  What I am hearing proposed is
a fine (since when did ARIN have authority to assess fines?) if I don't
complete my paperwork to meet some administrators approval.  I do not need a
sword of extra fees hanging over my head and I suspect you don't either.

> 
> -- 
> Jo Rhett
> senior geek
> 
> Silicon Valley Colocation
> Support Phone: 408-400-0550
> 
> 
> 
> 
> 
-------------- 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/20081029/b49fc9ea/attachment.bin>

From tedm at ipinc.net  Wed Oct 29 15:46:20 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Oct 2008 12:46:20 -0700
Subject: [arin-ppml] The problem with IPv4 bogon and listing them
Message-ID: <6A1B0F74F28C481A90C2C97C1C36509D@tedsdesk>


Kevin, let's talk about bogons.  We have Cymru running their list here:

http://www.cymru.com/Documents/bogon-list.html

but, I'll quote from the text on the list:

"...IANA allocations change over time, so please check back regularly to
ensure you have the latest filters. I can not stress this point strongly
enough - these allocations change, as often as every four months...."

Checking back every 4 MONTHS?  So that
means if I request IPv4 that's dirty, on this list, and I get it, that I
have to wait
4 months before using it?  And that's just for the people out there who are
following
the recommendation.

People are generating router ACL's from this list, and NOT updating them in
any timely 4 month intervals.  Consider that it might take a couple YEARS
from delisting on this list for the subnets to be usable.

It would be very foolish in my opinion to place IPv4 that is returned from
orgs who have been using it, on to this list.  Frankly, ARIN should be
working through this list right NOW and identifying if any subnets on it
are theirs, and taking steps to recover those subnets and place them back
into the free pool.  

Ted



From jrhett at svcolo.com  Wed Oct 29 15:50:21 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 29 Oct 2008 12:50:21 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <4908B28D.2050604@rollernet.us>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>
	<443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
	<E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>
	<4908B28D.2050604@rollernet.us>
Message-ID: <A3DF9149-1039-4BB7-9CE3-F700EDF243BA@svcolo.com>

On Oct 29, 2008, at 11:59 AM, Seth Mattinen wrote:
>> And I mean seriously, have you ever worked at an ISP that didn't have
>> an internal database with information about every single IP
>> allocation?  ISPs are going to find this exercise trivial.
>
> I have. I once spent about 2 months getting all of their swips in  
> order.
> The only documentation was comments in zone files. I think they just
> deleted all the swips later or something.


Yeah, obviously we have all been hired to resolve that problem from  
time to time. But that is why we were hired, right?  And if we did it  
once for them, they wouldn't be starting from scratch next year.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Wed Oct 29 15:52:28 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 29 Oct 2008 12:52:28 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <6C20698679C7424583370862390DBD47@tedsdesk>
References: <6C20698679C7424583370862390DBD47@tedsdesk>
Message-ID: <619E0677-69C0-4F19-A1F1-953AD27072EF@svcolo.com>

On Oct 29, 2008, at 12:11 PM, Ted Mittelstaedt wrote:
>> This is the cost of your IP allocation.  It's actually right
>> there in
>> your contract, right now, today.  What is being proposed is simply
>> enforcement of those contractual terms.
>
> Not unless there is a financial penalty for not doing it.  No penalty,
> no enforcement.


Recovery of the space is the enforcement. This is the useful and  
practical solution.

If you were to fine me for non-compliance I'd happy pay the fine and  
ignore you ;-)  Taking back the IP space would be effective.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From jrhett at svcolo.com  Wed Oct 29 15:55:08 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 29 Oct 2008 12:55:08 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB23@mail>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>
	<443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
	<E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB23@mail>
Message-ID: <B48B1598-90E3-4AC1-A72C-64E5D9AFF37C@svcolo.com>

On Oct 29, 2008, at 12:33 PM, Kevin Kargel wrote:
> Have you ever looked in an ISP's database and found inaccuracies or
> mistakes?  Do you know of ANY database ANYWHERE that is 100%  
> accurate or
> 100% up to date?  ISP's are going to find this exersice trivial as  
> long as

I see no reason for ARIN policy to make exceptions for the  
inaccuracies in a given ISP's database.  This is not my problem, nor  
ARIN's problem.

>> This is the cost of your IP allocation.  It's actually right
>> there in your contract, right now, today.  What is being
>> proposed is simply enforcement of those contractual terms.
>
> I already have a cost for my IP allocation..  What I am hearing  
> proposed is
> a fine (since when did ARIN have authority to assess fines?) if I  
> don't
> complete my paperwork to meet some administrators approval.  I do  
> not need a
> sword of extra fees hanging over my head and I suspect you don't  
> either.


Ha.  I'd pay the fine and ignore ARIN ;-)  I've been saying that fines  
won't work, and we don't have it in our contract to take them.  We  
should recover the unjustified space.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From tedm at ipinc.net  Wed Oct 29 15:55:34 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Oct 2008 12:55:34 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <619E0677-69C0-4F19-A1F1-953AD27072EF@svcolo.com>
Message-ID: <7DB313DA72D349C7BB938DA46BEF022E@tedsdesk>



> -----Original Message-----
> From: Jo Rhett [mailto:jrhett at svcolo.com] 
> Sent: Wednesday, October 29, 2008 12:52 PM
> To: Ted Mittelstaedt
> Cc: 'Kevin Kargel'; ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> On Oct 29, 2008, at 12:11 PM, Ted Mittelstaedt wrote:
> >> This is the cost of your IP allocation.  It's actually 
> right there in
> >> your contract, right now, today.  What is being proposed is simply
> >> enforcement of those contractual terms.
> >
> > Not unless there is a financial penalty for not doing it.  
> No penalty, 
> > no enforcement.
> 
> 
> Recovery of the space is the enforcement. This is the useful and  
> practical solution.
> 
> If you were to fine me for non-compliance I'd happy pay the fine and  
> ignore you ;-)

And I'd be happy to allow you to keep the space and pay the
$1,000,000.00 USD fine every year. ;-)

Ted



From jrhett at svcolo.com  Wed Oct 29 15:56:46 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 29 Oct 2008 12:56:46 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <7DB313DA72D349C7BB938DA46BEF022E@tedsdesk>
References: <7DB313DA72D349C7BB938DA46BEF022E@tedsdesk>
Message-ID: <2AF2A084-347B-4E7F-A3F1-1239989744ED@svcolo.com>

On Oct 29, 2008, at 12:55 PM, Ted Mittelstaedt wrote:
> And I'd be happy to allow you to keep the space and pay the
> $1,000,000.00 USD fine every year. ;-)


Show me where in the RSA it gives ARIN the right to fine me.

They have the right and the clear authority to recover the space.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550






From kkargel at polartel.com  Wed Oct 29 15:57:37 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 14:57:37 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <7DB313DA72D349C7BB938DA46BEF022E@tedsdesk>
References: <619E0677-69C0-4F19-A1F1-953AD27072EF@svcolo.com>
	<7DB313DA72D349C7BB938DA46BEF022E@tedsdesk>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB25@mail>

 

> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] 
> Sent: Wednesday, October 29, 2008 2:56 PM
> To: 'Jo Rhett'
> Cc: Kevin Kargel; ppml at arin.net
> Subject: RE: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> 
> > -----Original Message-----
> > From: Jo Rhett [mailto:jrhett at svcolo.com]
> > Sent: Wednesday, October 29, 2008 12:52 PM
> > To: Ted Mittelstaedt
> > Cc: 'Kevin Kargel'; ppml at arin.net
> > Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> > 
> > 
> > On Oct 29, 2008, at 12:11 PM, Ted Mittelstaedt wrote:
> > >> This is the cost of your IP allocation.  It's actually
> > right there in
> > >> your contract, right now, today.  What is being proposed 
> is simply 
> > >> enforcement of those contractual terms.
> > >
> > > Not unless there is a financial penalty for not doing it.  
> > No penalty,
> > > no enforcement.
> > 
> > 
> > Recovery of the space is the enforcement. This is the useful and 
> > practical solution.
> > 
> > If you were to fine me for non-compliance I'd happy pay the 
> fine and 
> > ignore you ;-)
> 
> And I'd be happy to allow you to keep the space and pay the 
> $1,000,000.00 USD fine every year. ;-)
> 
> Ted
> 
> 
Of course this is all assuming the authority to assess fines in the first
place.  You (should) have a contract and an agreement with ARIN.  You are
not subject to ARIN.  
-------------- 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/20081029/ebaef37d/attachment.bin>

From tedm at ipinc.net  Wed Oct 29 16:05:12 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Oct 2008 13:05:12 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <B48B1598-90E3-4AC1-A72C-64E5D9AFF37C@svcolo.com>
Message-ID: <C8FE594BAF9C4E46984421ACCEADDAE7@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jo Rhett
> Sent: Wednesday, October 29, 2008 12:55 PM
> To: Kevin Kargel
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> On Oct 29, 2008, at 12:33 PM, Kevin Kargel wrote:
> > Have you ever looked in an ISP's database and found inaccuracies or 
> > mistakes?  Do you know of ANY database ANYWHERE that is 100%
> > accurate or
> > 100% up to date?  ISP's are going to find this exersice trivial as  
> > long as
> 
> I see no reason for ARIN policy to make exceptions for the  
> inaccuracies in a given ISP's database.  This is not my problem, nor  
> ARIN's problem.
> 
> >> This is the cost of your IP allocation.  It's actually 
> right there in 
> >> your contract, right now, today.  What is being proposed is simply 
> >> enforcement of those contractual terms.
> >
> > I already have a cost for my IP allocation..  What I am hearing
> > proposed is
> > a fine (since when did ARIN have authority to assess fines?) if I  
> > don't
> > complete my paperwork to meet some administrators approval.  I do  
> > not need a
> > sword of extra fees hanging over my head and I suspect you don't  
> > either.
> 
> 
> Ha.  I'd pay the fine and ignore ARIN ;-)  I've been saying 
> that fines  
> won't work, and we don't have it in our contract to take them.  We  
> should recover the unjustified space.
> 

How do you recover space when the org advertising it does not want to
give it up?

Fact is, I was rather curious myself about these situations
so when we got our portable allocation years ago I kept advertising a /23
from one
of our old blocks after renumbering out of it just to see what would happen.
About a year later the block was finally assigned.  Trust me, if I had
wanted to be a jerk about it, it would have gotten pretty bad for the
org that got the numbers.

Ted



From kkargel at polartel.com  Wed Oct 29 16:05:55 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 15:05:55 -0500
Subject: [arin-ppml] The problem with IPv4 bogon and listing them
In-Reply-To: <6A1B0F74F28C481A90C2C97C1C36509D@tedsdesk>
References: <6A1B0F74F28C481A90C2C97C1C36509D@tedsdesk>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB26@mail>


> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] 
> Sent: Wednesday, October 29, 2008 2:46 PM
> To: ppml at arin.net
> Cc: Kevin Kargel
> Subject: The problem with IPv4 bogon and listing them
> 
> 
> Kevin, let's talk about bogons.  We have Cymru running their 
> list here:
> 
> http://www.cymru.com/Documents/bogon-list.html
> 
> but, I'll quote from the text on the list:
> 
> "...IANA allocations change over time, so please check back 
> regularly to ensure you have the latest filters. I can not 
> stress this point strongly enough - these allocations change, 
> as often as every four months...."
> 
> Checking back every 4 MONTHS?  So that
> means if I request IPv4 that's dirty, on this list, and I get 
> it, that I have to wait
> 4 months before using it?  And that's just for the people out 
> there who are following the recommendation.
> 
> People are generating router ACL's from this list, and NOT 
> updating them in any timely 4 month intervals.  Consider that 
> it might take a couple YEARS from delisting on this list for 
> the subnets to be usable.
> 
> It would be very foolish in my opinion to place IPv4 that is 
> returned from orgs who have been using it, on to this list.  
> Frankly, ARIN should be working through this list right NOW 
> and identifying if any subnets on it are theirs, and taking 
> steps to recover those subnets and place them back into the 
> free pool.  
> 
> Ted
> 
> 

Ted,

I agree with all of your points in this message. Actually in fact, we are
more in line than recent missives would indicate.

I do, however, stipulate that the downsides are mitigated if it is ARIN that
is running the bogon list, as accuracy and timeliness would be vastly
improved.  Also with ARIN running the list it could relatively easily be
tied in to ARIN WHOIS, making automation of the routing declinations
possible.  

I agree that without much closer interwork between ARIN and CYMRU that blind
adoption of the CYMRU list would be foolhardy.  As it stands it is a great
reference, but not a great authoritative reference.

If money is needed to fund an ARIN bogon effort it could easily be offered
as a subscription service.  I would happily pay a reasonable fee.


 
-------------- 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/20081029/bd14ccb0/attachment.bin>

From tedm at ipinc.net  Wed Oct 29 16:08:38 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Oct 2008 13:08:38 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <2AF2A084-347B-4E7F-A3F1-1239989744ED@svcolo.com>
Message-ID: <FC852A9FA1AA4CC08E8238B5D09E5179@tedsdesk>



> -----Original Message-----
> From: Jo Rhett [mailto:jrhett at svcolo.com] 
> Sent: Wednesday, October 29, 2008 12:57 PM
> To: Ted Mittelstaedt
> Cc: 'Kevin Kargel'; ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> On Oct 29, 2008, at 12:55 PM, Ted Mittelstaedt wrote:
> > And I'd be happy to allow you to keep the space and pay the 
> > $1,000,000.00 USD fine every year. ;-)
> 
> 
> Show me where in the RSA it gives ARIN the right to fine me.
> 

The proposal from Chris was to institute fines, a fine would be a 
modification of the NPRM which you are subject to.

Ted



From kkargel at polartel.com  Wed Oct 29 16:11:28 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 15:11:28 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <C8FE594BAF9C4E46984421ACCEADDAE7@tedsdesk>
References: <B48B1598-90E3-4AC1-A72C-64E5D9AFF37C@svcolo.com>
	<C8FE594BAF9C4E46984421ACCEADDAE7@tedsdesk>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB28@mail>

<big snip>
> 
> Fact is, I was rather curious myself about these situations 
> so when we got our portable allocation years ago I kept 
> advertising a /23 from one of our old blocks after 
> renumbering out of it just to see what would happen.
> About a year later the block was finally assigned.  Trust me, 
> if I had wanted to be a jerk about it, it would have gotten 
> pretty bad for the org that got the numbers.
> 
> Ted
> 
> 
This precisely illustrates the "cooperative" part of "cooperative anarchy".
If the world prefers to accept your advertisements over the recommendations
of ARIN or any other authority there is nothing stopping that from
happening, aside from the fact that it will be problematic and less than
wonderfully functional.  

I suspect that if it started creating problems and people started making a
noise that your peers would have stopped accepting your advertisements.  You
can shout whatever network you want as loud as you want, but if nobody
listens it isn't going far.  With your credibility to your peers damaged
they may look askance at the rest of your operation and treat everything you
do as questionable.
-------------- 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/20081029/b0498c15/attachment.bin>

From kkargel at polartel.com  Wed Oct 29 16:13:22 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 15:13:22 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <FC852A9FA1AA4CC08E8238B5D09E5179@tedsdesk>
References: <2AF2A084-347B-4E7F-A3F1-1239989744ED@svcolo.com>
	<FC852A9FA1AA4CC08E8238B5D09E5179@tedsdesk>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB29@mail>

> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] 
> Sent: Wednesday, October 29, 2008 3:09 PM
> To: 'Jo Rhett'
> Cc: Kevin Kargel; ppml at arin.net
> Subject: RE: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> 
> > -----Original Message-----
> > From: Jo Rhett [mailto:jrhett at svcolo.com]
> > Sent: Wednesday, October 29, 2008 12:57 PM
> > To: Ted Mittelstaedt
> > Cc: 'Kevin Kargel'; ppml at arin.net
> > Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> > 
> > 
> > On Oct 29, 2008, at 12:55 PM, Ted Mittelstaedt wrote:
> > > And I'd be happy to allow you to keep the space and pay the 
> > > $1,000,000.00 USD fine every year. ;-)
> > 
> > 
> > Show me where in the RSA it gives ARIN the right to fine me.
> > 
> 
> The proposal from Chris was to institute fines, a fine would 
> be a modification of the NPRM which you are subject to.
> 
> Ted
> 
> 
Hmm..  How many of you out there would be willing to sign a document with a
provider that allowed them to charge you unlimited monies at their
discretion?  How do you fit that in to your operating budget?
-------------- 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/20081029/d59af4d9/attachment.bin>

From tedm at ipinc.net  Wed Oct 29 16:14:16 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Oct 2008 13:14:16 -0700
Subject: [arin-ppml] The problem with IPv4 bogon and listing them
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB26@mail>
Message-ID: <B1F0968B2C874055B5C966E6BEDEF874@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Wednesday, October 29, 2008 1:06 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] The problem with IPv4 bogon and listing them
> 
> 
> 
> > -----Original Message-----
> > From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
> > Sent: Wednesday, October 29, 2008 2:46 PM
> > To: ppml at arin.net
> > Cc: Kevin Kargel
> > Subject: The problem with IPv4 bogon and listing them
> > 
> > 
> > Kevin, let's talk about bogons.  We have Cymru running their
> > list here:
> > 
> > http://www.cymru.com/Documents/bogon-list.html
> > 
> > but, I'll quote from the text on the list:
> > 
> > "...IANA allocations change over time, so please check back
> > regularly to ensure you have the latest filters. I can not 
> > stress this point strongly enough - these allocations change, 
> > as often as every four months...."
> > 
> > Checking back every 4 MONTHS?  So that
> > means if I request IPv4 that's dirty, on this list, and I get
> > it, that I have to wait
> > 4 months before using it?  And that's just for the people out 
> > there who are following the recommendation.
> > 
> > People are generating router ACL's from this list, and NOT
> > updating them in any timely 4 month intervals.  Consider that 
> > it might take a couple YEARS from delisting on this list for 
> > the subnets to be usable.
> > 
> > It would be very foolish in my opinion to place IPv4 that is
> > returned from orgs who have been using it, on to this list.  
> > Frankly, ARIN should be working through this list right NOW 
> > and identifying if any subnets on it are theirs, and taking 
> > steps to recover those subnets and place them back into the 
> > free pool.  
> > 
> > Ted
> > 
> > 
> 
> Ted,
> 
> I agree with all of your points in this message. Actually in 
> fact, we are more in line than recent missives would indicate.
> 
> I do, however, stipulate that the downsides are mitigated if 
> it is ARIN that is running the bogon list, as accuracy and 
> timeliness would be vastly improved.  Also with ARIN running 
> the list it could relatively easily be tied in to ARIN WHOIS, 
> making automation of the routing declinations possible.  
> 

Very good.

> I agree that without much closer interwork between ARIN and 
> CYMRU that blind adoption of the CYMRU list would be 
> foolhardy.  As it stands it is a great reference, but not a 
> great authoritative reference.
> 
> If money is needed to fund an ARIN bogon effort it could 
> easily be offered as a subscription service.  I would happily 
> pay a reasonable fee.
> 

I don't see that yet another fee is necessary here.  ARIN
already has a database - whois.  An effort really needs to be
made to get the number blocks listed in whois to align with what
is actually assigned, don't you think?  Whois should not list
network entries for blocks that are in the free pool, and
there should not be assigned blocks that lack an entry in
whois.

Ideally, a bogon list should be able to be generated by running
a query that iterates through every /24 in the IP numberspace
and queries it against the whois database, and the list would
be all queries that return "no object found"

Ted



From tedm at ipinc.net  Wed Oct 29 16:27:06 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Oct 2008 13:27:06 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB29@mail>
Message-ID: <F36493E8C1F14C0DA9EED225B716729E@tedsdesk>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Wednesday, October 29, 2008 1:13 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> > -----Original Message-----
> > From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
> > Sent: Wednesday, October 29, 2008 3:09 PM
> > To: 'Jo Rhett'
> > Cc: Kevin Kargel; ppml at arin.net
> > Subject: RE: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Jo Rhett [mailto:jrhett at svcolo.com]
> > > Sent: Wednesday, October 29, 2008 12:57 PM
> > > To: Ted Mittelstaedt
> > > Cc: 'Kevin Kargel'; ppml at arin.net
> > > Subject: Re: [arin-ppml] The Library Book Approach to 
> IPv4 Scarcity
> > > 
> > > 
> > > On Oct 29, 2008, at 12:55 PM, Ted Mittelstaedt wrote:
> > > > And I'd be happy to allow you to keep the space and pay the
> > > > $1,000,000.00 USD fine every year. ;-)
> > > 
> > > 
> > > Show me where in the RSA it gives ARIN the right to fine me.
> > > 
> > 
> > The proposal from Chris was to institute fines, a fine would
> > be a modification of the NPRM which you are subject to.
> > 
> > Ted
> > 
> > 
> Hmm..  How many of you out there would be willing to sign a 
> document with a provider that allowed them to charge you 
> unlimited monies at their discretion?  How do you fit that in 
> to your operating budget?
> 

Oh, you mean like the agreement I have with my water/natural gas/
electric/cable/satellite/cell phone/etc/etc/etc/etc  company? ;-)

The One Million Dollars figure was to illustrate the fallacy
of claiming that fines are irrelevant, as well as a joke that 
you probably would have missed unless you saw the movie Austin
Powers.    There's only 1 kind of fine that is irrelevant and
that is a fine that is set too low.

Presumably, anyone setting up a fine schedule would be smart
enough to understand this and set the fines accordingly.  I suppose
I could have just said this, but where's the fun in that?

Understand of course that I don't support the proposal AT ALL but
I am not going to resist pointing out logical fallacies in
arguments against it - that DOES NOT mean I'm defending it!

Ted



From kkargel at polartel.com  Wed Oct 29 16:28:41 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 15:28:41 -0500
Subject: [arin-ppml] The problem with IPv4 bogon and listing them
In-Reply-To: <B1F0968B2C874055B5C966E6BEDEF874@tedsdesk>
References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB26@mail>
	<B1F0968B2C874055B5C966E6BEDEF874@tedsdesk>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB2A@mail>

<Another tersing snip>

> > 
> > Ted,
> > 
> > I agree with all of your points in this message. Actually in 
> > fact, we are more in line than recent missives would indicate.
> > 
> > I do, however, stipulate that the downsides are mitigated if 
> > it is ARIN that is running the bogon list, as accuracy and 
> > timeliness would be vastly improved.  Also with ARIN running 
> > the list it could relatively easily be tied in to ARIN WHOIS, 
> > making automation of the routing declinations possible.  
> > 
> 
> Very good.
> 
> > I agree that without much closer interwork between ARIN and 
> > CYMRU that blind adoption of the CYMRU list would be 
> > foolhardy.  As it stands it is a great reference, but not a 
> > great authoritative reference.
> > 
> > If money is needed to fund an ARIN bogon effort it could 
> > easily be offered as a subscription service.  I would happily 
> > pay a reasonable fee.
> > 
> 
> I don't see that yet another fee is necessary here.  ARIN
> already has a database - whois.  An effort really needs to be
> made to get the number blocks listed in whois to align with what
> is actually assigned, don't you think?  Whois should not list
> network entries for blocks that are in the free pool, and
> there should not be assigned blocks that lack an entry in
> whois.

Hmm..  I'll have to think about this one..  On the surface filtering WHOIS
to function also as (not)bogon sounds like a great idea.  Starting with
Bogon(not) is much more functional than reducing the database (world) by the
contents of (bogon).

Ties to BGP should be relatively easy, and application in IPv6 would be
natural.

The fly in the ointment is that if this becomes popular the WHOIS becomes
incredibly busy.  Lots of people querying for every subnet in the world.
Publishing the result would be much more efficient.  A simple solution would
be if ARIN made available canned ACL's for the most popular routers on
secure tftp (HA!) servers that routers could suck to update on a regular
basis.  Or these could be sucked by admins, parsed to their whims (or for
oddball routers) and pushed to the edge.

> 
> Ideally, a bogon list should be able to be generated by running
> a query that iterates through every /24 in the IP numberspace
> and queries it against the whois database, and the list would
> be all queries that return "no object found"
> 
> Ted
> 
> 
-------------- 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/20081029/219b7f0d/attachment.bin>

From kkargel at polartel.com  Wed Oct 29 16:39:08 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 15:39:08 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <F36493E8C1F14C0DA9EED225B716729E@tedsdesk>
References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB29@mail>
	<F36493E8C1F14C0DA9EED225B716729E@tedsdesk>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB2B@mail>

 

> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] 
> Sent: Wednesday, October 29, 2008 3:27 PM
> To: Kevin Kargel; ppml at arin.net
> Subject: RE: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> > Sent: Wednesday, October 29, 2008 1:13 PM
> > To: ppml at arin.net
> > Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> > 
> > 
> > > -----Original Message-----
> > > From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
> > > Sent: Wednesday, October 29, 2008 3:09 PM
> > > To: 'Jo Rhett'
> > > Cc: Kevin Kargel; ppml at arin.net
> > > Subject: RE: [arin-ppml] The Library Book Approach to 
> IPv4 Scarcity
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jo Rhett [mailto:jrhett at svcolo.com]
> > > > Sent: Wednesday, October 29, 2008 12:57 PM
> > > > To: Ted Mittelstaedt
> > > > Cc: 'Kevin Kargel'; ppml at arin.net
> > > > Subject: Re: [arin-ppml] The Library Book Approach to
> > IPv4 Scarcity
> > > > 
> > > > 
> > > > On Oct 29, 2008, at 12:55 PM, Ted Mittelstaedt wrote:
> > > > > And I'd be happy to allow you to keep the space and pay the 
> > > > > $1,000,000.00 USD fine every year. ;-)
> > > > 
> > > > 
> > > > Show me where in the RSA it gives ARIN the right to fine me.
> > > > 
> > > 
> > > The proposal from Chris was to institute fines, a fine would be a 
> > > modification of the NPRM which you are subject to.
> > > 
> > > Ted
> > > 
> > > 
> > Hmm..  How many of you out there would be willing to sign a 
> document 
> > with a provider that allowed them to charge you unlimited monies at 
> > their discretion?  How do you fit that in to your operating budget?
> > 
> 
> Oh, you mean like the agreement I have with my water/natural 
> gas/ electric/cable/satellite/cell phone/etc/etc/etc/etc  company? ;-)

Sorta, but on those your costs are limited by your consumption.  Your
utility companies don't assess fines if you don't reaffirm your address on a
regular basis.  Even my cel company doesn't assess fines if I don't answer
their calls or respond to their voicemails.

> 
> The One Million Dollars figure was to illustrate the fallacy 
> of claiming that fines are irrelevant, as well as a joke that 
> you probably would have missed unless you saw the movie Austin
> Powers.    There's only 1 kind of fine that is irrelevant and
> that is a fine that is set too low.
> 
> Presumably, anyone setting up a fine schedule would be smart 
> enough to understand this and set the fines accordingly.  I 
> suppose I could have just said this, but where's the fun in that?
> 
> Understand of course that I don't support the proposal AT ALL 
> but I am not going to resist pointing out logical fallacies 
> in arguments against it - that DOES NOT mean I'm defending it!
> 
> Ted
> 
>

I understand and appreciate your devil's advocacy..   

I am really warming up to the WHOIS!bogon idea..  The problem is that it
would effectively be reclamation, and I haven't worked out the angles on
that yet..  Maybe a choice of whoises..  One (WHOIS && !bogon) and one
(WHOIS | stale) {please excuse my bad regexp} and the community would be
free to utilize their preference according to their needs at the moment..

How would we best incorporate this into routing?
-------------- 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/20081029/ef38be9b/attachment.bin>

From sethm at rollernet.us  Wed Oct 29 16:43:58 2008
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 29 Oct 2008 13:43:58 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB29@mail>
References: <2AF2A084-347B-4E7F-A3F1-1239989744ED@svcolo.com>
	<FC852A9FA1AA4CC08E8238B5D09E5179@tedsdesk>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB29@mail>
Message-ID: <4908CB0E.7010705@rollernet.us>

<snip lots of stuff>

Here's my take. I'm just a tiny AS operator. There's big chunks out 
there that aren't under ARIN's control. Jerking around a /22 holder with 
audits just to maybe extend the runout date by 10 seconds doesn't really 
seem worth it. I don't have a huge staff sitting around to play 
paperwork games to make someone else happy, and I have a gut feeling 
that in the end it will be people like me and my /22 that will suffer, 
while the bigger orgs will continue to get a free pass. I'd rather see 
efforts focused on 1) pushing IPv6 like there's no tomorrow and failing 
that 2) getting back something that would be worthwhile like a /8.

~Seth


From alan at batie.org  Wed Oct 29 16:53:18 2008
From: alan at batie.org (Alan Batie)
Date: Wed, 29 Oct 2008 13:53:18 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <4908CB0E.7010705@rollernet.us>
References: <2AF2A084-347B-4E7F-A3F1-1239989744ED@svcolo.com>	<FC852A9FA1AA4CC08E8238B5D09E5179@tedsdesk>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB29@mail>
	<4908CB0E.7010705@rollernet.us>
Message-ID: <4908CD3E.9030602@batie.org>

Seth Mattinen wrote:
> Jerking around a /22 holder with 
> audits just to maybe extend the runout date by 10 seconds doesn't really 
> seem worth it. I don't have a huge staff sitting around to play 
> paperwork games to make someone else happy, and I have a gut feeling 
> that in the end it will be people like me and my /22 that will suffer, 

That's my feeling about this idea as well...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3263 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081029/79a3cd8f/attachment.bin>

From bmanning at vacation.karoshi.com  Wed Oct 29 16:55:28 2008
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Wed, 29 Oct 2008 20:55:28 +0000
Subject: [arin-ppml] was "Library Book" (e.g. the DHCP server for the
	Internet)
Message-ID: <20081029205528.GA15521@vacation.karoshi.com.>


not sure that idea is going to get a whole lot of traction... but I could be
wrong.

the long/lean is that address efficency is going to go up - and there are 
several ways to get there.

here is one other view:

	 http://www.1-4-5.net/~dmm/iteotwawki-ccw08.ppt

--bill


From cgrundemann at gmail.com  Wed Oct 29 17:18:37 2008
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 29 Oct 2008 15:18:37 -0600
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <4908CB0E.7010705@rollernet.us>
References: <2AF2A084-347B-4E7F-A3F1-1239989744ED@svcolo.com>
	<FC852A9FA1AA4CC08E8238B5D09E5179@tedsdesk>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB29@mail>
	<4908CB0E.7010705@rollernet.us>
Message-ID: <443de7ad0810291418p7fc44898u15bd67aa28a5ea63@mail.gmail.com>

On Wed, Oct 29, 2008 at 2:43 PM, Seth Mattinen <sethm at rollernet.us> wrote:
> <snip lots of stuff>
>
> Here's my take. I'm just a tiny AS operator. There's big chunks out
> there that aren't under ARIN's control. Jerking around a /22 holder with
> audits just to maybe extend the runout date by 10 seconds doesn't really
> seem worth it. I don't have a huge staff sitting around to play
> paperwork games to make someone else happy, and I have a gut feeling
> that in the end it will be people like me and my /22 that will suffer,
> while the bigger orgs will continue to get a free pass. I'd rather see
> efforts focused on 1) pushing IPv6 like there's no tomorrow and failing
> that 2) getting back something that would be worthwhile like a /8.

My assumption is that documenting a single /22 will be much less
demanding than documenting multiple /16s, etc.  IOW, the amount of
effort should be (at least somewhat) proportional to the size of the
network.

To your numbered points; I agree 100% - I am not saying that this idea
is a complete solution, only (possibly) one peice of one.

>
> ~Seth
> _______________________________________________
> 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.chrisgrundemann.com
www.linkedin.com/in/cgrundemann


From ptimmins at clearrate.com  Wed Oct 29 17:07:30 2008
From: ptimmins at clearrate.com (Paul G. Timmins)
Date: Wed, 29 Oct 2008 17:07:30 -0400
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <4908B28D.2050604@rollernet.us>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com><443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail><E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>
	<4908B28D.2050604@rollernet.us>
Message-ID: <B98837F93D40A74D8656EAE7C1F57C56295F27@EXCHANGE1.corp.clearrate.net>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Seth Mattinen
> Sent: Wednesday, October 29, 2008 2:59 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> Jo Rhett wrote:
> > On Oct 29, 2008, at 6:52 AM, Kevin Kargel wrote:
> >> What you are proposing could easily turn in to an 
> excessive annual  
> >> manpower
> >> requirement for an ISP.  It could easily be forgotten or mis- 
> >> assigned with
> >> terrible consequences.
> > 
> > Not unless the ISP throws away the information gained from the  
> > previous year every time and does it all from scratch.
> > 
> > And I mean seriously, have you ever worked at an ISP that 
> didn't have  
> > an internal database with information about every single IP  
> > allocation?  ISPs are going to find this exercise trivial.
> 
> I have. I once spent about 2 months getting all of their 
> swips in order. 
> The only documentation was comments in zone files. I think they just 
> deleted all the swips later or something.

I don't understand why basic recordkeeping that any ISP should be doing,
should not be able to be mandated. I have had no problem maintaining an
accurate inventory of our IP use. I feel confident enough about our
recordkeeping to pay $20 out of my own pocket for any inaccurate or
missing record found in our IP database. (This is not a challenge, of
course).

I know people out there don't maintain their records, but there's really
no excuse for that. How hard is it to kick out a SWIP, or update a
spreadsheet or something? At the end of the day, these bad or
nonexistent records are doctored up, and made to show ARIN that they're
out of IPs and need more. How do they come to this determination without
accurate records in the first place? Do they give up on finding more
useful space? How can you accurately assign and track your IP space well
enough to know you need more space if you don't have good records?

I have been out for a week, and honestly, I have no idea what proposal
is even being discussed. But to hear other ARIN holders discussing how
poor their records are and how it's not fair if someone mandates
something resembling accuracy is insulting to people who actually work
to maintain accurate records to avoid needless allocations and waste.

-Paul


From leo.vegoda at icann.org  Wed Oct 29 17:27:37 2008
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Wed, 29 Oct 2008 14:27:37 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <4908CB0E.7010705@rollernet.us>
Message-ID: <C52E93D9.20D7E%leo.vegoda@icann.org>

On 29/10/2008 9:43, "Seth Mattinen" <sethm at rollernet.us> wrote:

[...]

> I'd rather see
> efforts focused on 1) pushing IPv6 like there's no tomorrow and failing
> that 2) getting back something that would be worthwhile like a /8.

Some /8s have been returned and recovered. Each one buys slightly less than
one month at the current rate on consumption. It's not realistic to expect
any more whole /8s to be returned or recovered.

That doesn't mean that address recovery is pointless but it does mean it
will probably be quite slow and expensive.

Regards,

Leo Vegoda



From kkargel at polartel.com  Wed Oct 29 17:33:33 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 29 Oct 2008 16:33:33 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <B98837F93D40A74D8656EAE7C1F57C56295F27@EXCHANGE1.corp.clearrate.net>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk><97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com><443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com><70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail><E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com><4908B28D.2050604@rollernet.us>
	<B98837F93D40A74D8656EAE7C1F57C56295F27@EXCHANGE1.corp.clearrate.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB30@mail>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul G. Timmins
> Sent: Wednesday, October 29, 2008 4:08 PM
> To: Seth Mattinen; ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net
> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Seth Mattinen
> > Sent: Wednesday, October 29, 2008 2:59 PM
> > To: ppml at arin.net
> > Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> > 
> > Jo Rhett wrote:
> > > On Oct 29, 2008, at 6:52 AM, Kevin Kargel wrote:
> > >> What you are proposing could easily turn in to an
> > excessive annual
> > >> manpower
> > >> requirement for an ISP.  It could easily be forgotten or mis- 
> > >> assigned with terrible consequences.
> > > 
> > > Not unless the ISP throws away the information gained from the 
> > > previous year every time and does it all from scratch.
> > > 
> > > And I mean seriously, have you ever worked at an ISP that
> > didn't have
> > > an internal database with information about every single IP 
> > > allocation?  ISPs are going to find this exercise trivial.
> > 
> > I have. I once spent about 2 months getting all of their swips in 
> > order.
> > The only documentation was comments in zone files. I think 
> they just 
> > deleted all the swips later or something.
> 
> I don't understand why basic recordkeeping that any ISP 
> should be doing, should not be able to be mandated. I have 
> had no problem maintaining an accurate inventory of our IP 
> use. I feel confident enough about our recordkeeping to pay 
> $20 out of my own pocket for any inaccurate or missing record 
> found in our IP database. (This is not a challenge, of course).

I don't understand why anyone would think they have the right to tell anyone
else how to admin their network or what tasks they need to do in order to do
it.  I agree that basic recordkeeping is a must but I don't think we have
the right to make other businesses do things our way.  Even if you
religiously balance your checkbook I don't think you would be happy if they
made not balancing it a misdemeanor offense.  

You do things better than some other people do.  That is why your business
runs smoother and is more profitable than theirs.  Lead by example, not
legislation.


> 
> I know people out there don't maintain their records, but 
> there's really no excuse for that. How hard is it to kick out 
> a SWIP, or update a spreadsheet or something? At the end of 
> the day, these bad or nonexistent records are doctored up, 
> and made to show ARIN that they're out of IPs and need more. 
> How do they come to this determination without accurate 
> records in the first place? Do they give up on finding more 
> useful space? How can you accurately assign and track your IP 
> space well enough to know you need more space if you don't 
> have good records?
> 
> I have been out for a week, and honestly, I have no idea what 
> proposal is even being discussed. But to hear other ARIN 
> holders discussing how poor their records are and how it's 
> not fair if someone mandates something resembling accuracy is 
> insulting to people who actually work to maintain accurate 
> records to avoid needless allocations and waste.


I applaud you efforts for accurate and timely recordkeeping.  I do not think
it is reasonable that we expect the rest of the world meets your standards.


> 
> -Paul
> _______________________________________________
> 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/20081029/4e515efd/attachment.bin>

From stephen at sprunk.org  Wed Oct 29 19:07:41 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 29 Oct 2008 18:07:41 -0500
Subject: [arin-ppml] The problem with IPv4 bogon and listing them
In-Reply-To: <6A1B0F74F28C481A90C2C97C1C36509D@tedsdesk>
References: <6A1B0F74F28C481A90C2C97C1C36509D@tedsdesk>
Message-ID: <4908ECBD.90007@sprunk.org>

Ted Mittelstaedt wrote:
> Kevin, let's talk about bogons.  We have Cymru running their list here:
>
> http://www.cymru.com/Documents/bogon-list.html
>
> but, I'll quote from the text on the list:
>
> "...IANA allocations change over time, so please check back regularly to ensure you have the latest filters. I can not stress this point strongly enough - these allocations change, as often as every four months...."
>
> Checking back every 4 MONTHS?  So that means if I request IPv4 that's dirty, on this list, and I get it, that I have to wait 4 months before using it?

No.  According to staff comments, when a block is returned or revoked, 
it is placed on hold for _at least_ 6 mos if it is "clean" and much 
longer if it is "dirty".  If folks keep their bogon (or spammer) filters 
up to date, there should be no problem at all.

S


From stephen at sprunk.org  Wed Oct 29 19:12:36 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 29 Oct 2008 18:12:36 -0500
Subject: [arin-ppml] The problem with IPv4 bogon and listing them
In-Reply-To: <B1F0968B2C874055B5C966E6BEDEF874@tedsdesk>
References: <B1F0968B2C874055B5C966E6BEDEF874@tedsdesk>
Message-ID: <4908EDE4.10207@sprunk.org>

Ted Mittelstaedt wrote:
> I don't see that yet another fee is necessary here.  ARIN already has a database - whois.

I would expect that WHOIS is an interface into an internal database by 
some other name.

> An effort really needs to be made to get the number blocks listed in whois to align with what is actually assigned, don't you think?  Whois should not list network entries for blocks that are in the free pool, and there should not be assigned blocks that lack an entry in whois.
>   

Ideally, yes.

> Ideally, a bogon list should be able to be generated by running a query that iterates through every /24 in the IP numberspace and queries it against the whois database, and the list would be all queries that return "no object found"
>   

That almost qualifies as a DoS attack against the WHOIS servers.  Better 
would be for ARIN to publish a list of ranges (in the /8s they maintain) 
of unassigned addresses in text, XML, and/or other convenient formats.  
Once the software is written, it should be trivial to publish the 
results.  These sorts of things are perfect for the ACSP.

S


From tedm at ipinc.net  Wed Oct 29 19:34:22 2008
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 29 Oct 2008 16:34:22 -0700
Subject: [arin-ppml] The problem with IPv4 bogon and listing them
In-Reply-To: <4908ECBD.90007@sprunk.org>
Message-ID: <8E128C25CFFB4DD4BBFE96FA0A995BAE@tedsdesk>



> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org] 
> Sent: Wednesday, October 29, 2008 4:08 PM
> To: Ted Mittelstaedt
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] The problem with IPv4 bogon and listing them
> 
> 
> Ted Mittelstaedt wrote:
> > Kevin, let's talk about bogons.  We have Cymru running their list 
> > here:
> >
> > http://www.cymru.com/Documents/bogon-list.html
> >
> > but, I'll quote from the text on the list:
> >
> > "...IANA allocations change over time, so please check back 
> regularly 
> > to ensure you have the latest filters. I can not stress this point 
> > strongly enough - these allocations change, as often as every four 
> > months...."
> >
> > Checking back every 4 MONTHS?  So that means if I request 
> IPv4 that's 
> > dirty, on this list, and I get it, that I have to wait 4 
> months before 
> > using it?
> 
> No.  According to staff comments, when a block is returned or 
> revoked, 
> it is placed on hold for _at least_ 6 mos if it is "clean" and much 
> longer if it is "dirty".  If folks keep their bogon (or 
> spammer) filters 
> up to date, there should be no problem at all.
> 

Let me fast forward for a moment:

It is now 2015 and it's been a few years since the last IANA-assigned
"virgin" IPv4 has been allocated from ARIN.

The large ISPs are now heavily into native IPv6 for Vista dialups, and
private IPv4 for everyone else, all going to large IPv4<->IPv6 translators,
as well as IPv4<->IPv4 nats.  It's fricken ugly for them, but they have
the cash to have a staff of network admins to keep the kludges running.

I'm a small ISP needing a portable block because I'm too big for my
upstreams
to hand me IP address blocks anymore, and besides I don't trust them any
further
than I can spit a rat and definitely don't want the golden handcuffs.  I
know
I need to run both IPv4 and IPv6 on my net to connect customers.  But, I
don't
have the expertise or time to keep a massive kludge/proxy thing running, so
what I want to do is KISS, that is, run IPv6 and public IPv4.

I go to ARIN for my small /21 IPv4 and my IPv6.  ARIN gives me the IPv6
immediately.  ARIN then gives me 3 options for getting IPv4:

1) Go on a waiting list and wait until God-knows how long
2) Take a "dirty" block that was just returned last week
3) try to find some abandonded IPv4 block floating around out there
that may or may not have been hijacked, and ARIN hasn't gotten around
to collecting up.

I think you know what I'm going to do.  I'll take the dirty block and
take my chances with it.  After all, all I really need to do is start
assigning from it, and when my customers call saying they can't get to
AOL or some place like that, I just need to contact AOL and ask them to
pull my newly-assigned block off their bogon list.  Which, knowing AOL,
after enough trouble, they will do it.

Ted



From gih at apnic.net  Thu Oct 30 03:49:39 2008
From: gih at apnic.net (Geoff Huston)
Date: Thu, 30 Oct 2008 18:49:39 +1100
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <49061D56.6358.FF331AB@farmer.umn.edu>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
	<49061D56.6358.FF331AB@farmer.umn.edu>
Message-ID: <797A328D-3807-4D49-BB05-E173977B6275@apnic.net>

Thanks for your note David.

You have noted that the analogy with a title office has parallels
between deaggregation and subdivision, and the regulation of such
deaggregation. I think you are making that point that a title office
may be able to apply some constraint on deaggregation either by
applying some regulatory constraint in its own right, or conforming to
some third party acting in a regulatory capacity.

The observation I made was that the ability of the registry to impose
regulatory constraints was mitigated by its enforcement
capability. When a registry imposes conditions that are not universally
accepted then alternate registries appear - the IRR story is a good
example of registry proliferation and some aspects of attendant
problems that this causes (http://www.nanog.org/meetings/nanog44/presentations/Tuesday/RAS_irrdata_N44.pdf 
).

I'm not arguing with the desireability of aggregation in the routing
system, but what I have been saying is that the registry function in
and of itself does not necessarily have the apropriate enforement
ability, and that imposing such a burden on the registry in terms of
access policies runs the distinct risk of heading down the path
already travelled with route registries, which I personally do not
think is a desireable path.

kind regards,

   Geoff Huston

    Disclaimer : still speaking for myself, of course.




From randy at psg.com  Thu Oct 30 03:56:59 2008
From: randy at psg.com (Randy Bush)
Date: Thu, 30 Oct 2008 11:56:59 +0400
Subject: [arin-ppml] Some observations on the differences in the various
 transfer policy proposals
In-Reply-To: <797A328D-3807-4D49-BB05-E173977B6275@apnic.net>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>	<49061D56.6358.FF331AB@farmer.umn.edu>
	<797A328D-3807-4D49-BB05-E173977B6275@apnic.net>
Message-ID: <490968CB.40809@psg.com>

Geoff Huston wrote:
> the IRR story is a good example of registry proliferation

indeed, it has been quite successful and as useful as irr data are

> some aspects of attendant problems that this causes
>
(http://www.nanog.org/meetings/nanog44/presentations/Tuesday/RAS_irrdata_N44.pdf

no.  that is a problem with the content, not the fact that it the irr is
a successfully distributed registry.
r
andy


From gih at apnic.net  Thu Oct 30 04:06:19 2008
From: gih at apnic.net (Geoff Huston)
Date: Thu, 30 Oct 2008 19:06:19 +1100
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <490968CB.40809@psg.com>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>	<49061D56.6358.FF331AB@farmer.umn.edu>
	<797A328D-3807-4D49-BB05-E173977B6275@apnic.net>
	<490968CB.40809@psg.com>
Message-ID: <888CD95E-7EF1-44B8-B436-DFA42B94A740@apnic.net>


On 30/10/2008, at 6:56 PM, Randy Bush wrote:

> Geoff Huston wrote:
>> the IRR story is a good example of registry proliferation
>
> indeed, it has been quite successful and as useful as irr data are
>
>> some aspects of attendant problems that this causes
>>
> (http://www.nanog.org/meetings/nanog44/presentations/Tuesday/RAS_irrdata_N44.pdf
>
> no.  that is a problem with the content, not the fact that it the  
> irr is
> a successfully distributed registry.

I believed that I was referring to the problem with content, in terms  
of consistency, authority, coherence, verifiability and accuracy of  
the data contained in those registries. Perhaps this was not made  
adequately clear, and I must apologise for my poor command of English.

Geoff Huston

Disclaimer: Guess! Here's a hint: noone else is implicated.
.





From tvest at pch.net  Thu Oct 30 04:10:29 2008
From: tvest at pch.net (Tom Vest)
Date: Thu, 30 Oct 2008 12:10:29 +0400
Subject: [arin-ppml] Some observations on the differences in the various
	transfer policy proposals
In-Reply-To: <797A328D-3807-4D49-BB05-E173977B6275@apnic.net>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net>
	<49061D56.6358.FF331AB@farmer.umn.edu>
	<797A328D-3807-4D49-BB05-E173977B6275@apnic.net>
Message-ID: <C332B1FD-170A-4C74-94F9-9EB4FCB9F668@pch.net>

Hi Geoff,

Out of curiosity, can you think of any example of any policy or goal  
or imperative in any context where pure unencumbered choice, free from  
any material constraints and subject only to pure self-interest is the  
*only* driver -- and yet that goal or whatever is actually realized,  
i.e., enough to be something more than a hollow joke?

*Meaningful participation in any registry* is itself one of the  
conditions that you are proposing to transform into a completely  
unencumbered choice.

The IRRs are a great example, but not one that supports your point.

Thanks,

TV

On Oct 30, 2008, at 11:49 AM, Geoff Huston wrote:

> Thanks for your note David.
>
> You have noted that the analogy with a title office has parallels
> between deaggregation and subdivision, and the regulation of such
> deaggregation. I think you are making that point that a title office
> may be able to apply some constraint on deaggregation either by
> applying some regulatory constraint in its own right, or conforming to
> some third party acting in a regulatory capacity.
>
> The observation I made was that the ability of the registry to impose
> regulatory constraints was mitigated by its enforcement
> capability. When a registry imposes conditions that are not  
> universally
> accepted then alternate registries appear - the IRR story is a good
> example of registry proliferation and some aspects of attendant
> problems that this causes (http://www.nanog.org/meetings/nanog44/presentations/Tuesday/RAS_irrdata_N44.pdf
> ).
>
> I'm not arguing with the desireability of aggregation in the routing
> system, but what I have been saying is that the registry function in
> and of itself does not necessarily have the apropriate enforement
> ability, and that imposing such a burden on the registry in terms of
> access policies runs the distinct risk of heading down the path
> already travelled with route registries, which I personally do not
> think is a desireable path.
>
> kind regards,
>
>   Geoff Huston
>
>    Disclaimer : still speaking for myself, of course.
>
>
> _______________________________________________
> 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  Thu Oct 30 06:50:59 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 30 Oct 2008 10:50:59 -0000
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB25@mail>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC090AD7F4@E03MVZ2-UKDY.domain1.systemhost.net>

> Of course this is all assuming the authority to assess fines 
> in the first place.  You (should) have a contract and an 
> agreement with ARIN.  You are not subject to ARIN.  

The fact is that the PPML discussions and ARIN's policies, do NOT have
the authority to impose fines or modify fees. Only the ARIN members
themselves can impose fines or change the fee structure.

You guys are all barking into the wind.

--Michael Dillon


From michael.dillon at bt.com  Thu Oct 30 06:55:42 2008
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 30 Oct 2008 10:55:42 -0000
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB2B@mail>
Message-ID: <C0F2465B4F386241A58321C884AC7ECC090AD80C@E03MVZ2-UKDY.domain1.systemhost.net>


> I am really warming up to the WHOIS!bogon idea..  

It's a fine idea. The problem is that it has nothing
to do with ARIN policy. Please take this off the list.
I suggest <http://www.arin.net/acsp/index.html> the
ARIN suggestion box.

--Michael Dillon


From kkargel at polartel.com  Thu Oct 30 09:22:32 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 30 Oct 2008 08:22:32 -0500
Subject: [arin-ppml] Some observations on the differences in the
	varioustransfer policy proposals
In-Reply-To: <797A328D-3807-4D49-BB05-E173977B6275@apnic.net>
References: <3A0696F6-F8EE-4F3B-8438-0ECBD56C845F@apnic.net><49061D56.6358.FF331AB@farmer.umn.edu>
	<797A328D-3807-4D49-BB05-E173977B6275@apnic.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB32@mail>

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Geoff Huston
> Sent: Thursday, October 30, 2008 2:50 AM
> To: David Farmer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Some observations on the differences 
> in the varioustransfer policy proposals
> 
> Thanks for your note David.
> 
> You have noted that the analogy with a title office has 
> parallels between deaggregation and subdivision, and the 
> regulation of such deaggregation. I think you are making that 
> point that a title office may be able to apply some 
> constraint on deaggregation either by applying some 
> regulatory constraint in its own right, or conforming to some 
> third party acting in a regulatory capacity.
> 
> The observation I made was that the ability of the registry 
> to impose regulatory constraints was mitigated by its 
> enforcement capability. When a registry imposes conditions 
> that are not universally accepted then alternate registries 
> appear - the IRR story is a good example of registry 
> proliferation and some aspects of attendant problems that 
> this causes 
> (http://www.nanog.org/meetings/nanog44/presentations/Tuesday/R
> AS_irrdata_N44.pdf
> ).
> 
> I'm not arguing with the desireability of aggregation in the 
> routing system, but what I have been saying is that the 
> registry function in and of itself does not necessarily have 
> the apropriate enforement ability, and that imposing such a 
> burden on the registry in terms of access policies runs the 
> distinct risk of heading down the path already travelled with 
> route registries, which I personally do not think is a 
> desireable path.
> 
> kind regards,
> 
>    Geoff Huston
> 
>     Disclaimer : still speaking for myself, of course.

Good point David.  People here tend to forget that there is no government
with an army forcing you to use a specific registrar.  The reasons that
people use the registry is that it works and it is easier than doing it
yourself.  If it stops being easier then people can find ways to use a
different registry or to use their own.  Nobody -(not even the registrar)-
have any dog given right to the numbers.  We all agree to abide by the
registry instructions because it is incredibly less confusing and hugely
less work.  When that stops being the case then all bets are off.
-------------- 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/20081030/26df0a2f/attachment.bin>

From kkargel at polartel.com  Thu Oct 30 09:34:50 2008
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 30 Oct 2008 08:34:50 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC090AD7F4@E03MVZ2-UKDY.domain1.systemhost.net>
References: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB25@mail>
	<C0F2465B4F386241A58321C884AC7ECC090AD7F4@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB33@mail>

 

> -----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: Thursday, October 30, 2008 5:51 AM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] The Library Book Approach to IPv4 Scarcity
> 
> > Of course this is all assuming the authority to assess fines in the 
> > first place.  You (should) have a contract and an agreement 
> with ARIN.  
> > You are not subject to ARIN.
> 
> The fact is that the PPML discussions and ARIN's policies, do 
> NOT have the authority to impose fines or modify fees. Only 
> the ARIN members themselves can impose fines or change the 
> fee structure.
> 
> You guys are all barking into the wind.
> 

I maintain that at the current time neither ARIN nor ARIN members have
authority to assess fines (read as - charge punative monies in excess of
contract).  
-------------- 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/20081030/f33d32f3/attachment.bin>

From stephen at sprunk.org  Thu Oct 30 12:06:00 2008
From: stephen at sprunk.org (Stephen Sprunk)
Date: Thu, 30 Oct 2008 11:06:00 -0500
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
References: <443de7ad0810271152t9cdb2d8n482f7ce4d5cb04cd@mail.gmail.com>
Message-ID: <4909DB68.5070102@sprunk.org>

Chris Grundemann wrote:
> == Potential Proposal:
>
> Once every 12months each holder of IPv4 addresses is required to fully 
> document their IP utilization and demonstrate that the current 
> utilization standard for IPv4 assignments and allocations is being 
> met. This shall include all currently held IPv4 space, regardless of 
> origin or registration status.

Other than the period (see below), this is the degenerate case of 
2007-14 -- and fear of that degenerate case is/was a major part of the 
opposition to that proposal.  Like many others, I object to _all_ 
registrants being subjected to this process regularly, regardless of the 
period; it should be up to ARIN staff to decide which registrants 
require this sort of attention -- and where ARIN's (read: our) money is 
most efficiently spent.  Reviewing all that documentation ain't cheap.

> A fee shall be assessed for underutilization or insufficient 
> documentation.

ARIN is not -- and IMHO should not be -- in the business of levying 
fines.  The only real enforcement powers ARIN has are (a) refusing to 
allocate/assign new resources, and (b) revoking existing resources.  I 
am very leery of changing that.

>     * The fee for one 12m period shall be waived if the address holder 
> returns a contiguous block of IPv4 space equal to at least 1/256th of 
> currently held space and no less than one /24 (class C equivalent) to 
> ARINs free pool.
>     * The fee for one 12m period shall be waived if the address holder 
> signs an ARIN RSA for any uncontested and unregistered IPv4 space, 
> this waiver shall be restricted to one use per member organization.

There are existing policies that have a similar purpose which don't 
appear to have had any significant effect to date.  Plus, fees (and any 
waivers thereof) are generally the purview of the BoT.  However, I would 
support the general idea of either of these proposals if they were not 
tied to the above "library fee" proposal.

> 6) I originally considered a period of 24 months but shortened it to 
> 12 months considering the rapid approach of IANA free pool exhaustion; 
> 24 months will be far to long of an interval to have a significant 
> impact on IPv4 availability.

2007-14 originally had a (minimum) 12-month window between reviews, but 
there was a very strong consensus that that was too short, so we 
modified it to 24 months.  I would suggest the same to you so that you 
don't run into the same opposition.  It could be reduced later in a 
separate proposal if it becomes absolutely necessary.

S


From scott.beuker at sjrb.ca  Thu Oct 30 13:31:14 2008
From: scott.beuker at sjrb.ca (Scott Beuker)
Date: Thu, 30 Oct 2008 11:31:14 -0600
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AB30@mail>
References: <DC68F81FAA8B408DB9DDDAA0E8480E3D@tedsdesk>
	<97617247-B8EA-4F62-BB11-014825BF8A51@svcolo.com>
	<443de7ad0810282115g40dad82ex1ceeafe0a4449eff@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB16@mail>
	<E9591B45-145C-4A2E-93F8-D4D49A774D46@svcolo.com>
	<4908B28D.2050604@rollernet.us>
	<B98837F93D40A74D8656EAE7C1F57C56295F27@EXCHANGE1.corp.clearrate.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4AB30@mail>
Message-ID: <46A2DD1223D7BF47B61799AFFBA8AD8902B0E603@PRDCG4EXVW01-1.OSS.PRD>

> I don't understand why anyone would think they have the right to tell
> anyone else how to admin their network or what tasks they need to do
in
> order to do it.


This isn't telling people how to admin *their* network, this is telling
people that they need to keep track of *our* IPs. Big difference.

I don't tell people how to raise *their* children, but I do insist that
they keep their children from driving their cars on *our* roads. The
reason that's a better analogy to me than balancing a cheque book is
because we don't share your cheque book, but we share the roads like we
share IP space.

Nothing wrong with requiring accountability from those using IP
resources,
in my opinion... at any point in time.

- Scott



From jrhett at svcolo.com  Thu Oct 30 15:58:27 2008
From: jrhett at svcolo.com (Jo Rhett)
Date: Thu, 30 Oct 2008 12:58:27 -0700
Subject: [arin-ppml] The Library Book Approach to IPv4 Scarcity
In-Reply-To: <C8FE594BAF9C4E46984421ACCEADDAE7@tedsdesk>
References: <C8FE594BAF9C4E46984421ACCEADDAE7@tedsdesk>
Message-ID: <B04C22F8-99E6-46B9-99E5-62EAE61FD2FE@svcolo.com>

At which point I would have chastized any peer who kept sending your  
announcement as valid.

Yes, it means we have to do better at filtering.  This is not a bad  
thing.

On Oct 29, 2008, at 1:05 PM, Ted Mittelstaedt wrote:
> How do you recover space when the org advertising it does not want to
> give it up?
>
> Fact is, I was rather curious myself about these situations
> so when we got our portable allocation years ago I kept advertising  
> a /23
> from one
> of our old blocks after renumbering out of it just to see what would  
> happen.
> About a year later the block was finally assigned.  Trust me, if I had
> wanted to be a jerk about it, it would have gotten pretty bad for the
> org that got the numbers.
>
> Ted
>

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550