From marty at akamai.com  Mon Nov  1 09:38:36 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 1 Nov 2010 09:38:36 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <AANLkTimTgE+7z-FjPXzs4GHXbhMHDzdj=AFGbSjy9dTp@mail.gmail.com>
Message-ID: <C8F43B1C.15512%marty@akamai.com>




On 10/29/10 1:00 PM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:

> On Fri, Oct 29, 2010 at 10:47, Leo Bicknell <bicknell at ufp.org> wrote:
>> In a message written on Fri, Oct 29, 2010 at 12:40:10PM -0400, ARIN wrote:
>>> The AC made the following revisions to the text:
>>> ? - The second sentence in section 2 was changed into two sentences.
>>> "Eligible address space includes addresses that are not designated as
>>> "special use" by an IETF RFC. Address space may only be returned by the
>>> issuing RIR."
>> 
>> I am unsure if I am being pedantic here, or if there is an intent
>> to exclude legacy space.
> 
> That was certainly not the originators intent. Although I agree that
> the AC did a less than optimum job of word-smithing; I must admit the
> original text was less than perfectly clear as well.
> 
> In any case, I think the next sentence saves us from any potential
> problem: "Legacy address holders may return address space directly to
> the IANA if they so choose."
> 
>> Legacy space was not issued by any of the current RIR's. ?ARIN may
>> be able to claim it is the decendant of the issuer (warning, can
>> of worms), but for instance other RIR's had legacy space transferred
>> to them years ago.
>> 
>> It is entirely possible to read that sentence as excluding legacy
>> space as a result, which I hope was not the intention.
>> s/issuing/responsible/ would clear up any confusion, although I'm
>> uncleaer why the sentence is needed at all. ?Do we really need to
>> state that IANA shouldn't accept back an APNIC block if RIPE is the
>> one trying to return it?
> 
> I think it makes sense to cover our bases.
> 


At worst, the authors via the ASO AC can suggest that the other RIR's
rewrite this to something clearer if they consider it to be able to be done
while keeping the context and intent of the proposal.


Best,

-M<



From marty at akamai.com  Mon Nov  1 15:42:12 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 1 Nov 2010 15:42:12 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <EE964CDF-FBF2-40C1-B666-DB0F2FF2E067@arin.net>
Message-ID: <C8F49054.15697%marty@akamai.com>




On 10/29/10 3:51 PM, "John Curran" <jcurran at arin.net> wrote:

> On Oct 29, 2010, at 1:48 PM, David Farmer wrote:
> 
>> Further more, yes it is a can of worms but, I believe it is ARIN's position
>> that ARIN is essentially the issuing RIR for Legacy address space within the
>> ARIN region, as through contracts it is successor registry to the previous
>> registries that made the Legacy allocations. Additionally, I it is my
>> understanding that the other RIRs have much cleaner contractual relationships
>> with their Legacy holders.
> 
> That is correct: ARIN is the successor registry for legacy address space
> registrations within this region.
> 
> While other regions had a very modest number of legacy assignments to be
> brought under clearer contractual relations, the quantity of legacy
> registrations in the ARIN region make this process much more challenging.
> Current statistics on progress in this area may be found here:
> <https://www.arin.net/knowledge/statistics/legacy.html>
> 


What's breakout of v4 prefixes not associated with an RSA or an L RSA?

Best,

-M<





From jcurran at arin.net  Mon Nov  1 22:04:08 2010
From: jcurran at arin.net (John Curran)
Date: Mon, 1 Nov 2010 22:04:08 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <C8F49054.15697%marty@akamai.com>
References: <C8F49054.15697%marty@akamai.com>
Message-ID: <1B197CF1-74A5-4842-920D-74235336D029@arin.net>

On Nov 1, 2010, at 3:42 PM, Hannigan, Martin wrote:

>> While other regions had a very modest number of legacy assignments to be
>> brought under clearer contractual relations, the quantity of legacy
>> registrations in the ARIN region make this process much more challenging.
>> Current statistics on progress in this area may be found here:
>> <https://www.arin.net/knowledge/statistics/legacy.html>
>> 
> 
> What's breakout of v4 prefixes not associated with an RSA or an L RSA?

Marty - 
 
At present, we can only provide a partial answer with respect to legacy resources not under LRSA or RSA.  We know the inventory of Legacy resources, and can provide a breakdown for all those number resources under LRSA because we specifically track those prefix counts.  We can provide a breakdown of legacy resources not under LRSA by subtracting those LRSA counts from the inventory count, and that is attached below.

Unfortunately, we have not historically associated the agreements with the number resources in the database, and that precludes our generating a breakdown of those Legacy resources which have been brought specifically under an RSA agreement.  We are working on changing that, but first must transition to newer database schema, phase out the older templates and SWIP processing system, etc. all as discussed in the ARIN Atlanta meeting.  This work is on-track for early next year and includes indexing the number resources associated with each LRSA and RSA.

So, attached is the breakdown of legacy resources not under LRSA.  These are active (i.e. assigned) resources only; they do not include resources in the returned, revoked, or hold status.  Again, some of these legacy resources may by under RSA at the request of the holder (either moved under an existing RSA as a result of merger/transfer or by entering an RSA before the LRSA agreement was available) - 

Number of Prefixes NOT under LRSA  |  Prefix Size

  33    /8                    
   1    /9           
   3   /10          
   4   /11          
  13   /12          
  29   /13          
 112   /14         
 183   /15         
5263   /16        
 246   /17         
 476   /18           
 730   /19          
 767   /20           
1055   /21            
1519   /22           
2644   /23            
20062  /24 

I hope this proves helpful in the policy development process!
/John

John Curran
President and CEO
ARIN




From mueller at syr.edu  Tue Nov  2 08:57:37 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 2 Nov 2010 08:57:37 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <4CCB08F9.1030303@umn.edu>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> 
> But, the final sentence in the section makes all that a moot point, as
> it explicitly gives Legacy holders of address space the ability to
> return address space to IANA directly, if they choose to.

I think this is correct. But let's not forget: legacy holders also have the ability not to return address space at all; i.e., they could keep it or transfer it privately if they chose to. 

--MM


From jcurran at arin.net  Tue Nov  2 11:12:20 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 2 Nov 2010 11:12:20 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu>
	<75822E125BCB994F8446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>

On Nov 2, 2010, at 8:57 AM, Milton L Mueller wrote:

> I think this is correct. But let's not forget: legacy holders also have the ability not to return address space at all; i.e., they could keep it or transfer it privately if they chose to. 

Milton - 
 
   I'm not certain what "transfer it privately" means, so for avoidance of doubt I'll state that legacy holders may bring their resources under an LRSA, and then participate in transfers per the policies in the ARIN region. NRPM section 8.3 provides such legacy address holders the ability to have a Specified Transfer to recipient which otherwise meets the allocation/assignment policy.  This might be seen as useful at the point in time when ARIN has no free resources available. At present, transfers to parties in other regions isn't possible, but there has been a policy proposal submitted for consideration which would change that.

/John

John Curran 
President and CEO
ARIN

From mueller at syr.edu  Tue Nov  2 13:03:48 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 2 Nov 2010 13:03:48 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu>
	<75822E125BCB994F8446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> From: John Curran [mailto:jcurran at arin.net]
>    I'm not certain what "transfer it privately" means

I am

> of doubt I'll state that legacy holders may bring their resources under
> an LRSA, 

Or not. As they wish.

--MM




From jcurran at arin.net  Tue Nov  2 13:29:15 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 2 Nov 2010 13:29:15 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu>
	<75822E125BCB994F8446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<75822E125BCB994F8446858C4B19F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>

On Nov 2, 2010, at 1:03 PM, Milton L Mueller wrote:

> -----Original Message-----
>> From: John Curran [mailto:jcurran at arin.net]
>>   I'm not certain what "transfer it privately" means
> 
> I am
> 
>> of doubt I'll state that legacy holders may bring their resources under
>> an LRSA, 
> 
> Or not. As they wish.

Correct.  They may bring their resources under an RSA or LRSA or not, as they wish. They may also transfer resources under agreement according to the policies adopted in the region, or not transfer them (again as they wish.)  

The only they can't do is transfer resources outside of the policies, as ARIN has to maintain the registration database in accordance with the community policies as adopted.

/John

John Curran
President and CEO
ARIN

 




From jcurran at arin.net  Tue Nov  2 17:42:15 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 2 Nov 2010 17:42:15 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):
 GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call
 (textrevised)
In-Reply-To: <32136639FEF54CFDB80A5AB685165263@mike>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8
	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19
	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
Message-ID: <36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>

On Nov 2, 2010, at 2:57 PM, Mike Burns wrote:

> John,
> 
> How was the registration database maintained in accordance with community 
> policies and yet the ORG and POC information for some legacy records has 
> been changed?

Organizations with legacy address blocks may update their point of contact
information (in fact, they can now do it online via ARIN Online, probably 
why we have more than 20,000 ARIN Online accounts... :-)  Remember, we are
actively requesting all organizations to update their Point of Contact (POC)
information via electronic reminders.  More information about this program 
and its progress was given at the Atlanta meeting:
<https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobile_POC_Validation.pdf>

> Are we to assume by your statements that the 16/8 block HAS to have an LSRA 

> signed, since the original recipients of this legacy block are no longer 
> listed in the registration database?
> And, if this is the case, can we assume that justification was provided per 
> NRPM 8.2?

ARIN doesn't discuss any organizations number resources in public due to privacy 
issues; if you are a valid contact for the resources you may contact the 
Registration Services Helpdesk <https://www.arin.net/resources/help_desk.html>

> Or is there some other policy mechanism whereby ARIN will make changes to 
> that database to reflect private transfers of legacy addresses?

All transfers must meet the community developed and adopted policies at the 
time of the request, and I've outlined those mechanisms which presently apply.

Thanks!
/John

John Curran
President and CEO
ARIN



From tedm at ipinc.net  Tue Nov  2 18:37:37 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 02 Nov 2010 15:37:37 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):
 GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call
 (textrevised)
In-Reply-To: <36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
Message-ID: <4CD092B1.4090203@ipinc.net>

On 11/2/2010 2:42 PM, John Curran wrote:
> On Nov 2, 2010, at 2:57 PM, Mike Burns wrote:
>
>> John,
>>
>> How was the registration database maintained in accordance with community
>> policies and yet the ORG and POC information for some legacy records has
>> been changed?
>
> Organizations with legacy address blocks may update their point of contact
> information (in fact, they can now do it online via ARIN Online, probably
> why we have more than 20,000 ARIN Online accounts... :-)  Remember, we are
> actively requesting all organizations to update their Point of Contact (POC)
> information via electronic reminders.  More information about this program
> and its progress was given at the Atlanta meeting:
> <https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobile_POC_Validation.pdf>
>
>> Are we to assume by your statements that the 16/8 block HAS to have an LSRA
>
>> signed, since the original recipients of this legacy block are no longer
>> listed in the registration database?
>> And, if this is the case, can we assume that justification was provided per
>> NRPM 8.2?
>

Mike, the problem with the Legacy holders is that the ARIN community has 
never agreed to exert the RIR's authority over them.  There are many
historical reasons (some valid, some not) for this, but the Legacy
holders aren't stupid.  They know that until the community unites
against them and tells them all to sign an LSRA and thus come under
obligation to the NRPM and it's justification requirements, (or face the 
whois database being purged of their records) that they
can do whatever the hell they want.  Including changing the POC to
some other org, essentially transferring the block to someone else.
John Curran is just trying to say this in a nice fashion to you.  But
truthfully he has absolutely no lever over the non-LRSA Legacy holders,
because the one lever he can use, the community won't give to ARIN.

I frankly think that the situation now is more of a fairness thing,
it is grossly unfair to the LRSA signatories for some of their peers
to to continue to flout the intent of the LRSA and ignore it.  I do
not understand why the RSA holders unite against the Legacy holders
and I -definitely- don't understand why the LRSA signatories unite
against the non-LRSA Legacy holders, but until that happens, nothing
is going to change.

Ted


From aaron at wholesaleinternet.net  Tue Nov  2 19:10:17 2010
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Tue, 2 Nov 2010 18:10:17 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):
	GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion
	- Last Call (textrevised)
In-Reply-To: <4CD092B1.4090203@ipinc.net>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net>
Message-ID: <ce1f01cb7ae3$2770f470$7652dd50$@net>

I took John's comments here:

 

"The only they can't do is transfer resources outside of the policies, as
ARIN has to maintain the registration database in accordance with the
community policies as adopted."

 

To mean that ARIN would not update the registration database with
information for a new org if legacy space was transferred outside of the
ARIN rules.

 

My question about that is what happens to the integrity of the registration
data when Bob, who obtained a /16 back in 1990, decides to sell it off in
/24s to 256 different people?  Bob's given all those people LOAs with their
new /24s so they have no issues getting them routed but ARIN refuses to
change the registration.  Bob's not in control of those blocks anymore and
doesn't care to answer questions about them and the "community" has no way
of knowing who has those blocks and how to contact them.

 

Ted is correct.  The community has given ARIN the mandate to hold out the
carrot in the form of the LRSA but no one seems to want to give ARIN a
stick.  I would assume that's because the majority of the active ARIN
members, and by active I mean ones that participate on the list or at
meetings, are legacy holders themselves.

 

If ARIN, whose primary job is to maintain the registration data, can't
insure the integrity of that registration data any more then what's the
point?  Once one legacy holder kicks them in the groin and they don't fight
back it'll be a feeding frenzy.

 

I think the responsible thing for the community to do would be to give ARIN
the stick they need.

 

Aaron

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Ted Mittelstaedt
Sent: Tuesday, November 02, 2010 5:38 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal):
GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call
(textrevised)

 

On 11/2/2010 2:42 PM, John Curran wrote:
> On Nov 2, 2010, at 2:57 PM, Mike Burns wrote:
>
>> John,
>>
>> How was the registration database maintained in accordance with community
>> policies and yet the ORG and POC information for some legacy records has
>> been changed?
>
> Organizations with legacy address blocks may update their point of contact
> information (in fact, they can now do it online via ARIN Online, probably
> why we have more than 20,000 ARIN Online accounts... :-)  Remember, we are
> actively requesting all organizations to update their Point of Contact
(POC)
> information via electronic reminders.  More information about this program
> and its progress was given at the Atlanta meeting:
>
<https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobil
e_POC_Validation.pdf>
>
>> Are we to assume by your statements that the 16/8 block HAS to have an
LSRA
>
>> signed, since the original recipients of this legacy block are no longer
>> listed in the registration database?
>> And, if this is the case, can we assume that justification was provided
per
>> NRPM 8.2?
>

Mike, the problem with the Legacy holders is that the ARIN community has
never agreed to exert the RIR's authority over them.  There are many
historical reasons (some valid, some not) for this, but the Legacy
holders aren't stupid.  They know that until the community unites
against them and tells them all to sign an LSRA and thus come under
obligation to the NRPM and it's justification requirements, (or face the
whois database being purged of their records) that they
can do whatever the hell they want.  Including changing the POC to
some other org, essentially transferring the block to someone else.
John Curran is just trying to say this in a nice fashion to you.  But
truthfully he has absolutely no lever over the non-LRSA Legacy holders,
because the one lever he can use, the community won't give to ARIN.

I frankly think that the situation now is more of a fairness thing,
it is grossly unfair to the LRSA signatories for some of their peers
to to continue to flout the intent of the LRSA and ignore it.  I do
not understand why the RSA holders unite against the Legacy holders
and I -definitely- don't understand why the LRSA signatories unite
against the non-LRSA Legacy holders, but until that happens, nothing
is going to change.

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. 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1153 / Virus Database: 424/3233 - Release Date: 11/02/10

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

From BillD at cait.wustl.edu  Tue Nov  2 20:38:04 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 2 Nov 2010 19:38:04 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>

Never, in my memory, has the debate over recovery of legacy addresses been given more than superficial treatment.

Seems that the typical statements that stop debate is that such a course would be prohibitively expensive from a legal point of view and a real PR nightmare to boot...or at least not a 'value' proposition.

One way to have such a debate is to make a proposal through the regular process of the PDP.  If you feel strongly about your position, you are welcome to draft such a proposal and let the discussion begin....

bd

-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Aaron Wendel
Sent: Tue 11/2/2010 6:10 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion- Last Call (textrevised)
 
I took John's comments here:

 

"The only they can't do is transfer resources outside of the policies, as
ARIN has to maintain the registration database in accordance with the
community policies as adopted."

 

To mean that ARIN would not update the registration database with
information for a new org if legacy space was transferred outside of the
ARIN rules.

 

My question about that is what happens to the integrity of the registration
data when Bob, who obtained a /16 back in 1990, decides to sell it off in
/24s to 256 different people?  Bob's given all those people LOAs with their
new /24s so they have no issues getting them routed but ARIN refuses to
change the registration.  Bob's not in control of those blocks anymore and
doesn't care to answer questions about them and the "community" has no way
of knowing who has those blocks and how to contact them.

 

Ted is correct.  The community has given ARIN the mandate to hold out the
carrot in the form of the LRSA but no one seems to want to give ARIN a
stick.  I would assume that's because the majority of the active ARIN
members, and by active I mean ones that participate on the list or at
meetings, are legacy holders themselves.

 

If ARIN, whose primary job is to maintain the registration data, can't
insure the integrity of that registration data any more then what's the
point?  Once one legacy holder kicks them in the groin and they don't fight
back it'll be a feeding frenzy.

 

I think the responsible thing for the community to do would be to give ARIN
the stick they need.

 

Aaron

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Ted Mittelstaedt
Sent: Tuesday, November 02, 2010 5:38 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal):
GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call
(textrevised)

 

On 11/2/2010 2:42 PM, John Curran wrote:
> On Nov 2, 2010, at 2:57 PM, Mike Burns wrote:
>
>> John,
>>
>> How was the registration database maintained in accordance with community
>> policies and yet the ORG and POC information for some legacy records has
>> been changed?
>
> Organizations with legacy address blocks may update their point of contact
> information (in fact, they can now do it online via ARIN Online, probably
> why we have more than 20,000 ARIN Online accounts... :-)  Remember, we are
> actively requesting all organizations to update their Point of Contact
(POC)
> information via electronic reminders.  More information about this program
> and its progress was given at the Atlanta meeting:
>
<https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobil
e_POC_Validation.pdf>
>
>> Are we to assume by your statements that the 16/8 block HAS to have an
LSRA
>
>> signed, since the original recipients of this legacy block are no longer
>> listed in the registration database?
>> And, if this is the case, can we assume that justification was provided
per
>> NRPM 8.2?
>

Mike, the problem with the Legacy holders is that the ARIN community has
never agreed to exert the RIR's authority over them.  There are many
historical reasons (some valid, some not) for this, but the Legacy
holders aren't stupid.  They know that until the community unites
against them and tells them all to sign an LSRA and thus come under
obligation to the NRPM and it's justification requirements, (or face the
whois database being purged of their records) that they
can do whatever the hell they want.  Including changing the POC to
some other org, essentially transferring the block to someone else.
John Curran is just trying to say this in a nice fashion to you.  But
truthfully he has absolutely no lever over the non-LRSA Legacy holders,
because the one lever he can use, the community won't give to ARIN.

I frankly think that the situation now is more of a fairness thing,
it is grossly unfair to the LRSA signatories for some of their peers
to to continue to flout the intent of the LRSA and ignore it.  I do
not understand why the RSA holders unite against the Legacy holders
and I -definitely- don't understand why the LRSA signatories unite
against the non-LRSA Legacy holders, but until that happens, nothing
is going to change.

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. 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1153 / Virus Database: 424/3233 - Release Date: 11/02/10


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

From tedm at ipinc.net  Tue Nov  2 23:30:48 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 02 Nov 2010 20:30:48 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>
	<ce1f01cb7ae3$2770f470$7652dd50$@net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
Message-ID: <4CD0D768.3060905@ipinc.net>

On 11/2/2010 5:38 PM, Bill Darte wrote:
> Never, in my memory, has the debate over recovery of legacy addresses
> been given more than superficial treatment.
>

I think that this is because ultimately the goal isn't to take legacy
resources away that are IN USE.

Ultimately the goal should be to take legacy resources away that are 
either being hoarded, or are abandoned.

Aaron's example is towards the point, but it doesn't go far enough.
You see, as long as all of the 256 people who "bought" the /24's from
Bob are USING THEM then really there isn't a problem.

The problem is that 3 years after Bob has done his "sale" about
50% of the orgs he "sold" to are still using their /24's - and the
rest aren't.  Bob got his money, he's not interested anymore.  And
ARIN has no lever to make Bob get interested.

> Seems that the typical statements that stop debate is that such a course
> would be prohibitively expensive from a legal point of view

Rubbish.  If ARIN takes over an abandoned Legacy resource then since
it is abandoned, the original org that had it cannot suffer damages,
and since it hasn't suffered damages, it has no standing to sue in
court.

The problem is that since the original Legacy holder did NOT ever sign
an agreement with ARIN then ARIN has no contractual justification to 
take over an abandoned Legacy assignment even if they know it's unused, 
because so far the community has not given ARIN permission to do this 
via policy in the NRPM.

  and a real
> PR nightmare to boot...or at least not a 'value' proposition.
>
> One way to have such a debate is to make a proposal through the regular
> process of the PDP. If you feel strongly about your position, you are
> welcome to draft such a proposal and let the discussion begin....
>

Uh, I did.  And it was my first draft of the POC cleanup that 
kickstarted the later policy that ultimately resulted in the system
to purge abandoned POCs.

However, I did not address POCs that RESPONDED yet were NOT using
Legacy (or other) resources.

Right now, Legacy netblocks that are attached to POCs that ARIN
determines are non-respondent, can ultimately be freed up.  All ARIN
has to do is determine a POC is abandoned and when ALL POCs that
are on a particular Legacy block change to abandoned status, then
the resource is, (in my opinion) effectively freed, and (in my opinion)
ARIN should move it back into the free pool of assignable IPv4

I would hope that ARIN would just do this by themselves, but maybe
we need yet another policy to state the obvious.

But that does not answer the Legacy space that is unused, yet still
has a respondent POC on it.  Or Legacy space that the master block
has an abandoned POC but has active POC's that are in SWIPS that
were filed on parts of it.

And on top of that, not too long ago I thought the AC stated they would
no longer entertain drafts of policy changes that dealt entirely with
IPv4.  So please don't duck behind this "if you think you have a better
method then make a proposal" bullcrap.

There are too many people now in the ARIN community that just want to
bury IPv4 and really aren't interested in mining possibly usable IPv4
from Legacy resources.  They want to believe if we just ignore it we
can leave IPv4 behind in a few years and switch everything to IPv6 and
they won't believe this isn't going to happen right away until it just
doesn't happen right away.  Maybe they are right.  I just hope that if
they are not, that they start mining.

Ted


> bd
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of Aaron Wendel
> Sent: Tue 11/2/2010 6:10 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global
> Proposal):GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion-
> Last Call (textrevised)
>
> I took John's comments here:
>
>
>
> "The only they can't do is transfer resources outside of the policies, as
> ARIN has to maintain the registration database in accordance with the
> community policies as adopted."
>
>
>
> To mean that ARIN would not update the registration database with
> information for a new org if legacy space was transferred outside of the
> ARIN rules.
>
>
>
> My question about that is what happens to the integrity of the registration
> data when Bob, who obtained a /16 back in 1990, decides to sell it off in
> /24s to 256 different people? Bob's given all those people LOAs with their
> new /24s so they have no issues getting them routed but ARIN refuses to
> change the registration. Bob's not in control of those blocks anymore and
> doesn't care to answer questions about them and the "community" has no way
> of knowing who has those blocks and how to contact them.
>
>
>
> Ted is correct. The community has given ARIN the mandate to hold out the
> carrot in the form of the LRSA but no one seems to want to give ARIN a
> stick. I would assume that's because the majority of the active ARIN
> members, and by active I mean ones that participate on the list or at
> meetings, are legacy holders themselves.
>
>
>
> If ARIN, whose primary job is to maintain the registration data, can't
> insure the integrity of that registration data any more then what's the
> point? Once one legacy holder kicks them in the groin and they don't fight
> back it'll be a feeding frenzy.
>
>
>
> I think the responsible thing for the community to do would be to give ARIN
> the stick they need.
>
>
>
> Aaron
>
>
>
>
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Ted Mittelstaedt
> Sent: Tuesday, November 02, 2010 5:38 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal):
> GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call
> (textrevised)
>
>
>
> On 11/2/2010 2:42 PM, John Curran wrote:
>  > On Nov 2, 2010, at 2:57 PM, Mike Burns wrote:
>  >
>  >> John,
>  >>
>  >> How was the registration database maintained in accordance with
> community
>  >> policies and yet the ORG and POC information for some legacy records has
>  >> been changed?
>  >
>  > Organizations with legacy address blocks may update their point of
> contact
>  > information (in fact, they can now do it online via ARIN Online, probably
>  > why we have more than 20,000 ARIN Online accounts... :-) Remember, we are
>  > actively requesting all organizations to update their Point of Contact
> (POC)
>  > information via electronic reminders. More information about this program
>  > and its progress was given at the Atlanta meeting:
>  >
> <https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobil
> e_POC_Validation.pdf>
>  >
>  >> Are we to assume by your statements that the 16/8 block HAS to have an
> LSRA
>  >
>  >> signed, since the original recipients of this legacy block are no longer
>  >> listed in the registration database?
>  >> And, if this is the case, can we assume that justification was provided
> per
>  >> NRPM 8.2?
>  >
>
> Mike, the problem with the Legacy holders is that the ARIN community has
> never agreed to exert the RIR's authority over them. There are many
> historical reasons (some valid, some not) for this, but the Legacy
> holders aren't stupid. They know that until the community unites
> against them and tells them all to sign an LSRA and thus come under
> obligation to the NRPM and it's justification requirements, (or face the
> whois database being purged of their records) that they
> can do whatever the hell they want. Including changing the POC to
> some other org, essentially transferring the block to someone else.
> John Curran is just trying to say this in a nice fashion to you. But
> truthfully he has absolutely no lever over the non-LRSA Legacy holders,
> because the one lever he can use, the community won't give to ARIN.
>
> I frankly think that the situation now is more of a fairness thing,
> it is grossly unfair to the LRSA signatories for some of their peers
> to to continue to flout the intent of the LRSA and ignore it. I do
> not understand why the RSA holders unite against the Legacy holders
> and I -definitely- don't understand why the LRSA signatories unite
> against the non-LRSA Legacy holders, but until that happens, nothing
> is going to change.
>
> 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.
>
> _____
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1153 / Virus Database: 424/3233 - Release Date: 11/02/10
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From jcurran at arin.net  Wed Nov  3 00:36:27 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 3 Nov 2010 00:36:27 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <4CD0D768.3060905@ipinc.net>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu> <"75822E125BCB994F8
	446858C4B19F0D70AC125B367"@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<"75822E125BCB994F8446858C4B19
	F0D70AC125B37F"@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>
Message-ID: <48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>

On Nov 2, 2010, at 11:30 PM, Ted Mittelstaedt wrote:
> Right now, Legacy netblocks that are attached to POCs that ARIN
> determines are non-respondent, can ultimately be freed up.  All ARIN
> has to do is determine a POC is abandoned and when ALL POCs that
> are on a particular Legacy block change to abandoned status, then
> the resource is, (in my opinion) effectively freed, and (in my opinion)
> ARIN should move it back into the free pool of assignable IPv4
> 
> I would hope that ARIN would just do this by themselves, but maybe
> we need yet another policy to state the obvious.
> 
> But that does not answer the Legacy space that is unused, yet still
> has a respondent POC on it.  Or Legacy space that the master block
> has an abandoned POC but has active POC's that are in SWIPS that
> were filed on parts of it.

Ted - 
 
I'd like to raise the abstraction layer just a bit, in order to show why the issue of Legacy space holders is not quite as obvious as one might hope...

On one hand, it seems fairly clear: ARIN administers a database for the community accordingly to openly developed policies, and this database includes information about legacy address assignments which ARIN agreed to administer as the final successor registry after a long line of contractors managing this information per US Government cooperative agreements.  Before this time, legacy address space holders had nominal say in policies surrounding the direct management of the database, other than at global level through overall IETF guidance documents, such as RFC 2050.  The transition to a community-based organization provides a more direct route for participation in the governance and policy development, and everyone wins (run applause track here...)

However, it is also the case that there is a significant base of legacy space holders who simply want to make use of the number resources, and have no particular interest in number resource policy, ARIN's governance structure, or fee schedules, etc.  These legacy holders have use of unique number resources, and simply wish that to continue unmolested.  When ARIN came into operation, things seemed just fine for those legacy organizations, and the fact that many of the ISPs at that time joined ARIN, paid fees, and participated in its formation does not mean that every legacy organization wanted to do the same.

One can readily argue that services to legacy address space holders should be provided services without any change, in the same manner as they were at ARIN's inception, since that matches some expectations in the community.  One can also argue that legacy address space holders should all participate in ARIN, sign agreements like everyone else, pay reasonable fees to offset their operational costs, and conform to the policies that are adopted by the community.

In the end, the active ARIN community needs to treat the legacy address space community with respect, and legacy address space holders need to also respect the more active ARIN community. The Legacy RSA and Specified Transfer policy are examples of where common ground was found, and we need more of that going forward rather than calls for "exertion of authority".  There is no doubt that ARIN will administer the Whois database accordingly to the community developed policy, but folks should keep in mind that there are tens of thousands of legacy address holders who may not be active in ARIN but still deserve to be treated fairly.

/John

John Curran
President and CEO
ARIN





From jim at i2bnetworks.com  Wed Nov  3 00:53:17 2010
From: jim at i2bnetworks.com (Jim Fitzgerald)
Date: Tue, 2 Nov 2010 21:53:17 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last
	Call	(textrevised)
In-Reply-To: <48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu> <"75822E125BCB994F8
	446858C4B19F0D70AC125B367"@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<"75822E125BCB994F8446858C4B19
	F0D70AC125B37F"@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>
	<48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>
Message-ID: <817B1E62-04FA-4CD3-97D7-A230F957AF8D@i2bnetworks.com>

I question how seriously ARIN is even paying attention to active recovery of legacy resources.  I personally informed ARIN of two /24's assigned to defunct customers of ours that should be reclaimed.  These were ARIN direct assignments from the 90's.  No action has transpired.  We're announcing both currently and have been for 7+ years.  Both clients have been dead for 3+ years, there are no hosts in this space -- we're announcing it but its otherwise un-routed on our network.   The space was only noticed by us when we completed an audit of our IPv4 database.

Irrespective of "exertion of authority", how about lets reclaim the easy ones such as the two I just turned in.  If not even that can happen, how do I have confidence that ARIN is properly pressuring those who may be squatting on unused space simply because they signed up for it in 1990?  I don't take that an organization signed up for resources in the distant past to be an acceptable reason to permit such organizations to squat on the resources unused.  

I would encourage the community to favor and advocate for policies that will impart a bit of "stick" to the process.

-J

On Nov 2, 2010, at 9:36 PM, John Curran wrote:

> On Nov 2, 2010, at 11:30 PM, Ted Mittelstaedt wrote:
>> Right now, Legacy netblocks that are attached to POCs that ARIN
>> determines are non-respondent, can ultimately be freed up.  All ARIN
>> has to do is determine a POC is abandoned and when ALL POCs that
>> are on a particular Legacy block change to abandoned status, then
>> the resource is, (in my opinion) effectively freed, and (in my opinion)
>> ARIN should move it back into the free pool of assignable IPv4
>> 
>> I would hope that ARIN would just do this by themselves, but maybe
>> we need yet another policy to state the obvious.
>> 
>> But that does not answer the Legacy space that is unused, yet still
>> has a respondent POC on it.  Or Legacy space that the master block
>> has an abandoned POC but has active POC's that are in SWIPS that
>> were filed on parts of it.
> 
> Ted - 
> 
> I'd like to raise the abstraction layer just a bit, in order to show why the issue of Legacy space holders is not quite as obvious as one might hope...
> 
> On one hand, it seems fairly clear: ARIN administers a database for the community accordingly to openly developed policies, and this database includes information about legacy address assignments which ARIN agreed to administer as the final successor registry after a long line of contractors managing this information per US Government cooperative agreements.  Before this time, legacy address space holders had nominal say in policies surrounding the direct management of the database, other than at global level through overall IETF guidance documents, such as RFC 2050.  The transition to a community-based organization provides a more direct route for participation in the governance and policy development, and everyone wins (run applause track here...)
> 
> However, it is also the case that there is a significant base of legacy space holders who simply want to make use of the number resources, and have no particular interest in number resource policy, ARIN's governance structure, or fee schedules, etc.  These legacy holders have use of unique number resources, and simply wish that to continue unmolested.  When ARIN came into operation, things seemed just fine for those legacy organizations, and the fact that many of the ISPs at that time joined ARIN, paid fees, and participated in its formation does not mean that every legacy organization wanted to do the same.
> 
> One can readily argue that services to legacy address space holders should be provided services without any change, in the same manner as they were at ARIN's inception, since that matches some expectations in the community.  One can also argue that legacy address space holders should all participate in ARIN, sign agreements like everyone else, pay reasonable fees to offset their operational costs, and conform to the policies that are adopted by the community.
> 
> In the end, the active ARIN community needs to treat the legacy address space community with respect, and legacy address space holders need to also respect the more active ARIN community. The Legacy RSA and Specified Transfer policy are examples of where common ground was found, and we need more of that going forward rather than calls for "exertion of authority".  There is no doubt that ARIN will administer the Whois database accordingly to the community developed policy, but folks should keep in mind that there are tens of thousands of legacy address holders who may not be active in ARIN but still deserve to be treated fairly.
> 
> /John
> 
> John Curran
> President and CEO
> 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 jcurran at arin.net  Wed Nov  3 01:08:01 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 3 Nov 2010 01:08:01 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <817B1E62-04FA-4CD3-97D7-A230F957AF8D@i2bnetworks.com>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu> <"75822E125BCB994F8
	446858C4B19F0D70AC125B367"@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<"75822E125BCB994F8446858C4B19
	F0D70AC125B37F"@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>
	<48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>
	<817B1E62-04FA-4CD3-97D7-A230F957AF8D@i2bnetworks.com>
Message-ID: <4133B19E-26A0-413E-B0B5-BBD2503ABD11@arin.net>

On Nov 3, 2010, at 12:53 AM, Jim Fitzgerald wrote:

> I question how seriously ARIN is even paying attention to active recovery of legacy resources.  I personally informed ARIN of two /24's assigned to defunct customers of ours that should be reclaimed.  These were ARIN direct assignments from the 90's.  No action has transpired.  We're announcing both currently and have been for 7+ years.  Both clients have been dead for 3+ years, there are no hosts in this space -- we're announcing it but its otherwise un-routed on our network.   The space was only noticed by us when we completed an audit of our IPv4 database.
> 
> Irrespective of "exertion of authority", how about lets reclaim the easy ones such as the two I just turned in.  If not even that can happen, how do I have confidence that ARIN is properly pressuring those who may be squatting on unused space simply because they signed up for it in 1990?  I don't take that an organization signed up for resources in the distant past to be an acceptable reason to permit such organizations to squat on the resources unused.  
> 
> I would encourage the community to favor and advocate for policies that will impart a bit of "stick" to the process.

Jim - 
 
  As noted earlier, there is significant interest in reclaiming resources from organizations which are defunct.  Presently, there is a lack of policy in this area, so ARIN has no direction to "pressure those who may be squatting on unused space simply because they signed up for it in 1990".  We do occasionally see attempts to hijack such space, and can revoke subsequent to a fraud report, and may soon have some recovery of blocks when they have no valid POCs, but at present the most likely path that completely unused space with active contact is going to come back into the system is via the specified transfer policy.  I know that may not be your own preference, but it at least results in overall improved IPv4 resource utilization.

/John

John Curran
President and CEO
ARIN



From scottleibrand at gmail.com  Wed Nov  3 01:19:10 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 2 Nov 2010 22:19:10 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last
	Call	(textrevised)
In-Reply-To: <4133B19E-26A0-413E-B0B5-BBD2503ABD11@arin.net>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu> <"75822E125BCB994F8
	446858C4B19F0D70AC125B367"@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<"75822E125BCB994F8446858C4B19
	F0D70AC125B37F"@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>
	<48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>
	<817B1E62-04FA-4CD3-97D7-A230F957AF8D@i2bnetworks.com>
	<4133B19E-26A0-413E-B0B5-BBD2503ABD11@arin.net>
Message-ID: <AB2E35CC-AA80-4906-9FCF-054B90CEEAFB@gmail.com>

Jim,

If you (or Ted, or anyone else) want to help craft a policy proposal to direct ARIN to reclaim such resources, I suspect we could develop consensus around it. Feel free to let me (or any AC member) know if you need any assistance getting things started. 

Scott

On Nov 2, 2010, at 10:08 PM, John Curran <jcurran at arin.net> wrote:

> On Nov 3, 2010, at 12:53 AM, Jim Fitzgerald wrote:
> 
>> I question how seriously ARIN is even paying attention to active recovery of legacy resources.  I personally informed ARIN of two /24's assigned to defunct customers of ours that should be reclaimed.  These were ARIN direct assignments from the 90's.  No action has transpired.  We're announcing both currently and have been for 7+ years.  Both clients have been dead for 3+ years, there are no hosts in this space -- we're announcing it but its otherwise un-routed on our network.   The space was only noticed by us when we completed an audit of our IPv4 database.
>> 
>> Irrespective of "exertion of authority", how about lets reclaim the easy ones such as the two I just turned in.  If not even that can happen, how do I have confidence that ARIN is properly pressuring those who may be squatting on unused space simply because they signed up for it in 1990?  I don't take that an organization signed up for resources in the distant past to be an acceptable reason to permit such organizations to squat on the resources unused.  
>> 
>> I would encourage the community to favor and advocate for policies that will impart a bit of "stick" to the process.
> 
> Jim - 
> 
>  As noted earlier, there is significant interest in reclaiming resources from organizations which are defunct.  Presently, there is a lack of policy in this area, so ARIN has no direction to "pressure those who may be squatting on unused space simply because they signed up for it in 1990".  We do occasionally see attempts to hijack such space, and can revoke subsequent to a fraud report, and may soon have some recovery of blocks when they have no valid POCs, but at present the most likely path that completely unused space with active contact is going to come back into the system is via the specified transfer policy.  I know that may not be your own preference, but it at least results in overall improved IPv4 resource utilization.
> 
> /John
> 
> John Curran
> President and CEO
> 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 tedm at ipinc.net  Wed Nov  3 01:22:45 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 02 Nov 2010 22:22:45 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu> <"75822E125BCB994F8
	446858C4B19F0D70AC125B367"@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<"75822E125BCB994F8446858C4B19
	F0D70AC125B37F"@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>
	<48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>
Message-ID: <4CD0F1A5.5040507@ipinc.net>

On 11/2/2010 9:36 PM, John Curran wrote:
> On Nov 2, 2010, at 11:30 PM, Ted Mittelstaedt wrote:
>> Right now, Legacy netblocks that are attached to POCs that ARIN
>> determines are non-respondent, can ultimately be freed up.  All
>> ARIN has to do is determine a POC is abandoned and when ALL POCs
>> that are on a particular Legacy block change to abandoned status,
>> then the resource is, (in my opinion) effectively freed, and (in my
>> opinion) ARIN should move it back into the free pool of assignable
>> IPv4
>>
>> I would hope that ARIN would just do this by themselves, but maybe
>> we need yet another policy to state the obvious.
>>
>> But that does not answer the Legacy space that is unused, yet
>> still has a respondent POC on it.  Or Legacy space that the master
>> block has an abandoned POC but has active POC's that are in SWIPS
>> that were filed on parts of it.
>
> Ted -
>
> I'd like to raise the abstraction layer just a bit, in order to show
> why the issue of Legacy space holders is not quite as obvious as one
> might hope...
>
> On one hand, it seems fairly clear: ARIN administers a database for
> the community accordingly to openly developed policies, and this
> database includes information about legacy address assignments which
> ARIN agreed to administer as the final successor registry after a
> long line of contractors managing this information per US Government
> cooperative agreements.  Before this time, legacy address space
> holders had nominal say in policies surrounding the direct management
> of the database, other than at global level through overall IETF
> guidance documents, such as RFC 2050.  The transition to a
> community-based organization provides a more direct route for
> participation in the governance and policy development, and everyone
> wins (run applause track here...)
>
> However, it is also the case that there is a significant base of
> legacy space holders who simply want to make use of the number
> resources, and have no particular interest in number resource policy,
> ARIN's governance structure, or fee schedules, etc.  These legacy
> holders have use of unique number resources, and simply wish that to
> continue unmolested.  When ARIN came into operation, things seemed
> just fine for those legacy organizations, and the fact that many of
> the ISPs at that time joined ARIN, paid fees, and participated in its
> formation does not mean that every legacy organization wanted to do
> the same.
>
> One can readily argue that services to legacy address space holders
> should be provided services without any change, in the same manner as
> they were at ARIN's inception, since that matches some expectations
> in the community.  One can also argue that legacy address space
> holders should all participate in ARIN, sign agreements like everyone
> else, pay reasonable fees to offset their operational costs, and
> conform to the policies that are adopted by the community.
>
> In the end, the active ARIN community needs to treat the legacy
> address space community with respect, and legacy address space
> holders need to also respect the more active ARIN community. The
> Legacy RSA and Specified Transfer policy are examples of where common
> ground was found, and we need more of that going forward rather than
> calls for "exertion of authority".  There is no doubt that ARIN will
> administer the Whois database accordingly to the community developed
> policy, but folks should keep in mind that there are tens of
> thousands of legacy address holders who may not be active in ARIN but
> still deserve to be treated fairly.
>

Ah, but they AREN'T currently being treated fairly, because the
world has consumed all IPv4 space and needs more of it - and as
a result the world is switching to IPv6 - thus destroying the
usefulness of their assignments.

So I don't see that the legacy holders are being treated fairly
even with the ARIN community bending over backwards to leave them
alone.  in short, the idea that the legacy holders are being treated
fairly is rapidly becoming a sham, if it isn't already.

Also introducing the LRSA
has started the process of dividing the legacy holders into 2 camps.
The first camp are the folks like your referring to who just want to
be left alone.  The second camp are the folks who have acknowledged
that what they are doing affects the rest of the world and are making
the minimal effort to be responsible to the community by signing the
LRSA, even if they otherwise completely ignore the community once
they sign the document.

Naturally when ARIN wants to bring the legacy holders from the first
camp into the second, a honeyed approach is the first approach to
try.  Your call for "common ground" is a facet of this approach.

But human nature has shown that whenever you try to get a group
of people, or organizations to become more responsible to the community,
that eventually the honeyed approach succumbs to the law of diminishing
returns.

If you say that ARIN is seeing a steady stream of legacy holders
still signing the LRSA then I can understand that you believe that
we have not reached the area of diminishing returns on the honeyed
approach, and that you would prefer that the community not get the
pichforks and torches out and "kill the ogre" just yet.

But eventually the honeyed approach is going to play out.  At that
time, further attempts with the honey do a disservice to the camp
who has signed the LRSA.

My personal take on this is that IPv4 has a LOT more life in it
than most people are comfortable contemplating.  Surely, the "new
Tech" networking like cellular is going to embrace IPv6 right away.
But, I think that for many years much of the land infrastructure
in the US particularly will continue to use IPv4.  If my gut feel
is right then there will be continued pressure to "mine" the unused
IPv4 resources, and the community will eventually intently focus
on the legacy holders - and at that time, the legacy holders who
have NOT signed an LRSA are going to find the community has no more
sympathy for the "common ground" approach and will be going after
them with the pitchforks and torches.  At that time, calls for
"exertion of authority" are going to seem quite tame.

Ted




> /John
>
> John Curran President and CEO ARIN
>
>
>
>



From owen at delong.com  Wed Nov  3 05:54:29 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Nov 2010 02:54:29 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):
	GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion
	- Last Call (textrevised)
In-Reply-To: <ce1f01cb7ae3$2770f470$7652dd50$@net>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
Message-ID: <12BFB7D4-A224-4E74-87B6-78348A66C61D@delong.com>


> Ted is correct.  The community has given ARIN the mandate to hold out the carrot in the form of the LRSA but no one seems to want to give ARIN a stick.  I would assume that?s because the majority of the active ARIN members, and by active I mean ones that participate on the list or at meetings, are legacy holders themselves.
>  
A small NIT... Participation on list and at meetings is by the community, not the members.

Many people who participate, including some on the AC are NOT members. I myself am not
a member, but, I do work for an organization that is a member and am the DMR for another
client that is also a member.

Owen

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

From lear at cisco.com  Wed Nov  3 06:57:23 2010
From: lear at cisco.com (Eliot Lear)
Date: Wed, 03 Nov 2010 11:57:23 +0100
Subject: [arin-ppml] Draft Policy 2010-10 (Global
 Proposal):	GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion	-
 Last Call (textrevised)
In-Reply-To: <ce1f01cb7ae3$2770f470$7652dd50$@net>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>
	<ce1f01cb7ae3$2770f470$7652dd50$@net>
Message-ID: <4CD14013.7060706@cisco.com>

Aaron,

On 11/3/10 12:10 AM, Aaron Wendel wrote:
>
> I took John?s comments here:
>
>  
>
> ?The only they can't do is transfer resources outside of the policies,
> as ARIN has to maintain the registration database in accordance with
> the community policies as adopted.?
>
>  
>
> To mean that ARIN would not update the registration database with
> information for a new org if legacy space was transferred outside of
> the ARIN rules.
>
>  
>
> My question about that is what happens to the integrity of the
> registration data when Bob, who obtained a /16 back in 1990, decides
> to sell it off in /24s to 256 different people?  Bob?s given all those
> people LOAs with their new /24s so they have no issues getting them
> routed but ARIN refuses to change the registration.  Bob?s not in
> control of those blocks anymore and doesn?t care to answer questions
> about them and the ?community? has no way of knowing who has those
> blocks and how to contact them.
>

It's funny.  Your example demonstrates how a /16 would be put to better
use than it otherwise would be put to, today.

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

From bicknell at ufp.org  Wed Nov  3 10:02:52 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 3 Nov 2010 07:02:52 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last
	Call	(textrevised)
In-Reply-To: <4133B19E-26A0-413E-B0B5-BBD2503ABD11@arin.net>
References: <5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>
	<48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>
	<817B1E62-04FA-4CD3-97D7-A230F957AF8D@i2bnetworks.com>
	<4133B19E-26A0-413E-B0B5-BBD2503ABD11@arin.net>
Message-ID: <20101103140252.GB61109@ussenterprise.ufp.org>

In a message written on Wed, Nov 03, 2010 at 01:08:01AM -0400, John Curran wrote:
>   As noted earlier, there is significant interest in reclaiming resources from organizations which are defunct.  Presently, there is a lack of policy in this area, so ARIN has no direction to "pressure those who may be squatting on unused space simply because they signed up for it in 1990".  We do occasionally see attempts to hijack such space, and can revoke subsequent to a fraud report, and may soon have some recovery of blocks when they have no valid POCs, but at present the most likely path that completely unused space with active contact is going to come back into the system is via the specified transfer policy.  I know that may not be your own preference, but it at least results in overall improved IPv4 resource utilization.

If, as the original poster suggested, the original recipent
organization is defunct, how will the block make it through the
specified transfer policy?

Isn't the first step verifying that the resource holder can transfer
the block?  If it is issued to XYZ corp that is no more who can
authorize that transaction?  There are no more corproate officers.

Out of your method the more direct and faster path seems to be for the
ISP to file a fraud report on itself.  They are announcing their old
customers block and have "hijacked" it as a result.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101103/62092663/attachment.sig>

From jim at i2bnetworks.com  Wed Nov  3 11:48:27 2010
From: jim at i2bnetworks.com (Jim Fitzgerald)
Date: Wed, 3 Nov 2010 08:48:27 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <C8F6EE46.15EF6%marty@akamai.com>
References: <C8F6EE46.15EF6%marty@akamai.com>
Message-ID: <9AAAB680-023B-445D-8BE2-F70780D34D7E@i2bnetworks.com>


On Nov 3, 2010, at 7:47 AM, Hannigan, Martin wrote:

> 
> On 11/3/10 12:53 AM, "Jim Fitzgerald" <jim at i2bnetworks.com> wrote:
> 
>> I question how seriously ARIN is even paying attention to active recovery of
>> legacy resources.  I personally informed ARIN of two /24's assigned to defunct
>> customers of ours that should be reclaimed.  These were ARIN direct
>> assignments from the 90's.  No action has transpired.  We're announcing both
>> currently and have been for 7+ years.  Both clients have been dead for 3+
>> years, there are no hosts in this space -- we're announcing it but its
>> otherwise un-routed on our network.   The space was only noticed by us when we
>> completed an audit of our IPv4 database.
> 
> Why are you still advertising them if they are dead-ended then?
> 
> Best,
> -M<
> 

As mentioned in my post, due to error.  The original clients were not BGP enabled we announced these on their behalf.  Clients are now defunct.  Due to slop in our system we did not remove these announcements.   It was discovered some time ago in an audit.  

The blocks were reported to ARIN and we await further guidance as to what to do with them.  Meanwhile the blocks are unused & un-routed on our network but we're not sure what to do with them otherwise.  We may eventually put them to work for test hosts or other non-critical work while we await some resolution or guidance from ARIN or in the absence of any guidance.  We're just surprised that with the IPv4 shortage and so much noise about efficient utilization that nobody would want these...

-J



From cgrundemann at gmail.com  Wed Nov  3 12:06:26 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 3 Nov 2010 10:06:26 -0600
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy 2010-10
 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA Post
 Exhaustion- Last Call (textrevised))
Message-ID: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>

On Tue, Nov 2, 2010 at 23:08, John Curran <jcurran at arin.net> wrote:
>
> ?As noted earlier, there is significant interest in reclaiming resources from organizations which are defunct. ?Presently, there is a lack of policy in this area, so ARIN has no direction to "pressure those who may be squatting on unused space simply because they signed up for it in 1990". ?We do occasionally see attempts to hijack such space, and can revoke subsequent to a fraud report, and may soon have some recovery of blocks when they have no valid POCs, but at present the most likely path that completely unused space with active contact is going to come back into the system is via the specified transfer policy. ?I know that may not be your own preference, but it at least results in overall improved IPv4 resource utilization.

Some questions, for my own clarity:

 1) Today, under current policy and practice, if ARIN becomes aware of
a block of IPv4 that is assigned/allocated to a defunct organization
(and therefor must be unused); you do nothing?
2) Will a POC for an IPv4 block assigned/allocated to a known defunct
organization be allowed to authorize transfer of those resources under
current policy and practice? What happens if there are multiple POCs?
3) If the community adopted a policy which stated that unused
resources assigned/allocated to defunct organizations should be
reclaimed by ARIN, could ARIN reclaim such space? Would you actively
work to?

Thanks,
~Chris

>
> /John
>
> John Curran
> President and CEO
> 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From jcurran at arin.net  Wed Nov  3 12:20:08 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 3 Nov 2010 12:20:08 -0400
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>
References: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>
Message-ID: <4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>

On Nov 3, 2010, at 9:06 AM, Chris Grundemann wrote:

> On Tue, Nov 2, 2010 at 23:08, John Curran <jcurran at arin.net> wrote:
>> 
>>  As noted earlier, there is significant interest in reclaiming resources from organizations which are defunct.  Presently, there is a lack of policy in this area, so ARIN has no direction to "pressure those who may be squatting on unused space simply because they signed up for it in 1990".  We do occasionally see attempts to hijack such space, and can revoke subsequent to a fraud report, and may soon have some recovery of blocks when they have no valid POCs, but at present the most likely path that completely unused space with active contact is going to come back into the system is via the specified transfer policy.  I know that may not be your own preference, but it at least results in overall improved IPv4 resource utilization.
> 
> Some questions, for my own clarity:
> 
> 1) Today, under current policy and practice, if ARIN becomes aware of
> a block of IPv4 that is assigned/allocated to a defunct organization
> (and therefor must be unused); you do nothing?

Chris - There are numerous organizations that may appear to be defunct at first glance, but that does not make such a fact.  If we're notified by a contact from the original organization that they've shutdown, then we do reclaim the associated number resources.  Note that it's also quite possible that an organization has been acquired and no longer operates under the same name or location (but is still using the resources internally) or simply is choosing not to respond to ARIN's queries.

> 2) Will a POC for an IPv4 block assigned/allocated to a known defunct
> organization be allowed to authorize transfer of those resources under
> current policy and practice? What happens if there are multiple POCs?

See "known defunct" above.

> 3) If the community adopted a policy which stated that unused
> resources assigned/allocated to defunct organizations should be
> reclaimed by ARIN, could ARIN reclaim such space? Would you actively
> work to?

As long as we can understand the policy as defined, we will actively follow
any policy adopted.

/John

John Curran
President and CEO
ARIn




From marty at akamai.com  Wed Nov  3 12:28:41 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 3 Nov 2010 12:28:41 -0400
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
Message-ID: <C8F705F9.15F3B%marty@akamai.com>




On 11/3/10 12:20 PM, "John Curran" <jcurran at arin.net> wrote:

> On Nov 3, 2010, at 9:06 AM, Chris Grundemann wrote:
> 

> 
>> 3) If the community adopted a policy which stated that unused
>> resources assigned/allocated to defunct organizations should be
>> reclaimed by ARIN, could ARIN reclaim such space? Would you actively
>> work to?
> 
> As long as we can understand the policy as defined, we will actively follow
> any policy adopted.


I guess I'm wondering if there is a problem to solve? I thought that this
came up at a recent policy meeting; it "looks" like we aren't doing
anything, but in fact we are and that statistics would be posted to
demonstrate e.g. we have stats on fraud reporting and they clearly
demonstrate what some think is fraud really isn't.

Any way we can demonstrate if there really is a problem before writing a
proposal that is likely to be very difficult to reach consensus?

Best,

-M<



From jim at i2bnetworks.com  Wed Nov  3 12:48:05 2010
From: jim at i2bnetworks.com (Jim Fitzgerald)
Date: Wed, 3 Nov 2010 09:48:05 -0700
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
	2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations
	by the IANA Post Exhaustion- Last Call (textrevised))
In-Reply-To: <4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
References: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>
	<4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
Message-ID: <9F511332-D701-433C-AC98-AC7F3E2D2088@i2bnetworks.com>


On Nov 3, 2010, at 9:20 AM, John Curran wrote:

> On Nov 3, 2010, at 9:06 AM, Chris Grundemann wrote:
> 
>> On Tue, Nov 2, 2010 at 23:08, John Curran <jcurran at arin.net> wrote:
>>> 
>>> As noted earlier, there is significant interest in reclaiming resources from organizations which are defunct.  Presently, there is a lack of policy in this area, so ARIN has no direction to "pressure those who may be squatting on unused space simply because they signed up for it in 1990".  We do occasionally see attempts to hijack such space, and can revoke subsequent to a fraud report, and may soon have some recovery of blocks when they have no valid POCs, but at present the most likely path that completely unused space with active contact is going to come back into the system is via the specified transfer policy.  I know that may not be your own preference, but it at least results in overall improved IPv4 resource utilization.
>> 
>> Some questions, for my own clarity:
>> 
>> 1) Today, under current policy and practice, if ARIN becomes aware of
>> a block of IPv4 that is assigned/allocated to a defunct organization
>> (and therefor must be unused); you do nothing?
> 
> Chris - There are numerous organizations that may appear to be defunct at first glance, but that does not make such a fact.  If we're notified by a contact from the original organization that they've shutdown, then we do reclaim the associated number resources.  Note that it's also quite possible that an organization has been acquired and no longer operates under the same name or location (but is still using the resources internally) or simply is choosing not to respond to ARIN's queries.
> 

Now, of course in our example.. regardless of organization naming or "whats on paper", the block is still being announced by us.  Checking the global route tables we are the only one announcing the blocks in question and have been for many many years.   Its obviously not "in use", since we're announcing and not routing it and we're the only ones who are.  It simply won't work, so it cannot be "in use" at least not on the global Internet and thats what we're discussing here -- routable IPv4.  I'd be happy to stop announcing the space if that is the direction given by ARIN.  We're just using this live example to suss out what is being done with regards to reclamation in practice.

I guess this brings the related question -- does the community care the status of an organization when it comes to (precious) unused IPv4?  Do we let an organization go out of business, turn down its network, or end up in some indeterminate state, and camp out on a bunch of unused IPv4 simply because they "might exist" somewhere in some form?  If so, how long do we allow that?  My example blocks have been in this state for over 3 years.  Long enough?  Can we look at obvious indicators of use such as presence in the global routing tables?  If I turn down these blocks, they will not appear in the global routing tables any longer.. good enough?

My strong opinion is ARIN needs a stick to reclaim these things.  I am not entirely familiar with all of the politics regarding reclaiming IPv4 but it sure seems to me that these should be the easiest and obvious ones...  if we can't manage this, how will we ever manage the more difficult situations?  I really don't envy the job of the folks at ARIN and appreciate all that they do, but we've got to get this working in a sensible way, its only going to get worse if we don't.

-J

>> 2) Will a POC for an IPv4 block assigned/allocated to a known defunct
>> organization be allowed to authorize transfer of those resources under
>> current policy and practice? What happens if there are multiple POCs?
> 
> See "known defunct" above.
> 
>> 3) If the community adopted a policy which stated that unused
>> resources assigned/allocated to defunct organizations should be
>> reclaimed by ARIN, could ARIN reclaim such space? Would you actively
>> work to?
> 
> As long as we can understand the policy as defined, we will actively follow
> any policy adopted.
> 
> /John
> 
> John Curran
> President and CEO
> 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 bicknell at ufp.org  Wed Nov  3 13:02:46 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 3 Nov 2010 10:02:46 -0700
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
	2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations
	by the IANA Post Exhaustion- Last Call (textrevised))
In-Reply-To: <9F511332-D701-433C-AC98-AC7F3E2D2088@i2bnetworks.com>
References: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>
	<4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
	<9F511332-D701-433C-AC98-AC7F3E2D2088@i2bnetworks.com>
Message-ID: <20101103170246.GA72090@ussenterprise.ufp.org>

In a message written on Wed, Nov 03, 2010 at 09:48:05AM -0700, Jim Fitzgerald wrote:
> I guess this brings the related question -- does the community care the status of an organization when it comes to (precious) unused IPv4?  Do we let an organization go out of business, turn down its network, or end up in some indeterminate state, and camp out on a bunch of unused IPv4 simply because they "might exist" somewhere in some form?  If so, how long do we allow that?  My example blocks have been in this state for over 3 years.  Long enough?  Can we look at obvious indicators of use such as presence in the global routing tables?  If I turn down these blocks, they will not appear in the global routing tables any longer.. good enough?

In many ways the community has "solved" this problem going forward.
For all resources issued since the formation of ARIN there is a
yearly fee.  If that fee is no longer paid because a company goes
defunct the resource will be reclaimed after the fee is not paid
and a notice period has elapsed.  I'm sure John can elaborate, but
I think the "worst case" for a company that goes under the day after
it paid a renewal is something like 2 years.

The issue at hand is largely only in the domain of legacy space.
There is no yearly fee, and thus no mechanism by which ARIN can
determine that a resource is no longer in use.

In terms of IPv4 runout, I don't believe this is a very interesting
issue.  What you have is a lot of /24, err "Class C's" when they
were given out, that were handed to individuals and small businesses
when they were free for the asking and somewhere along the line the
company went under, the individual dropped out of the industry, or
whatnot.  We don't have a problem with "forgotten" /8's.

However, in terms of spammers having space to hijack, and the general
concept of Stweardship I think this is a significant problem and
needs to be addressed.  I've long been a proponent that legacy
holders need to be brought into the fold for this and other reasons.

IMHO the minimum that ARIN should do is have yearly contact with
anyone holding a number resource, including legacy holders.  I don't
know what the cost is to send a letter, get back a respose and check
off "yes that person still exists", but I can't imagine it is a
lot.  I would be very supportive of a policy that caused ARIN to
charge a fee to legacy holders of $5, or $10 or whatever that cost
is per year to "keep their database entry current" so the community
can detect situations like this one.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101103/292cd49c/attachment.sig>

From jcurran at arin.net  Wed Nov  3 13:12:40 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 3 Nov 2010 13:12:40 -0400
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <9F511332-D701-433C-AC98-AC7F3E2D2088@i2bnetworks.com>
References: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>
	<4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
	<9F511332-D701-433C-AC98-AC7F3E2D2088@i2bnetworks.com>
Message-ID: <3760C347-E43F-4EB1-B5AE-DBE1134813A2@arin.net>

Jim -  

Whether it is routed today or not doesn't reflect whether the organization assigned the   resources is defunct.  If you know the organization to have dissolved, can you send me some evidence to that effect (nearly anything from that organization: a letter saying they're going out of business, a legal notice, ...)? 

/John

On Nov 3, 2010, at 12:48 PM, "Jim Fitzgerald" <jim at i2bnetworks.com> wrote:

> 
> On Nov 3, 2010, at 9:20 AM, John Curran wrote:
> 
>> On Nov 3, 2010, at 9:06 AM, Chris Grundemann wrote:
>> 
>>> On Tue, Nov 2, 2010 at 23:08, John Curran <jcurran at arin.net> wrote:
>>>> 
>>>> As noted earlier, there is significant interest in reclaiming resources from organizations which are defunct.  Presently, there is a lack of policy in this area, so ARIN has no direction to "pressure those who may be squatting on unused space simply because they signed up for it in 1990".  We do occasionally see attempts to hijack such space, and can revoke subsequent to a fraud report, and may soon have some recovery of blocks when they have no valid POCs, but at present the most likely path that completely unused space with active contact is going to come back into the system is via the specified transfer policy.  I know that may not be your own preference, but it at least results in overall improved IPv4 resource utilization.
>>> 
>>> Some questions, for my own clarity:
>>> 
>>> 1) Today, under current policy and practice, if ARIN becomes aware of
>>> a block of IPv4 that is assigned/allocated to a defunct organization
>>> (and therefor must be unused); you do nothing?
>> 
>> Chris - There are numerous organizations that may appear to be defunct at first glance, but that does not make such a fact.  If we're notified by a contact from the original organization that they've shutdown, then we do reclaim the associated number resources.  Note that it's also quite possible that an organization has been acquired and no longer operates under the same name or location (but is still using the resources internally) or simply is choosing not to respond to ARIN's queries.
>> 
> 
> Now, of course in our example.. regardless of organization naming or "whats on paper", the block is still being announced by us.  Checking the global route tables we are the only one announcing the blocks in question and have been for many many years.   Its obviously not "in use", since we're announcing and not routing it and we're the only ones who are.  It simply won't work, so it cannot be "in use" at least not on the global Internet and thats what we're discussing here -- routable IPv4.  I'd be happy to stop announcing the space if that is the direction given by ARIN.  We're just using this live example to suss out what is being done with regards to reclamation in practice.
> 
> I guess this brings the related question -- does the community care the status of an organization when it comes to (precious) unused IPv4?  Do we let an organization go out of business, turn down its network, or end up in some indeterminate state, and camp out on a bunch of unused IPv4 simply because they "might exist" somewhere in some form?  If so, how long do we allow that?  My example blocks have been in this state for over 3 years.  Long enough?  Can we look at obvious indicators of use such as presence in the global routing tables?  If I turn down these blocks, they will not appear in the global routing tables any longer.. good enough?
> 
> My strong opinion is ARIN needs a stick to reclaim these things.  I am not entirely familiar with all of the politics regarding reclaiming IPv4 but it sure seems to me that these should be the easiest and obvious ones...  if we can't manage this, how will we ever manage the more difficult situations?  I really don't envy the job of the folks at ARIN and appreciate all that they do, but we've got to get this working in a sensible way, its only going to get worse if we don't.
> 
> -J
> 
>>> 2) Will a POC for an IPv4 block assigned/allocated to a known defunct
>>> organization be allowed to authorize transfer of those resources under
>>> current policy and practice? What happens if there are multiple POCs?
>> 
>> See "known defunct" above.
>> 
>>> 3) If the community adopted a policy which stated that unused
>>> resources assigned/allocated to defunct organizations should be
>>> reclaimed by ARIN, could ARIN reclaim such space? Would you actively
>>> work to?
>> 
>> As long as we can understand the policy as defined, we will actively follow
>> any policy adopted.
>> 
>> /John
>> 
>> John Curran
>> President and CEO
>> 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 cgrundemann at gmail.com  Wed Nov  3 13:16:43 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 3 Nov 2010 11:16:43 -0600
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <20101103170246.GA72090@ussenterprise.ufp.org>
References: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>
	<4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
	<9F511332-D701-433C-AC98-AC7F3E2D2088@i2bnetworks.com>
	<20101103170246.GA72090@ussenterprise.ufp.org>
Message-ID: <AANLkTinzJONJeMnQOWCtcvtqhZ3fF_b2XcMRLQQypFj+@mail.gmail.com>

On Wed, Nov 3, 2010 at 11:02, Leo Bicknell <bicknell at ufp.org> wrote:
<snip>
> The issue at hand is largely only in the domain of legacy space.
> There is no yearly fee, and thus no mechanism by which ARIN can
> determine that a resource is no longer in use.

Section 3.6 of the NRPM (the result of dp 2008-7), was meant to help
resolve this problem by requiring POCs to respond to an annual "ping."

> In terms of IPv4 runout, I don't believe this is a very interesting
> issue. ?What you have is a lot of /24, err "Class C's" when they
> were given out, that were handed to individuals and small businesses
> when they were free for the asking and somewhere along the line the
> company went under, the individual dropped out of the industry, or
> whatnot. ?We don't have a problem with "forgotten" /8's.

I suspect class Cs and especially Bs may be worth more than we might
now guess, shortly.

> However, in terms of spammers having space to hijack, and the general
> concept of Stweardship I think this is a significant problem and
> needs to be addressed. ?I've long been a proponent that legacy
> holders need to be brought into the fold for this and other reasons.

Hear, here.

> IMHO the minimum that ARIN should do is have yearly contact with
> anyone holding a number resource, including legacy holders. ?I don't
> know what the cost is to send a letter, get back a respose and check
> off "yes that person still exists", but I can't imagine it is a
> lot. ?I would be very supportive of a policy that caused ARIN to
> charge a fee to legacy holders of $5, or $10 or whatever that cost
> is per year to "keep their database entry current" so the community
> can detect situations like this one.

Wouldn't that require them to sign something (like an LRSA)?

~Chris

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


-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From tedm at ipinc.net  Wed Nov  3 13:32:34 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 03 Nov 2010 10:32:34 -0700
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <C8F705F9.15F3B%marty@akamai.com>
References: <C8F705F9.15F3B%marty@akamai.com>
Message-ID: <4CD19CB2.4010703@ipinc.net>

On 11/3/2010 9:28 AM, Hannigan, Martin wrote:
>
>
>
> On 11/3/10 12:20 PM, "John Curran"<jcurran at arin.net>  wrote:
>
>> On Nov 3, 2010, at 9:06 AM, Chris Grundemann wrote:
>>
>
>>
>>> 3) If the community adopted a policy which stated that unused
>>> resources assigned/allocated to defunct organizations should be
>>> reclaimed by ARIN, could ARIN reclaim such space? Would you actively
>>> work to?
>>
>> As long as we can understand the policy as defined, we will actively follow
>> any policy adopted.
>
>
> I guess I'm wondering if there is a problem to solve? I thought that this
> came up at a recent policy meeting; it "looks" like we aren't doing
> anything, but in fact we are

I will call BS on that.  Maybe for some stuff but there's a lot of work
that still needs to be done.

> and that statistics would be posted to
> demonstrate e.g. we have stats on fraud reporting and they clearly
> demonstrate what some think is fraud really isn't.
>
> Any way we can demonstrate if there really is a problem before writing a
> proposal that is likely to be very difficult to reach consensus?
>

Yes, Martin.

I have posted SEVERAL TIMES to this list the following data:

Back in 1999 we had a customer with a legacy /24, Leatherman Tools.
The block is NET-199-248-255-0-1 you can look it up in WHOIS.

The customer disconnected from us around 2002 and went to a competitor.
The competitor would not add this block into their routing and forced
the customer to renumber.  The customer renumbered their internal 
network into private numbers and forgot about this block.

For the next few years we used this block for various things,
our upstreams still were routing it.

Our former network admin, Byron, had left the company by then but
he had changed the POC e-mail on the block to his address at his
new company - because he used the same tech handle (BCO-ARIN) on
some other blocks he was admining.

Eventually we got our own allocations and stopped using this
block permanently.

Since then I have periodically checked the status of this block to
see how it is faring.

Our former admin's company went bankrupt and his e-mail address
on BCO-ARIN became owned by a domain name speculator sometime around
2006-2007 I think.

Today, the block is STILL IN the WHOIS.  The POC on it uses
hostmaster at speculator-owned-domain.com (hostmaster at hcorp.com)
so it probably is passing muster with the ARIN e-mail POC check.

The block does not appear in the DFZ and hasn't since 2004, when
we stopped advertising it.  In 2004 I told the ARIN hostmaster it
was abandoned.  I have e-mailed the hostmaster this at least once
since and faxed a bunch of junk to them showing the history.  And I have 
posted this to the list several times.

Frankly the block has become more useful (IMHO) disproving assertions
that ARIN's handling of legacy space is "working" than it ever was
carrying traffic.

If ARIN cannot "handle" this, even after I have used this example
multiple times to publically embarrass people who claim that everything
is A-OK, then YOU KNOW there is a problem.  You would think that
just for PR's sake that John or someone like that would pull the
hostmaster aside quietly and say "please take care of this so that
he can't squeak about it anymore" ;-)



Ted

> Best,
>
> -M<
>
> _______________________________________________
> 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 aaron at wholesaleinternet.net  Wed Nov  3 13:34:37 2010
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Wed, 3 Nov 2010 12:34:37 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last
	Call	(textrevised)
In-Reply-To: <4CD0D768.3060905@ipinc.net>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>
Message-ID: <cef201cb7b7d$64a2cb30$2de86190$@net>

My statement wasn't about reclaiming legacy space.  That's a debate that
never seems to end.  My statement and concern was about the integrity of the
registration data for blocks transferred outside the ARIN policy by orgs
that choose not to have anything to do with the rest of us.

 

In my example "Bob" is a real person.  He really does have a legacy /16 that
he is just waiting to sell off in pieces.  He has no desire to participate
in any of ARIN's processes and doesn't feel he's obligated to.

 

My question still stands:  What happens to the registration data when people
start buying legacy IP space outside ARIN's policies.  Does it become
useless, thus rendering ARIN's primary duty worthless?  Do we need to be
looking at some sort of policy that addresses "black market" IP transfers.
Is there a policy already for dealing with that?

 

John made a statement about playing fair with legacy holders.  I would be
interested in what the definition of "fair" is?  Is it those of us who
choose to play by the rules footing the bill for and cleaning up the messes
of those who don't?

 

Aaron

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Ted Mittelstaedt
Sent: Tuesday, November 02, 2010 10:31 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
for IPv4 Allocations by the IANA Post Exhaustion- Last Call (textrevised)

 

On 11/2/2010 5:38 PM, Bill Darte wrote:
> Never, in my memory, has the debate over recovery of legacy addresses
> been given more than superficial treatment.
>

I think that this is because ultimately the goal isn't to take legacy
resources away that are IN USE.

Ultimately the goal should be to take legacy resources away that are
either being hoarded, or are abandoned.

Aaron's example is towards the point, but it doesn't go far enough.
You see, as long as all of the 256 people who "bought" the /24's from
Bob are USING THEM then really there isn't a problem.

The problem is that 3 years after Bob has done his "sale" about
50% of the orgs he "sold" to are still using their /24's - and the
rest aren't.  Bob got his money, he's not interested anymore.  And
ARIN has no lever to make Bob get interested.

> Seems that the typical statements that stop debate is that such a course
> would be prohibitively expensive from a legal point of view

Rubbish.  If ARIN takes over an abandoned Legacy resource then since
it is abandoned, the original org that had it cannot suffer damages,
and since it hasn't suffered damages, it has no standing to sue in
court.

The problem is that since the original Legacy holder did NOT ever sign
an agreement with ARIN then ARIN has no contractual justification to
take over an abandoned Legacy assignment even if they know it's unused,
because so far the community has not given ARIN permission to do this
via policy in the NRPM.

  and a real
> PR nightmare to boot...or at least not a 'value' proposition.
>
> One way to have such a debate is to make a proposal through the regular
> process of the PDP. If you feel strongly about your position, you are
> welcome to draft such a proposal and let the discussion begin....
>

Uh, I did.  And it was my first draft of the POC cleanup that
kickstarted the later policy that ultimately resulted in the system
to purge abandoned POCs.

However, I did not address POCs that RESPONDED yet were NOT using
Legacy (or other) resources.

Right now, Legacy netblocks that are attached to POCs that ARIN
determines are non-respondent, can ultimately be freed up.  All ARIN
has to do is determine a POC is abandoned and when ALL POCs that
are on a particular Legacy block change to abandoned status, then
the resource is, (in my opinion) effectively freed, and (in my opinion)
ARIN should move it back into the free pool of assignable IPv4

I would hope that ARIN would just do this by themselves, but maybe
we need yet another policy to state the obvious.

But that does not answer the Legacy space that is unused, yet still
has a respondent POC on it.  Or Legacy space that the master block
has an abandoned POC but has active POC's that are in SWIPS that
were filed on parts of it.

And on top of that, not too long ago I thought the AC stated they would
no longer entertain drafts of policy changes that dealt entirely with
IPv4.  So please don't duck behind this "if you think you have a better
method then make a proposal" bullcrap.

There are too many people now in the ARIN community that just want to
bury IPv4 and really aren't interested in mining possibly usable IPv4
from Legacy resources.  They want to believe if we just ignore it we
can leave IPv4 behind in a few years and switch everything to IPv6 and
they won't believe this isn't going to happen right away until it just
doesn't happen right away.  Maybe they are right.  I just hope that if
they are not, that they start mining.

Ted


> bd
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of Aaron Wendel
> Sent: Tue 11/2/2010 6:10 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global
> Proposal):GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion-
> Last Call (textrevised)
>
> I took John's comments here:
>
>
>
> "The only they can't do is transfer resources outside of the policies, as
> ARIN has to maintain the registration database in accordance with the
> community policies as adopted."
>
>
>
> To mean that ARIN would not update the registration database with
> information for a new org if legacy space was transferred outside of the
> ARIN rules.
>
>
>
> My question about that is what happens to the integrity of the
registration
> data when Bob, who obtained a /16 back in 1990, decides to sell it off in
> /24s to 256 different people? Bob's given all those people LOAs with their
> new /24s so they have no issues getting them routed but ARIN refuses to
> change the registration. Bob's not in control of those blocks anymore and
> doesn't care to answer questions about them and the "community" has no way
> of knowing who has those blocks and how to contact them.
>
>
>
> Ted is correct. The community has given ARIN the mandate to hold out the
> carrot in the form of the LRSA but no one seems to want to give ARIN a
> stick. I would assume that's because the majority of the active ARIN
> members, and by active I mean ones that participate on the list or at
> meetings, are legacy holders themselves.
>
>
>
> If ARIN, whose primary job is to maintain the registration data, can't
> insure the integrity of that registration data any more then what's the
> point? Once one legacy holder kicks them in the groin and they don't fight
> back it'll be a feeding frenzy.
>
>
>
> I think the responsible thing for the community to do would be to give
ARIN
> the stick they need.
>
>
>
> Aaron
>
>
>
>
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Ted Mittelstaedt
> Sent: Tuesday, November 02, 2010 5:38 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal):
> GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call
> (textrevised)
>
>
>
> On 11/2/2010 2:42 PM, John Curran wrote:
>  > On Nov 2, 2010, at 2:57 PM, Mike Burns wrote:
>  >
>  >> John,
>  >>
>  >> How was the registration database maintained in accordance with
> community
>  >> policies and yet the ORG and POC information for some legacy records
has
>  >> been changed?
>  >
>  > Organizations with legacy address blocks may update their point of
> contact
>  > information (in fact, they can now do it online via ARIN Online,
probably
>  > why we have more than 20,000 ARIN Online accounts... :-) Remember, we
are
>  > actively requesting all organizations to update their Point of Contact
> (POC)
>  > information via electronic reminders. More information about this
program
>  > and its progress was given at the Atlanta meeting:
>  >
>
<https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobil
> e_POC_Validation.pdf>
>  >
>  >> Are we to assume by your statements that the 16/8 block HAS to have an
> LSRA
>  >
>  >> signed, since the original recipients of this legacy block are no
longer
>  >> listed in the registration database?
>  >> And, if this is the case, can we assume that justification was
provided
> per
>  >> NRPM 8.2?
>  >
>
> Mike, the problem with the Legacy holders is that the ARIN community has
> never agreed to exert the RIR's authority over them. There are many
> historical reasons (some valid, some not) for this, but the Legacy
> holders aren't stupid. They know that until the community unites
> against them and tells them all to sign an LSRA and thus come under
> obligation to the NRPM and it's justification requirements, (or face the
> whois database being purged of their records) that they
> can do whatever the hell they want. Including changing the POC to
> some other org, essentially transferring the block to someone else.
> John Curran is just trying to say this in a nice fashion to you. But
> truthfully he has absolutely no lever over the non-LRSA Legacy holders,
> because the one lever he can use, the community won't give to ARIN.
>
> I frankly think that the situation now is more of a fairness thing,
> it is grossly unfair to the LRSA signatories for some of their peers
> to to continue to flout the intent of the LRSA and ignore it. I do
> not understand why the RSA holders unite against the Legacy holders
> and I -definitely- don't understand why the LRSA signatories unite
> against the non-LRSA Legacy holders, but until that happens, nothing
> is going to change.
>
> 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.
>
> _____
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1153 / Virus Database: 424/3233 - Release Date: 11/02/10
>
>
>
>
> _______________________________________________
> 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. 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1153 / Virus Database: 424/3234 - Release Date: 11/02/10

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

From jcurran at arin.net  Wed Nov  3 13:47:22 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 3 Nov 2010 13:47:22 -0400
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <4CD19CB2.4010703@ipinc.net>
References: <C8F705F9.15F3B%marty@akamai.com> <4CD19CB2.4010703@ipinc.net>
Message-ID: <6D1E7A9A-9575-4619-8996-DDE479A33326@arin.net>

Ted -

     If we can determine that the organization that was assigned the resource is defunct, we will reclaim the resources.   Feel free to send me any documentation that you have that would help with that determination, and we will "handle" it as you request.  Do you know if the organization that was assigned the resources is defunct?  If they are not, we need someone authoritative from the organization to contact us (and if they're not using the numbers internally then it would indeed be very appropriate for them to return the address block to ARIN)

/John

On Nov 3, 2010, at 1:32 PM, Ted Mittelstaedt <tedm at ipinc.net<mailto:tedm at ipinc.net>> wrote:

I have posted SEVERAL TIMES to this list the following data:

Back in 1999 we had a customer with a legacy /24, Leatherman Tools.
The block is NET-199-248-255-0-1 you can look it up in WHOIS.

The customer disconnected from us around 2002 and went to a competitor.
The competitor would not add this block into their routing and forced
the customer to renumber.  The customer renumbered their internal network into private numbers and forgot about this block.

For the next few years we used this block for various things,
our upstreams still were routing it.

Our former network admin, Byron, had left the company by then but
he had changed the POC e-mail on the block to his address at his
new company - because he used the same tech handle (BCO-ARIN) on
some other blocks he was admining.

Eventually we got our own allocations and stopped using this
block permanently.

Since then I have periodically checked the status of this block to
see how it is faring.

Our former admin's company went bankrupt and his e-mail address
on BCO-ARIN became owned by a domain name speculator sometime around
2006-2007 I think.

Today, the block is STILL IN the WHOIS.  The POC on it uses
hostmaster at speculator-owned-domain.com<mailto:hostmaster at speculator-owned-domain.com> (hostmaster at hcorp.com<mailto:hostmaster at hcorp.com>)
so it probably is passing muster with the ARIN e-mail POC check.

The block does not appear in the DFZ and hasn't since 2004, when
we stopped advertising it.  In 2004 I told the ARIN hostmaster it
was abandoned.  I have e-mailed the hostmaster this at least once
since and faxed a bunch of junk to them showing the history.  And I have posted this to the list several times.

Frankly the block has become more useful (IMHO) disproving assertions
that ARIN's handling of legacy space is "working" than it ever was
carrying traffic.

If ARIN cannot "handle" this, even after I have used this example
multiple times to publically embarrass people who claim that everything
is A-OK, then YOU KNOW there is a problem.  You would think that
just for PR's sake that John or someone like that would pull the
hostmaster aside quietly and say "please take care of this so that
he can't squeak about it anymore" ;-)

Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101103/86de980b/attachment.htm>

From bicknell at ufp.org  Wed Nov  3 13:59:43 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 3 Nov 2010 10:59:43 -0700
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
	2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations
	by the IANA Post Exhaustion- Last Call (textrevised))
In-Reply-To: <AANLkTinzJONJeMnQOWCtcvtqhZ3fF_b2XcMRLQQypFj+@mail.gmail.com>
References: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>
	<4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
	<9F511332-D701-433C-AC98-AC7F3E2D2088@i2bnetworks.com>
	<20101103170246.GA72090@ussenterprise.ufp.org>
	<AANLkTinzJONJeMnQOWCtcvtqhZ3fF_b2XcMRLQQypFj+@mail.gmail.com>
Message-ID: <20101103175943.GA75185@ussenterprise.ufp.org>

In a message written on Wed, Nov 03, 2010 at 11:16:43AM -0600, Chris Grundemann wrote:
> Section 3.6 of the NRPM (the result of dp 2008-7), was meant to help
> resolve this problem by requiring POCs to respond to an annual "ping."

All this policy does is allow POC's to be marked as invalid, there
is no way to remove the POC, much less the resource record entirely.

To that end, it is a first step to identify the resources that might
be abandoned, but it is not the process to actually recover them.

> I suspect class Cs and especially Bs may be worth more than we might
> now guess, shortly.

I won't speculate on price, just their ability to "extend runout" or
serve the potential demand.  By those mesaures I think they are
insignificant.

> > IMHO the minimum that ARIN should do is have yearly contact with
> > anyone holding a number resource, including legacy holders. ?I don't
> > know what the cost is to send a letter, get back a respose and check
> > off "yes that person still exists", but I can't imagine it is a
> > lot. ?I would be very supportive of a policy that caused ARIN to
> > charge a fee to legacy holders of $5, or $10 or whatever that cost
> > is per year to "keep their database entry current" so the community
> > can detect situations like this one.
> 
> Wouldn't that require them to sign something (like an LRSA)?

Sign a check, most definately. :)

I'm not going to wade into which contract (RSA/LRSA, or something all
together new) would need to be signed.  I'm fairly sure the contract
issues can be resolved if folks really want to resolve them.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101103/1d3d9d5a/attachment.sig>

From marty at akamai.com  Wed Nov  3 15:17:50 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 3 Nov 2010 15:17:50 -0400
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <4CD19CB2.4010703@ipinc.net>
Message-ID: <C8F72D9E.15FF8%marty@akamai.com>




On 11/3/10 1:32 PM, "Ted Mittelstaedt" <tedm at ipinc.net> wrote:

> On 11/3/2010 9:28 AM, Hannigan, Martin wrote:
>> 
>> 
>> 
>> On 11/3/10 12:20 PM, "John Curran"<jcurran at arin.net>  wrote:
>> 
>>> On Nov 3, 2010, at 9:06 AM, Chris Grundemann wrote:
>>> 
>> 
>>> 
>>>> 3) If the community adopted a policy which stated that unused
>>>> resources assigned/allocated to defunct organizations should be
>>>> reclaimed by ARIN, could ARIN reclaim such space? Would you actively
>>>> work to?
>>> 
>>> As long as we can understand the policy as defined, we will actively follow
>>> any policy adopted.
>> 
>> 
>> I guess I'm wondering if there is a problem to solve? I thought that this
>> came up at a recent policy meeting; it "looks" like we aren't doing
>> anything, but in fact we are
> 
> I will call BS on that.  Maybe for some stuff but there's a lot of work
> that still needs to be done.
> 
>> and that statistics would be posted to
>> demonstrate e.g. we have stats on fraud reporting and they clearly
>> demonstrate what some think is fraud really isn't.
>> 
>> Any way we can demonstrate if there really is a problem before writing a
>> proposal that is likely to be very difficult to reach consensus?
>> 
> 
> Yes, Martin.
> 
> I have posted SEVERAL TIMES to this list the following data:
> 
> Back in 1999 we had a customer with a legacy /24, Leatherman Tools.
> The block is NET-199-248-255-0-1 you can look it up in WHOIS.


What's the ROI on recovering that, Ted? Marketing?

There are clearly easy pickings. In the end, those easy pickings are going
to come back into inventory without a huge amount of effort on our part.

There are certainly bigger fish to fry and sometimes subtlety works better
than the stick. I believe that as a community we've come to consensus on the
former. The latter will be most difficult to achieve.

Best,


-M<




From tedm at ipinc.net  Wed Nov  3 15:24:13 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 03 Nov 2010 12:24:13 -0700
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <6D1E7A9A-9575-4619-8996-DDE479A33326@arin.net>
References: <C8F705F9.15F3B%marty@akamai.com> <4CD19CB2.4010703@ipinc.net>
	<6D1E7A9A-9575-4619-8996-DDE479A33326@arin.net>
Message-ID: <4CD1B6DD.5010609@ipinc.net>

On 11/3/2010 10:47 AM, John Curran wrote:
> Ted -
>
> If we can determine that the organization that was assigned the resource
> is defunct, we will reclaim the resources. Feel free to send me any
> documentation that you have that would help with that determination, and
> we will "handle" it as you request. Do you know if the organization that
> was assigned the resources is defunct?

It isn't.  That is part of the problem with dealing with these legacy
resources, you see.

Back when the ISP I work for was very young (1994-1996 era) when a 
customer needed IP addressing they would file for what is now
"assigned PI" on behalf of the org wanting the space.  They did this
instead of the more obvious method of filing for a lot larger amount
of what we call "allocated PA" and then "renting" it or whatever.  I 
don't know if this was common practice then, or why they did it this 
way, it was before my time. I went to work for them in late '98.

Most of that space disappeared when customers left over the years and
took the space with them.  I don't have a list of it (unfortunately)
but as far as I know, Leatherman Tools was the only "exiting" customer
who was told point-blank by their new ISP (our competitor) that they
would not route the space, that we heard about.

It wasn't until around 2000 that I seriously started getting into
auditing our space, finding out where it came from and so on.  After
doing that, the 199 block was the only PI space we had.  Everything
else were were using was "allocated PA" that had been assigned to us
by the various feeds we were using (and we were then advertising) and
we had in turn assigned chunks of that to our customers.  (and it was
a real mess to untangle)

> If they are not, we need someone
> authoritative from the organization to contact us (and if they're not
> using the numbers internally then it would indeed be very appropriate
> for them to return the address block to ARIN)
>

I know they aren't using the numbers internally but chances that they
would contact you are just about nil.  This is a tool company, they
make knives that people carry around in their backpacks when they
hike in the woods.  They don't know anything about the Internet, they
use Easystreet Online services which has their own assignments from
ARIN.

If Easystreet contacted them and said "do this" they would do it, 
because they have an established relationship with them.  But I doubt
anyone from Easystreet is even on this list at all, despite that they
almost certainly pay ARIN a pile of money every year.

If ARIN contacted them and said "are you using this, if not then we
will take it" they wouldn't know what the hell you were talking about
and would just say "yes we are using it" because they wouldn't want
to spend the time investigating it.  time=money.

If ARIN contacted them and said "we are going to start billing you
for this, unless your not using it in which case we will take it back"
then they would THEN spend the employee time investigating and then
tell you "take it"

If we contacted them they would say something along the lines of
"who the hell are you" since I doubt anyone there remembers us.

And I do not believe Leatherman would behave any differently than the
majority of orgs out there.

If someone called or mailed the ISP I work at and said "you have 
something I want but if you don't want to give it up just say so and
I'll go away" then without blinking I would tell them to get lost.
In fact my fiduciary duty to my employer would be to do this, rather
than provide work time to some stranger who is not a customer and isn't 
paying us.

I spend time mailing you because your a vendor
of ours.  I spend time helping our customers because they are our 
customers.  I spend time on the mailing list because it's germane to
the job, and because things like cleaning up legacy space will 
ultimately help us.  But I don't have time during working hours to just 
provide time to people who have no relationship with the company I work 
for and just want to call me and bend my ear about, for example, cars,
(I do my own car service work) or motorcycles (I ride) or whatever else
that's non-work related.

I doubt that your any different.  So how can you reasonably ask a
company like Leatherman to spend any time on cleaning up a decade old
SNAFU that wasn't even caused by them and only involves them in the
most periphery manner?  Why would you reasonably expect them to give a 
tinkers damn about it?

And if for some reason, they ARE using this space internally, and I
am wrong, then why does ARIN tolerate such an obviously
wrong e-mail address on the POC?)

 From my point of view, Section 3.6 was never anything more than a
beginning of a much larger cleanup/organization drive.  But I wonder
if this is working - because by now ARIN should have gotten a NAK on an 
email to hostmaster at hcorp.com (the
e-mail on the Leatherman 199.2478.255 netblock) and
by now ARIN should be well on the way to determining that 199.248.255.0
is in a state of abandonment.  ARIN should have by now already mailed a
letter to the street address of that netblock giving them 30 days to
correct the e-mail address on the POC or have it declared invalid.  Or
so I would think.

But I would bet if you check with your people you will find that none
of this has happened.

I don't mean to be nasty about all of this and I'm well aware that it's
only a /24 but if ARIN has a good system for cleaning up these things
then it will work on ALL of the legacy blocks that are questionable,
whether a /8 or a /24.  I therefore conclude that if the ARIN system
is only working on stuff like /8's /9's /10's and so on, that it needs
work!

John, section 3.6 says:

"...If ARIN staff deems a POC to be completely and permanently abandoned 
or otherwise illegitimate..."

The "ARIN staff deems" that is in there was absolutely positively 
deliberate.  It was put there to allow ARIN staff the leeway to wield a 
club if they wanted to.  It is there because if ARIN wants to focus NOW 
on the large /9's and such that are likely bogus, and ignore the /24's, 
that they can, it allows section 3.6 to be unevenly applied.

But if ARIN feels that this "ARIN staff deems" does not allow them to 
wield a club then maybe the community should take it out.  Maybe that 
section should just read:

"If a POC is completely..."

followed by multiple paragraphs defining what constitutes abandonment,
with deadlines and time limits for specific things to happen.

Your the ARIN President, you tell us - is the language in Section 3.6
so vague that ARIN cannot take it as a mandate?  Does ARIN think that
Section 3.6 not constitute a club?  Or is the language perfectly OK and
give you what you need to go mining with the honey in one hand and the
club in the other - and clean up stuff like the 199.248.255 block?

Ted

> /John
>
> On Nov 3, 2010, at 1:32 PM, Ted Mittelstaedt <tedm at ipinc.net
> <mailto:tedm at ipinc.net>> wrote:
>
>> I have posted SEVERAL TIMES to this list the following data:
>>
>> Back in 1999 we had a customer with a legacy /24, Leatherman Tools.
>> The block is NET-199-248-255-0-1 you can look it up in WHOIS.
>>
>> The customer disconnected from us around 2002 and went to a competitor.
>> The competitor would not add this block into their routing and forced
>> the customer to renumber. The customer renumbered their internal
>> network into private numbers and forgot about this block.
>>
>> For the next few years we used this block for various things,
>> our upstreams still were routing it.
>>
>> Our former network admin, Byron, had left the company by then but
>> he had changed the POC e-mail on the block to his address at his
>> new company - because he used the same tech handle (BCO-ARIN) on
>> some other blocks he was admining.
>>
>> Eventually we got our own allocations and stopped using this
>> block permanently.
>>
>> Since then I have periodically checked the status of this block to
>> see how it is faring.
>>
>> Our former admin's company went bankrupt and his e-mail address
>> on BCO-ARIN became owned by a domain name speculator sometime around
>> 2006-2007 I think.
>>
>> Today, the block is STILL IN the WHOIS. The POC on it uses
>> hostmaster at speculator-owned-domain.com
>> <mailto:hostmaster at speculator-owned-domain.com> (hostmaster at hcorp.com
>> <mailto:hostmaster at hcorp.com>)
>> so it probably is passing muster with the ARIN e-mail POC check.
>>
>> The block does not appear in the DFZ and hasn't since 2004, when
>> we stopped advertising it. In 2004 I told the ARIN hostmaster it
>> was abandoned. I have e-mailed the hostmaster this at least once
>> since and faxed a bunch of junk to them showing the history. And I
>> have posted this to the list several times.
>>
>> Frankly the block has become more useful (IMHO) disproving assertions
>> that ARIN's handling of legacy space is "working" than it ever was
>> carrying traffic.
>>
>> If ARIN cannot "handle" this, even after I have used this example
>> multiple times to publically embarrass people who claim that everything
>> is A-OK, then YOU KNOW there is a problem. You would think that
>> just for PR's sake that John or someone like that would pull the
>> hostmaster aside quietly and say "please take care of this so that
>> he can't squeak about it anymore" ;-)
>>
>> Ted



From tedm at ipinc.net  Wed Nov  3 15:57:00 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 03 Nov 2010 12:57:00 -0700
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <C8F72D9E.15FF8%marty@akamai.com>
References: <C8F72D9E.15FF8%marty@akamai.com>
Message-ID: <4CD1BE8C.2050100@ipinc.net>

On 11/3/2010 12:17 PM, Hannigan, Martin wrote:
>
>
>
> On 11/3/10 1:32 PM, "Ted Mittelstaedt"<tedm at ipinc.net>  wrote:
>
>> On 11/3/2010 9:28 AM, Hannigan, Martin wrote:
>>>
>>>
>>>
>>> On 11/3/10 12:20 PM, "John Curran"<jcurran at arin.net>   wrote:
>>>
>>>> On Nov 3, 2010, at 9:06 AM, Chris Grundemann wrote:
>>>>
>>>
>>>>
>>>>> 3) If the community adopted a policy which stated that unused
>>>>> resources assigned/allocated to defunct organizations should be
>>>>> reclaimed by ARIN, could ARIN reclaim such space? Would you actively
>>>>> work to?
>>>>
>>>> As long as we can understand the policy as defined, we will actively follow
>>>> any policy adopted.
>>>
>>>
>>> I guess I'm wondering if there is a problem to solve? I thought that this
>>> came up at a recent policy meeting; it "looks" like we aren't doing
>>> anything, but in fact we are
>>
>> I will call BS on that.  Maybe for some stuff but there's a lot of work
>> that still needs to be done.
>>
>>> and that statistics would be posted to
>>> demonstrate e.g. we have stats on fraud reporting and they clearly
>>> demonstrate what some think is fraud really isn't.
>>>
>>> Any way we can demonstrate if there really is a problem before writing a
>>> proposal that is likely to be very difficult to reach consensus?
>>>
>>
>> Yes, Martin.
>>
>> I have posted SEVERAL TIMES to this list the following data:
>>
>> Back in 1999 we had a customer with a legacy /24, Leatherman Tools.
>> The block is NET-199-248-255-0-1 you can look it up in WHOIS.
>
>
> What's the ROI on recovering that, Ted? Marketing?
>

With translation you can put a company the size of Microsoft's Redmond
campus behind that /24.  So, you tell me.  What happens when there
are no more /24's and that is the only potential out there?

> There are clearly easy pickings. In the end, those easy pickings are going
> to come back into inventory without a huge amount of effort on our part.
>
> There are certainly bigger fish to fry and sometimes subtlety works better
> than the stick. I believe that as a community we've come to consensus on the
> former. The latter will be most difficult to achieve.
>

Sooner or later the big fish will be all fried.  Then you fry the 
smaller fish.  I have already said I did not think the community was
ready to get more aggressive.  But unless everyone turns their back
on IPv4 in the next few years, the community will get more aggressive
and they will be frying smaller fish.  Then, the latter will be much
easier to achieve.

Ted

> Best,
>
>
> -M<
>
>
>



From marty at akamai.com  Wed Nov  3 16:33:31 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 3 Nov 2010 16:33:31 -0400
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <4CD1BE8C.2050100@ipinc.net>
Message-ID: <C8F73F5B.16057%marty@akamai.com>




On 11/3/10 3:57 PM, "Ted Mittelstaedt" <tedm at ipinc.net> wrote:

> On 11/3/2010 12:17 PM, Hannigan, Martin wrote:
>> 
>> 
>> 


[ snip ]


>>>> Any way we can demonstrate if there really is a problem before writing a
>>>> proposal that is likely to be very difficult to reach consensus?
>>>> 
>>> 
>>> Yes, Martin.
>>> 
>>> I have posted SEVERAL TIMES to this list the following data:
>>> 
>>> Back in 1999 we had a customer with a legacy /24, Leatherman Tools.
>>> The block is NET-199-248-255-0-1 you can look it up in WHOIS.
>> 
>> 
>> What's the ROI on recovering that, Ted? Marketing?
>> 
> 
> With translation you can put a company the size of Microsoft's Redmond
> campus behind that /24.  So, you tell me.  What happens when there
> are no more /24's and that is the only potential out there?

Ted, 

Here you acknowledge that LEATHERMAN is legit:

    http://lists.arin.net/pipermail/arin-ppml/2007-July/007675.html


What exactly are they doing wrong? Not routing the addresses? Where are they
not in compliance?



>> There are clearly easy pickings. In the end, those easy pickings are going
>> to come back into inventory without a huge amount of effort on our part.
>> 
>> There are certainly bigger fish to fry and sometimes subtlety works better
>> than the stick. I believe that as a community we've come to consensus on the
>> former. The latter will be most difficult to achieve.
>> 
> 
> Sooner or later the big fish will be all fried.  Then you fry the
> smaller fish.  


You gave me an example of a /24. If that's what the community thinks are the
big fish we'll be bankrupt before we recover the equivalent of a /14.

Best,

-M<





From mueller at syr.edu  Wed Nov  3 17:21:24 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 3 Nov 2010 17:21:24 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global
	Proposal):	GlobalPolicy for IPv4 Allocations by the IANA Post
	Exhaustion	- Last Call (textrevised)
In-Reply-To: <ce1f01cb7ae3$2770f470$7652dd50$@net>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8
	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19
	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>
	<ce1f01cb7ae3$2770f470$7652dd50$@net>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC108D743@SUEX07-MBX-04.ad.syr.edu>

ARIN can maintain the integrity of the registration data by allowing the parties who transfer legacy resources to update their entry in WHOIS. Very simple.

--MM

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Aaron Wendel
Sent: Tuesday, November 02, 2010 7:10 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal): GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (textrevised)

I took John's comments here:

"The only they can't do is transfer resources outside of the policies, as ARIN has to maintain the registration database in accordance with the community policies as adopted."

To mean that ARIN would not update the registration database with information for a new org if legacy space was transferred outside of the ARIN rules.

My question about that is what happens to the integrity of the registration data when Bob, who obtained a /16 back in 1990, decides to sell it off in /24s to 256 different people?  Bob's given all those people LOAs with their new /24s so they have no issues getting them routed but ARIN refuses to change the registration.  Bob's not in control of those blocks anymore and doesn't care to answer questions about them and the "community" has no way of knowing who has those blocks and how to contact them.

Ted is correct.  The community has given ARIN the mandate to hold out the carrot in the form of the LRSA but no one seems to want to give ARIN a stick.  I would assume that's because the majority of the active ARIN members, and by active I mean ones that participate on the list or at meetings, are legacy holders themselves.

If ARIN, whose primary job is to maintain the registration data, can't insure the integrity of that registration data any more then what's the point?  Once one legacy holder kicks them in the groin and they don't fight back it'll be a feeding frenzy.

I think the responsible thing for the community to do would be to give ARIN the stick they need.

Aaron


From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt
Sent: Tuesday, November 02, 2010 5:38 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal): GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (textrevised)


On 11/2/2010 2:42 PM, John Curran wrote:
> On Nov 2, 2010, at 2:57 PM, Mike Burns wrote:
>
>> John,
>>
>> How was the registration database maintained in accordance with community
>> policies and yet the ORG and POC information for some legacy records has
>> been changed?
>
> Organizations with legacy address blocks may update their point of contact
> information (in fact, they can now do it online via ARIN Online, probably
> why we have more than 20,000 ARIN Online accounts... :-)  Remember, we are
> actively requesting all organizations to update their Point of Contact (POC)
> information via electronic reminders.  More information about this program
> and its progress was given at the Atlanta meeting:
> <https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobile_POC_Validation.pdf>
>
>> Are we to assume by your statements that the 16/8 block HAS to have an LSRA
>
>> signed, since the original recipients of this legacy block are no longer
>> listed in the registration database?
>> And, if this is the case, can we assume that justification was provided per
>> NRPM 8.2?
>

Mike, the problem with the Legacy holders is that the ARIN community has
never agreed to exert the RIR's authority over them.  There are many
historical reasons (some valid, some not) for this, but the Legacy
holders aren't stupid.  They know that until the community unites
against them and tells them all to sign an LSRA and thus come under
obligation to the NRPM and it's justification requirements, (or face the
whois database being purged of their records) that they
can do whatever the hell they want.  Including changing the POC to
some other org, essentially transferring the block to someone else.
John Curran is just trying to say this in a nice fashion to you.  But
truthfully he has absolutely no lever over the non-LRSA Legacy holders,
because the one lever he can use, the community won't give to ARIN.

I frankly think that the situation now is more of a fairness thing,
it is grossly unfair to the LRSA signatories for some of their peers
to to continue to flout the intent of the LRSA and ignore it.  I do
not understand why the RSA holders unite against the Legacy holders
and I -definitely- don't understand why the LRSA signatories unite
against the non-LRSA Legacy holders, but until that happens, nothing
is going to change.

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.

________________________________

No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 10.0.1153 / Virus Database: 424/3233 - Release Date: 11/02/10
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101103/7b7969f7/attachment.htm>

From jcurran at arin.net  Wed Nov  3 17:30:16 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 3 Nov 2010 17:30:16 -0400
Subject: [arin-ppml] Draft Policy 2010-10
	(Global	Proposal):	GlobalPolicy for IPv4 Allocations by the
	IANA Post	Exhaustion	- Last Call (textrevised)
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC108D743@SUEX07-MBX-04.ad.syr.edu>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu> <"75822E125BCB994F8
	446858C4B19F0D70AC125B367"@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<"75822E125BCB994F8446858C4B19
	F0D70AC125B37F"@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
	<75822E125BCB994F8446858C4B19F0D70AC108D743@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <6DD1D477-7E93-4D72-92F3-35E847312729@arin.net>

Milton -

    Yes, we update the registry automatically as part of the transfer process.

/John

On Nov 3, 2010, at 2:21 PM, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:

ARIN can maintain the integrity of the registration data by allowing the parties who transfer legacy resources to update their entry in WHOIS. Very simple.

--MM

From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Aaron Wendel
Sent: Tuesday, November 02, 2010 7:10 PM
To: <mailto:arin-ppml at arin.net> arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal): GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (textrevised)

I took John?s comments here:

?The only they can't do is transfer resources outside of the policies, as ARIN has to maintain the registration database in accordance with the community policies as adopted.?

To mean that ARIN would not update the registration database with information for a new org if legacy space was transferred outside of the ARIN rules.

My question about that is what happens to the integrity of the registration data when Bob, who obtained a /16 back in 1990, decides to sell it off in /24s to 256 different people?  Bob?s given all those people LOAs with their new /24s so they have no issues getting them routed but ARIN refuses to change the registration.  Bob?s not in control of those blocks anymore and doesn?t care to answer questions about them and the ?community? has no way of knowing who has those blocks and how to contact them.

Ted is correct.  The community has given ARIN the mandate to hold out the carrot in the form of the LRSA but no one seems to want to give ARIN a stick.  I would assume that?s because the majority of the active ARIN members, and by active I mean ones that participate on the list or at meetings, are legacy holders themselves.

If ARIN, whose primary job is to maintain the registration data, can?t insure the integrity of that registration data any more then what?s the point?  Once one legacy holder kicks them in the groin and they don?t fight back it?ll be a feeding frenzy.

I think the responsible thing for the community to do would be to give ARIN the stick they need.

Aaron


From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt
Sent: Tuesday, November 02, 2010 5:38 PM
To: <mailto:arin-ppml at arin.net> arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal): GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (textrevised)


On 11/2/2010 2:42 PM, John Curran wrote:
> On Nov 2, 2010, at 2:57 PM, Mike Burns wrote:
>
>> John,
>>
>> How was the registration database maintained in accordance with community
>> policies and yet the ORG and POC information for some legacy records has
>> been changed?
>
> Organizations with legacy address blocks may update their point of contact
> information (in fact, they can now do it online via ARIN Online, probably
> why we have more than 20,000 ARIN Online accounts... :-)  Remember, we are
> actively requesting all organizations to update their Point of Contact (POC)
> information via electronic reminders.  More information about this program
> and its progress was given at the Atlanta meeting:
> <<https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobile_POC_Validation.pdf>https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobile_POC_Validation.pdf>
>
>> Are we to assume by your statements that the 16/8 block HAS to have an LSRA
>
>> signed, since the original recipients of this legacy block are no longer
>> listed in the registration database?
>> And, if this is the case, can we assume that justification was provided per
>> NRPM 8.2?
>

Mike, the problem with the Legacy holders is that the ARIN community has
never agreed to exert the RIR's authority over them.  There are many
historical reasons (some valid, some not) for this, but the Legacy
holders aren't stupid.  They know that until the community unites
against them and tells them all to sign an LSRA and thus come under
obligation to the NRPM and it's justification requirements, (or face the
whois database being purged of their records) that they
can do whatever the hell they want.  Including changing the POC to
some other org, essentially transferring the block to someone else.
John Curran is just trying to say this in a nice fashion to you.  But
truthfully he has absolutely no lever over the non-LRSA Legacy holders,
because the one lever he can use, the community won't give to ARIN.

I frankly think that the situation now is more of a fairness thing,
it is grossly unfair to the LRSA signatories for some of their peers
to to continue to flout the intent of the LRSA and ignore it.  I do
not understand why the RSA holders unite against the Legacy holders
and I -definitely- don't understand why the LRSA signatories unite
against the non-LRSA Legacy holders, but until that happens, nothing
is going to change.

Ted
_______________________________________________
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>http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.

________________________________

No virus found in this message.
Checked by AVG - <http://www.avg.com> www.avg.com<http://www.avg.com>
Version: 10.0.1153 / Virus Database: 424/3233 - Release Date: 11/02/10

_______________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101103/c7d9a310/attachment.htm>

From mueller at syr.edu  Wed Nov  3 17:36:22 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 3 Nov 2010 17:36:22 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last	Call	(textrevised)
In-Reply-To: <817B1E62-04FA-4CD3-97D7-A230F957AF8D@i2bnetworks.com>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>	<4CCB08F9.1030303@umn.edu>
	<"75822E125BCB994F8	446858C4B19F0D70AC125B367"@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<"75822E125BCB994F8446858C4B19	F0D70AC125B37F"@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>
	<ce1f01cb7ae3$2770f470$7652dd50$@net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>	<48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>
	<817B1E62-04FA-4CD3-97D7-A230F957AF8D@i2bnetworks.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC108D744@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> Behalf Of Jim Fitzgerald
> 
> recovery of legacy resources.  I personally informed ARIN of two /24's
> assigned to defunct customers of ours that should be reclaimed.  These
> were ARIN direct assignments from the 90's.  No action has transpired.
> We're announcing both currently and have been for 7+ years.  Both
> clients have been dead for 3+ years, there are no hosts in this space --
> we're announcing it but its otherwise un-routed on our network.   The
> space was only noticed by us when we completed an audit of our IPv4
> database.

Jim
This is a perfect example of how the absence of market incentives results in wasteful use of resources. Encourage and facilitate market transfers - especially in the legacy space - and it places an economic premium on the discovery and accurate identification of the chain of custody over legacy resources. If that happens, you will be amazed at how quickly and effectively the records will be cleared up and acted upon. If ARIN positions itself as a neutral and accurate registry of title it will benefit from that process, because people will look to it as the authoritative source of information. 

OTOH asking ARIN to "pressure" people over whom it has zero contractual authority, for no purpose other than to preserve a kind of monopoly over the transfer process, will encourage bypass of ARIN. 

--MM


From cgrundemann at gmail.com  Wed Nov  3 17:38:04 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 3 Nov 2010 15:38:04 -0600
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <C8F705F9.15F3B%marty@akamai.com>
References: <4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
	<C8F705F9.15F3B%marty@akamai.com>
Message-ID: <AANLkTinpi=s+1oQ99VsMUy957_rpmm6_cVpB5Q9v0Hok@mail.gmail.com>

On Wed, Nov 3, 2010 at 10:28, Hannigan, Martin <marty at akamai.com> wrote:
>
> On 11/3/10 12:20 PM, "John Curran" <jcurran at arin.net> wrote:
>
>> On Nov 3, 2010, at 9:06 AM, Chris Grundemann wrote:
>>> 3) If the community adopted a policy which stated that unused
>>> resources assigned/allocated to defunct organizations should be
>>> reclaimed by ARIN, could ARIN reclaim such space? Would you actively
>>> work to?
>>
>> As long as we can understand the policy as defined, we will actively follow
>> any policy adopted.
>
> I guess I'm wondering if there is a problem to solve?

I am basing my opinion that there is potentially a need for policy
primarily on two things.

The first is that there is space out there that has no legitimate
responsible party. If there is not much of it, then the workload to
reclaim it will be small. If there is a lot of it than the reward for
doing so will be high. Seems like a win to the community either way to
me (not to stave off depletion but to uphold Whois integrity and fend
off hijackers, spammers et. al.).

The second is what John said today (and has said in different words in
the past): "...there is significant interest in reclaiming resources
from organizations which are defunct.  Presently, there is a lack of
policy in this area, so ARIN has no direction to "pressure those who
may be squatting on unused space..."." Not to mention space that
doesn't even have anyone squatting on it at all (yet).

> I thought that this
> came up at a recent policy meeting; it "looks" like we aren't doing
> anything, but in fact we are and that statistics would be posted to
> demonstrate e.g. we have stats on fraud reporting and they clearly
> demonstrate what some think is fraud really isn't.

I remember something similar being said in Atlanta about fraud related
audits but I don't recall anything regarding unused space or defunct
orgs.

I would love to see any facts and figures that ARIN or anyone else has
WRT abandoned space or space belonging to defunct organizations. As I
understand it, until there is actual fraud (falsifying Whois data)
ARIN pays little attention to this space at this time.

> Any way we can demonstrate if there really is a problem before writing a
> proposal that is likely to be very difficult to reach consensus?

If there is no problem (no unused space in the swamp), then the policy
should be easy to reach consensus because there will be nothing to
reclaim. If there is a problem, then I have a hard time seeing defunct
organizations actively barring the path to adoption... =)

Cheers,
~Chris

> Best,
>
> -M<
>
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From mueller at syr.edu  Wed Nov  3 17:40:54 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 3 Nov 2010 17:40:54 -0400
Subject: [arin-ppml] Draft Policy 2010-10
	(Global	Proposal):	GlobalPolicy for IPv4 Allocations by the
	IANA Post	Exhaustion	- Last Call (textrevised)
In-Reply-To: <6DD1D477-7E93-4D72-92F3-35E847312729@arin.net>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu> <"75822E125BCB994F8
	446858C4B19F0D70AC125B367"@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<"75822E125BCB994F8446858C4B19
	F0D70AC125B37F"@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
	<75822E125BCB994F8446858C4B19F0D70AC108D743@SUEX07-MBX-04.ad.syr.edu>
	<6DD1D477-7E93-4D72-92F3-35E847312729@arin.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC108D745@SUEX07-MBX-04.ad.syr.edu>

_Whose_ transfer process? ;-)

From: John Curran [mailto:jcurran at arin.net]
Sent: Wednesday, November 03, 2010 5:30 PM
To: Milton L Mueller
Cc: Aaron Wendel; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal): GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (textrevised)

Milton -

    Yes, we update the registry automatically as part of the transfer process.

/John

On Nov 3, 2010, at 2:21 PM, Milton L Mueller <mueller at syr.edu<mailto:mueller at syr.edu>> wrote:
ARIN can maintain the integrity of the registration data by allowing the parties who transfer legacy resources to update their entry in WHOIS. Very simple.

--MM

From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Aaron Wendel
Sent: Tuesday, November 02, 2010 7:10 PM
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal): GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (textrevised)

I took John?s comments here:

?The only they can't do is transfer resources outside of the policies, as ARIN has to maintain the registration database in accordance with the community policies as adopted.?

To mean that ARIN would not update the registration database with information for a new org if legacy space was transferred outside of the ARIN rules.

My question about that is what happens to the integrity of the registration data when Bob, who obtained a /16 back in 1990, decides to sell it off in /24s to 256 different people?  Bob?s given all those people LOAs with their new /24s so they have no issues getting them routed but ARIN refuses to change the registration.  Bob?s not in control of those blocks anymore and doesn?t care to answer questions about them and the ?community? has no way of knowing who has those blocks and how to contact them.

Ted is correct.  The community has given ARIN the mandate to hold out the carrot in the form of the LRSA but no one seems to want to give ARIN a stick.  I would assume that?s because the majority of the active ARIN members, and by active I mean ones that participate on the list or at meetings, are legacy holders themselves.

If ARIN, whose primary job is to maintain the registration data, can?t insure the integrity of that registration data any more then what?s the point?  Once one legacy holder kicks them in the groin and they don?t fight back it?ll be a feeding frenzy.

I think the responsible thing for the community to do would be to give ARIN the stick they need.

Aaron


From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt
Sent: Tuesday, November 02, 2010 5:38 PM
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal): GlobalPolicy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (textrevised)


On 11/2/2010 2:42 PM, John Curran wrote:
> On Nov 2, 2010, at 2:57 PM, Mike Burns wrote:
>
>> John,
>>
>> How was the registration database maintained in accordance with community
>> policies and yet the ORG and POC information for some legacy records has
>> been changed?
>
> Organizations with legacy address blocks may update their point of contact
> information (in fact, they can now do it online via ARIN Online, probably
> why we have more than 20,000 ARIN Online accounts... :-)  Remember, we are
> actively requesting all organizations to update their Point of Contact (POC)
> information via electronic reminders.  More information about this program
> and its progress was given at the Atlanta meeting:
> <https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Monday/Nobile_POC_Validation.pdf>
>
>> Are we to assume by your statements that the 16/8 block HAS to have an LSRA
>
>> signed, since the original recipients of this legacy block are no longer
>> listed in the registration database?
>> And, if this is the case, can we assume that justification was provided per
>> NRPM 8.2?
>

Mike, the problem with the Legacy holders is that the ARIN community has
never agreed to exert the RIR's authority over them.  There are many
historical reasons (some valid, some not) for this, but the Legacy
holders aren't stupid.  They know that until the community unites
against them and tells them all to sign an LSRA and thus come under
obligation to the NRPM and it's justification requirements, (or face the
whois database being purged of their records) that they
can do whatever the hell they want.  Including changing the POC to
some other org, essentially transferring the block to someone else.
John Curran is just trying to say this in a nice fashion to you.  But
truthfully he has absolutely no lever over the non-LRSA Legacy holders,
because the one lever he can use, the community won't give to ARIN.

I frankly think that the situation now is more of a fairness thing,
it is grossly unfair to the LRSA signatories for some of their peers
to to continue to flout the intent of the LRSA and ignore it.  I do
not understand why the RSA holders unite against the Legacy holders
and I -definitely- don't understand why the LRSA signatories unite
against the non-LRSA Legacy holders, but until that happens, nothing
is going to change.

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

________________________________

No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 10.0.1153 / Virus Database: 424/3233 - Release Date: 11/02/10
_______________________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101103/75834452/attachment.htm>

From jcurran at arin.net  Wed Nov  3 17:46:13 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 3 Nov 2010 17:46:13 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last	Call	(textrevised)
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC108D744@SUEX07-MBX-04.ad.syr.edu>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu>
	<"75822E125BCB994F8	446858C4B19F0D70AC125B367"@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<"75822E125BCB994F8446858C4B19	F0D70AC125B37F"@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<32136639FEF54CFDB80A5AB685165263@mike>
	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>
	<4CD092B1.4090203@ipinc.net> <ce1f01cb7ae3$2770f470$7652dd50$@net>
	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>
	<48D2E0BD-6D86-464C-9A03-1E6C4064E36E@arin.net>
	<817B1E62-04FA-4CD3-97D7-A230F957AF8D@i2bnetworks.com>
	<75822E125BCB994F8446858C4B19F0D70AC108D744@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <F89A39F9-E913-4268-BFA7-D1D7F6DE1616@arin.net>

On Nov 3, 2010, at 2:36 PM, Milton L Mueller <mueller at syr.edu> wrote:

> This is a perfect example of how the absence of market incentives results in wasteful use of resources. Encourage and facilitate market transfers - especially in the legacy space - and it places an economic premium on the discovery and accurate identification of the chain of custody over legacy resources. If that happens, you will be amazed at how quickly and effectively the records will be cleared up and acted upon. If ARIN positions itself as a neutral and accurate registry of title it will benefit from that process, because people will look to it as the authoritative source of information.

Milton -  At depletion, that very market incentives that you mention will be effect due to the specified transfer policy, and you are likely correct that these will quickly be cleaned up as the resources are put to better use.

/John

John Curran
President and CEO
ARIN 

From cgrundemann at gmail.com  Wed Nov  3 17:58:36 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 3 Nov 2010 15:58:36 -0600
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <4CCAF8EA.7080109@arin.net>
References: <4CCAF8EA.7080109@arin.net>
Message-ID: <AANLkTi=JE6ndjykQw0cgRWJk+zhd9xVPHZG90mcKQEkn@mail.gmail.com>

I support this policy as revised and hope that the AC will recommend
it to the board for adoption.

I believe that the revisions are editorial and that the NRO should be
able to easily homogenize any resultant textual differences in
versions ultimately adopted in other regions as a result.

I would also like to suggest that others make their opinions on this
policy known, to aid the AC's decision.

Thanks,
~Chris


On Fri, Oct 29, 2010 at 10:40, ARIN <info at arin.net> wrote:
> The ARIN Advisory Council (AC) met on 27 October 2010 and decided to
> send the following draft policy to last call:
>
> ? Draft Policy 2010-10 (Global Proposal): Global Policy for IPv4
> Allocations by the IANA Post Exhaustion
>
> The AC made the following revisions to the text:
> ?- The second sentence in section 2 was changed into two sentences.
> "Eligible address space includes addresses that are not designated as
> "special use" by an IETF RFC. Address space may only be returned by the
> issuing RIR."
> ?- In section 4, the sentence beginning "Exhaustion is defined as..."
> was changed to: "An RIR is considered at exhaustion when the inventory
> is less than the equivalent of a single /8 and is unable to further
> assign address space to its customers in units equal to or shorter than
> the longest of that RIR's policy defined minimum allocation unit."
>
> Feedback is encouraged during the last call period. All comments should
> be provided to the Public Policy Mailing List. Last call for 2010-10
> will expire on 12 November 2010. After last call the AC will conduct
> their last call review.
>
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From BillD at cait.wustl.edu  Wed Nov  3 18:05:30 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 3 Nov 2010 17:05:30 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
	Policy for IPv4 Allocations by the IANA Post Exhaustion -
	Last Call (text revised)
References: <4CCAF8EA.7080109@arin.net>
	<AANLkTi=JE6ndjykQw0cgRWJk+zhd9xVPHZG90mcKQEkn@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087915446@ex1.cait.wustl.edu>

As the Shepherd for this Draft Policy, I strongly support Chris' call for declarations of support or for something other.
bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Chris Grundemann
Sent: Wed 11/3/2010 4:58 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text revised)
 
I support this policy as revised and hope that the AC will recommend
it to the board for adoption.

I believe that the revisions are editorial and that the NRO should be
able to easily homogenize any resultant textual differences in
versions ultimately adopted in other regions as a result.

I would also like to suggest that others make their opinions on this
policy known, to aid the AC's decision.

Thanks,
~Chris


On Fri, Oct 29, 2010 at 10:40, ARIN <info at arin.net> wrote:
> The ARIN Advisory Council (AC) met on 27 October 2010 and decided to
> send the following draft policy to last call:
>
> ? Draft Policy 2010-10 (Global Proposal): Global Policy for IPv4
> Allocations by the IANA Post Exhaustion
>
> The AC made the following revisions to the text:
> ?- The second sentence in section 2 was changed into two sentences.
> "Eligible address space includes addresses that are not designated as
> "special use" by an IETF RFC. Address space may only be returned by the
> issuing RIR."
> ?- In section 4, the sentence beginning "Exhaustion is defined as..."
> was changed to: "An RIR is considered at exhaustion when the inventory
> is less than the equivalent of a single /8 and is unable to further
> assign address space to its customers in units equal to or shorter than
> the longest of that RIR's policy defined minimum allocation unit."
>
> Feedback is encouraged during the last call period. All comments should
> be provided to the Public Policy Mailing List. Last call for 2010-10
> will expire on 12 November 2010. After last call the AC will conduct
> their last call review.
>
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and 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.
>

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

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

From springer at inlandnet.com  Wed Nov  3 18:15:33 2010
From: springer at inlandnet.com (John Springer)
Date: Wed, 3 Nov 2010 15:15:33 -0700 (PDT)
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087915446@ex1.cait.wustl.edu>
References: <4CCAF8EA.7080109@arin.net>
	<AANLkTi=JE6ndjykQw0cgRWJk+zhd9xVPHZG90mcKQEkn@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915446@ex1.cait.wustl.edu>
Message-ID: <20101103151457.P9883@mail.inlandnet.com>

I support the policy as revised.

John Springer

On Wed, 3 Nov 2010, Bill Darte wrote:

> As the Shepherd for this Draft Policy, I strongly support Chris' call for declarations of support or for something other.
> bd
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of Chris Grundemann
> Sent: Wed 11/3/2010 4:58 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text revised)
>
> I support this policy as revised and hope that the AC will recommend
> it to the board for adoption.
>
> I believe that the revisions are editorial and that the NRO should be
> able to easily homogenize any resultant textual differences in
> versions ultimately adopted in other regions as a result.
>
> I would also like to suggest that others make their opinions on this
> policy known, to aid the AC's decision.
>
> Thanks,
> ~Chris
>
>
> On Fri, Oct 29, 2010 at 10:40, ARIN <info at arin.net> wrote:
>> The ARIN Advisory Council (AC) met on 27 October 2010 and decided to
>> send the following draft policy to last call:
>>
>> ? Draft Policy 2010-10 (Global Proposal): Global Policy for IPv4
>> Allocations by the IANA Post Exhaustion
>>
>> The AC made the following revisions to the text:
>> ?- The second sentence in section 2 was changed into two sentences.
>> "Eligible address space includes addresses that are not designated as
>> "special use" by an IETF RFC. Address space may only be returned by the
>> issuing RIR."
>> ?- In section 4, the sentence beginning "Exhaustion is defined as..."
>> was changed to: "An RIR is considered at exhaustion when the inventory
>> is less than the equivalent of a single /8 and is unable to further
>> assign address space to its customers in units equal to or shorter than
>> the longest of that RIR's policy defined minimum allocation unit."
>>
>> Feedback is encouraged during the last call period. All comments should
>> be provided to the Public Policy Mailing List. Last call for 2010-10
>> will expire on 12 November 2010. After last call the AC will conduct
>> their last call review.
>>
>> The draft policy text is below and available at:
>> https://www.arin.net/policy/proposals/
>>
>> The ARIN Policy Development Process is available at:
>> https://www.arin.net/policy/pdp.html
>>
>> Regards,
>>
>> Communications and 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.
>>
>
> -- 
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>

From jcurran at arin.net  Wed Nov  3 20:57:02 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 3 Nov 2010 20:57:02 -0400
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <20101103195750.GA1796@vacation.karoshi.com.>
References: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>
	<4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
	<20101103195750.GA1796@vacation.karoshi.com.>
Message-ID: <701BD155-9837-4FE7-B729-0D3E12EC16B9@arin.net>

On Nov 3, 2010, at 12:58 PM, "bmanning at vacation.karoshi.com" <bmanning at vacation.karoshi.com> wrote:

> On Wed, Nov 03, 2010 at 12:20:08PM -0400, John Curran wrote:
>> 
>>> 3) If the community adopted a policy which stated that unused
>>> resources assigned/allocated to defunct organizations should be
>>> reclaimed by ARIN, could ARIN reclaim such space? Would you actively
>>> work to?
>> 
>> As long as we can understand the policy as defined, we will actively follow
>> any policy adopted.
> 
> 	i suspect you might temper that observation with the caveat that 
> 	ARIN will honour any existant contractual obligations; e.g. if
> 	the members of the community adopt a policy that would render 
> 	an existing contractual obligation null/void, ARIN might have to 
> 	push back on said policy.  no?

Yes, ARIN honors its contractual obligations, and wouldn't push back on the policy but would implement as best it can while respecting its obligations and applicable law.

In this case where the context is a hypothetical policy regarding resources that were held by now defunct organizations, the point is probably moot, as ARIN unlikely to have any relevant contractual obligations (particularly to organizations which no longer exist.)

/John 

John Curran
President & CEO
ARIN
> 
>> 
>> 


From marty at akamai.com  Wed Nov  3 23:01:48 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 3 Nov 2010 23:01:48 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <AANLkTi=JE6ndjykQw0cgRWJk+zhd9xVPHZG90mcKQEkn@mail.gmail.com>
Message-ID: <C8F79A5C.16144%marty@akamai.com>




On 11/3/10 5:58 PM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:

> I support this policy as revised and hope that the AC will recommend
> it to the board for adoption.
> 
> I believe that the revisions are editorial and that the NRO should be
> able to easily homogenize any resultant textual differences in
> versions ultimately adopted in other regions as a result.
> 
> I would also like to suggest that others make their opinions on this
> policy known, to aid the AC's decision.


40:5. :-) Supported, again.

Best,

-M<



From rfg at tristatelogic.com  Thu Nov  4 06:22:26 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Thu, 04 Nov 2010 03:22:26 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <4CD0D768.3060905@ipinc.net> 
Message-ID: <24271.1288866146@tristatelogic.com>


In message <4CD0D768.3060905 at ipinc.net>, Ted Mittelstaedt <tedm at ipinc.net>
 wrote:

>On 11/2/2010 5:38 PM, Bill Darte wrote:
>> Never, in my memory, has the debate over recovery of legacy addresses
>> been given more than superficial treatment.
>>
>
>I think that this is because ultimately the goal isn't to take legacy
>resources away that are IN USE.
>
>Ultimately the goal should be to take legacy resources away that are 
>either being hoarded, or are abandoned.
>
>Aaron's example is towards the point, but it doesn't go far enough.
>You see, as long as all of the 256 people who "bought" the /24's from
>Bob are USING THEM then really there isn't a problem.
>
>The problem is that 3 years after Bob has done his "sale" about
>50% of the orgs he "sold" to are still using their /24's - and the
>rest aren't.  Bob got his money, he's not interested anymore.  And
>ARIN has no lever to make Bob get interested.

Going from the abstract to the concrete...

149.47.0.0/16 is/was a legacy assignment.  It was originally allocated
to a NYC ISP.  That ISP folded, and the original owner sold what remained
of the ISP's assets, including the /16, to an ISP in Canada named Rackster.
Rackster then apparently resold the entire /16 to a spammer in Ohio named
Sean Q, Page.

At present, it appears that Mr. Page is using very little of that /16.
It would be Nice if ARIN could get some or all of that back.

>There are too many people now in the ARIN community that just want to
>bury IPv4 and really aren't interested in mining possibly usable IPv4
>from Legacy resources.  They want to believe if we just ignore it we
>can leave IPv4 behind in a few years and switch everything to IPv6 and
>they won't believe this isn't going to happen right away until it just
>doesn't happen right away.  Maybe they are right.  I just hope that if
>they are not, that they start mining.

I think they are wrong, and within 12 months, the spaghetti is going to
start to hit the fan.


From rfg at tristatelogic.com  Thu Nov  4 06:49:23 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Thu, 04 Nov 2010 03:49:23 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <9AAAB680-023B-445D-8BE2-F70780D34D7E@i2bnetworks.com> 
Message-ID: <25869.1288867763@tristatelogic.com>


In message <9AAAB680-023B-445D-8BE2-F70780D34D7E at i2bnetworks.com>, 
Jim Fitzgerald <jim at i2bnetworks.com> wrote:

>The blocks were reported to ARIN and we await further guidance as to what to d
>o with them.  Meanwhile the blocks are unused & un-routed on our network but w
>e're not sure what to do with them otherwise.  We may eventually put them to w
>ork for test hosts or other non-critical work while we await some resolution o
>r guidance from ARIN or in the absence of any guidance.  We're just surprised 
>that with the IPv4 shortage and so much noise about efficient utilization that
> nobody would want these...


For my part, I am likewise surprised at the degree of outright unmitigated
FRAUD that is occuring in the ARIN region, *and* I'm also quite surprised
at ARIN's apparent total disinterest in the vast gobs of IPv4 space being
wasted on account of all that.

I have been waiting weeks now for John Curran to answer my simple question:
i.e. What does, and what does not constitute "utilization fraud", and
although I see that he's found time to participate here, he apparently
hasn't found time to answer that question, the answer to which would help
me to spot even MORE utilization fraud than I am already aware of.


Regards,
rfg


P.S.  For some examples of utilization fraud see the allocations for
the various non-existant pseudo-entities that currently hold:

65.175.0.0/24
65.175.12.0/25
65.175.17.0/24
65.175.25.0/24
65.175.33.0/24
65.175.28.0/24
65.175.29.0/24

66.7.128.0/28
66.17.238.0/24
66.17.248.0/24
66.17.202.0/24
66.17.156.0/24
66.17.234.0/24
66.17.235.0/24
66.17.169.0/24
66.17.170.0/24
66.17.171.0/24

66.54.206.0/24
66.54.207.0/24
66.54.224.0/24

...as well as any & all of the IP blocks currently routed by the (defunct?)
snowshoe spam front company "RockSolid Network, Inc.", aka AS33475 (which
ads up to a considerable amount of space, BTW).


P.P.S. I agree with the prior poster who asserted that IPv4 may yet have a
lot of life left in it... well... it *would* have an almost infinite life
left in it if it were not for (a) various hardware vendors who have a clear
agenda to create an "upgrade cycle" (whether one is actually needed or not)
and if it were not for (b) IPv4 being bled dry by (1) snowshoe spammers and
(2) people who refuse to learn how to use NAT and (3) people who refuse to
learn how to properly configure web servers and mail servers and name servers
so that they will support multiple domains.


From owen at delong.com  Thu Nov  4 06:53:17 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Nov 2010 03:53:17 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <24271.1288866146@tristatelogic.com>
References: <24271.1288866146@tristatelogic.com>
Message-ID: <883BFCDD-B3D6-458D-B4AC-4D18F6007993@delong.com>

> 
>> There are too many people now in the ARIN community that just want to
>> bury IPv4 and really aren't interested in mining possibly usable IPv4
>> from Legacy resources.  They want to believe if we just ignore it we
>> can leave IPv4 behind in a few years and switch everything to IPv6 and
>> they won't believe this isn't going to happen right away until it just
>> doesn't happen right away.  Maybe they are right.  I just hope that if
>> they are not, that they start mining.
> 
> I think they are wrong, and within 12 months, the spaghetti is going to
> start to hit the fan.

First, I don't think that is an entirely fair characterization.

I do think that our efforts are better spent transitioning to IPv6 than attempting
to mine for diminishing (non-existant?) IPv4 resources.

Even if we succeed in mining for IPv4, it's a temporary solution where deploying
IPv6 offers a sustainable solution for a much longer term.

Is everything going to magically switch overnight? No.

However, if you're faced with a post-runout network deployment, the question
isn't so much one of whether the world has gone IPv6 yet or not as it is one
of whether it makes sense to take heroic measures to add your network to the
IPv4 network living on life support at best, or, add it to a growing and vibrant
IPv6 internet.

If you're expanding an existing deployment beyond the existing address space,
then, it's a slightly harder version of the same question. Limitations or issues
with your legacy software may make IPv4 temporarily more attractive, but,
if you go down that path, make sure you do it with the realization that it is a
dead end and you will still have to reverse course and go down the IPv6
road later.

Finally, if you think it's going to take 12 months for the IPv4 spaghetti to make
contact with the whirling blades, you aren't paying attention. I think it will
be somewhat sooner. All the more reason to focus on IPv6 deployment now
rather than continue throwing resources at IPv4 rescue efforts.

Owen



From jcurran at arin.net  Thu Nov  4 08:26:33 2010
From: jcurran at arin.net (John Curran)
Date: Thu, 4 Nov 2010 08:26:33 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <25869.1288867763@tristatelogic.com>
References: <25869.1288867763@tristatelogic.com>
Message-ID: <9E11B785-FFA2-4C62-824B-23B5F6071673@arin.net>

On Nov 4, 2010, at 3:49 AM, Ronald F. Guilmette wrote:
> 
> For my part, I am likewise surprised at the degree of outright unmitigated
> FRAUD that is occuring in the ARIN region, *and* I'm also quite surprised
> at ARIN's apparent total disinterest in the vast gobs of IPv4 space being
> wasted on account of all that.
> 
> I have been waiting weeks now for John Curran to answer my simple question:
> i.e. What does, and what does not constitute "utilization fraud", and
> although I see that he's found time to participate here, he apparently
> hasn't found time to answer that question, the answer to which would help
> me to spot even MORE utilization fraud than I am already aware of.

Good morning Ron - 

As already noted (as the top of fraud reporting page: https://www.arin.net/resources/fraud/index.html), we can respond to Number Resource Fraud which includes "the submission of falsified utilization or organization information, unauthorized changes to data in ARIN's WHOIS, hijacking of number resources in ARIN's database, or fraudulent transfers."

You've already successfully made use of this process, and we've removing thirteen resource registrations and are working through the M&A transfer process with holders of several of the remaining blocks to insure that they actually valid.  This is not a quick process, but we do take registry integrity as a priority.  

Recognize the challenge in that this region has thousands of registration records which were already quite "aged" when ARIN was founded, and we maintained the existing passive registry practices which did not specify contacting all allocation holders periodically to update records, nor were there even clear policies for obsolete information removal.
Now, the ARIN community can develop policies to address this (and POC Validation certainly is an excellent first step) but we need to recognize that we're only now as a community beginning to address this situation, and it's simply going to take time.

Thanks!
/John

John Curran
President and CEO
ARIN



From rfg at tristatelogic.com  Thu Nov  4 08:30:21 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Thu, 04 Nov 2010 05:30:21 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <883BFCDD-B3D6-458D-B4AC-4D18F6007993@delong.com> 
Message-ID: <26961.1288873821@tristatelogic.com>


In message <883BFCDD-B3D6-458D-B4AC-4D18F6007993 at delong.com>, 
Owen DeLong <owen at delong.com> wrote:

>>
>>> There are too many people now in the ARIN community that just want to
>>> bury IPv4 and really aren't interested in mining possibly usable IPv4
>>> from Legacy resources.  They want to believe if we just ignore it we
>>> can leave IPv4 behind in a few years and switch everything to IPv6
>and
>>> they won't believe this isn't going to happen right away until it
>just
>>> doesn't happen right away.  Maybe they are right.  I just hope that
>if
>>> they are not, that they start mining.
>>
>> I think they are wrong, and within 12 months, the spaghetti is going
>to
>> start to hit the fan.
>...
>However, if you're faced with a post-runout network deployment, the
>question
>isn't so much one of whether the world has gone IPv6 yet or not as it is
>one
>of whether it makes sense to take heroic measures to add your network to
>the
>IPv4 network living on life support at best, or, add it to a growing and
>vibrant
>IPv6 internet.

"Growing and vibrant IPv6 internet" ??

Have you ever considered a career in marketing?
(1/2 :-)

>Finally, if you think it's going to take 12 months for the IPv4
>spaghetti to make
>contact with the whirling blades, you aren't paying attention. I think
>it will
>be somewhat sooner.

I said "within 12 months".

I was being generous.


Regards,
rfg


From owen at delong.com  Thu Nov  4 08:48:45 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Nov 2010 05:48:45 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <25869.1288867763@tristatelogic.com>
References: <25869.1288867763@tristatelogic.com>
Message-ID: <229F95A3-D2A7-46C5-B3EA-3CC665D94121@delong.com>

> 
> 
> P.P.S. I agree with the prior poster who asserted that IPv4 may yet have a
> lot of life left in it... well... it *would* have an almost infinite life
> left in it if it were not for (a) various hardware vendors who have a clear
> agenda to create an "upgrade cycle" (whether one is actually needed or not)
> and if it were not for (b) IPv4 being bled dry by (1) snowshoe spammers and
> (2) people who refuse to learn how to use NAT and (3) people who refuse to
> learn how to properly configure web servers and mail servers and name servers
> so that they will support multiple domains.

(3) -- Please do explain to me how to terminate an HTTPS connection for
multiple domains on the same server with different certificates on port 443.

Thanks for playing.

Owen



From rfg at tristatelogic.com  Thu Nov  4 08:49:59 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Thu, 04 Nov 2010 05:49:59 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <9E11B785-FFA2-4C62-824B-23B5F6071673@arin.net> 
Message-ID: <27141.1288874999@tristatelogic.com>


In message <9E11B785-FFA2-4C62-824B-23B5F6071673 at arin.net>, 
John Curran <jcurran at arin.net> wrote:

>On Nov 4, 2010, at 3:49 AM, Ronald F. Guilmette wrote:
>> I have been waiting weeks now for John Curran to answer my simple question:
>> i.e. What does, and what does not constitute "utilization fraud", and
>> although I see that he's found time to participate here, he apparently
>> hasn't found time to answer that question, the answer to which would help
>> me to spot even MORE utilization fraud than I am already aware of.
>
>Good morning Ron -
>
> {... big buch of non-responsive platitudes snipped... }

I am _still_ waiting for John Curran to answer the simple question.

Look John, this is very simple.... I have read comments about various
entities undergoing a "utilization audit".

Do such things exist?  Does ARIN perform any such?

(Those are both simple yes/no questions, by the way.)

If such things DO NOT exist and/or if ARIN DOES NOT perform any such, then
why have I read several people commenting about such audits and/or fretting
aloud that they may have to undergo one?

Conversely, if such things DO exist and if ARIN DOES perform any such,
then please do stop beating about the bush and just describe how that is
done.

I'm not asking either you or ``the community'' to invent anything new or
to consider anything new or to ratify anything new.  My question is about
current existing practice at ARIN.

If ARIN, at present, DOES NOT do any utilization audits or reviews, then
please have the coutesy to just say that.

Conversely, if ARIN, at present, DOES perform utilization audits or reviews,
then please just describe, briefly, how an organization either passes or fails
such a thing.

But whatever you do, please have the courtesy not to treat me to another
long winded digression on how ``the community'' must evolve approaches to
this, that, or the other.  I haven't asked about the future.  I want to
know what you are doing right now, today, in the way of reviewing utilization
of existing allocations.  (And if the answer is "nothing", then don't be
bashful... just say "nothing".  Nobody will begrudge you for the truth.)


Regards,
rfg


From owen at delong.com  Thu Nov  4 08:52:12 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Nov 2010 05:52:12 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <26961.1288873821@tristatelogic.com>
References: <26961.1288873821@tristatelogic.com>
Message-ID: <37EC59C4-FE76-49EE-9503-41042E3E4237@delong.com>

>>> 
>> ...
>> However, if you're faced with a post-runout network deployment, the
>> question
>> isn't so much one of whether the world has gone IPv6 yet or not as it is
>> one
>> of whether it makes sense to take heroic measures to add your network to
>> the
>> IPv4 network living on life support at best, or, add it to a growing and
>> vibrant
>> IPv6 internet.
> 
> "Growing and vibrant IPv6 internet" ??
> 
> Have you ever considered a career in marketing?
> (1/2 :-)
> 
No, but, I have access to a pretty good perspective on IPv6 traffic and
domain statistics. The IPv6 internet is already passing more traffic than
the IPv4 internet of only 8 years ago. When you consider the number of
years it took IPv4 to get to that point, I'd say IPv6 is catching up fast.

>> Finally, if you think it's going to take 12 months for the IPv4
>> spaghetti to make
>> contact with the whirling blades, you aren't paying attention. I think
>> it will
>> be somewhat sooner.
> 
> I said "within 12 months".
> 
> I was being generous.
> 
Now is not the time to be generous in such estimates.

Owen



From owen at delong.com  Thu Nov  4 09:07:32 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Nov 2010 06:07:32 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <27141.1288874999@tristatelogic.com>
References: <27141.1288874999@tristatelogic.com>
Message-ID: <DDE139AF-24A9-4F9A-B524-2CB78272E735@delong.com>


On Nov 4, 2010, at 5:49 AM, Ronald F. Guilmette wrote:

> 
> In message <9E11B785-FFA2-4C62-824B-23B5F6071673 at arin.net>, 
> John Curran <jcurran at arin.net> wrote:
> 
>> On Nov 4, 2010, at 3:49 AM, Ronald F. Guilmette wrote:
>>> I have been waiting weeks now for John Curran to answer my simple question:
>>> i.e. What does, and what does not constitute "utilization fraud", and
>>> although I see that he's found time to participate here, he apparently
>>> hasn't found time to answer that question, the answer to which would help
>>> me to spot even MORE utilization fraud than I am already aware of.
>> 
>> Good morning Ron -
>> 
>> {... big buch of non-responsive platitudes snipped... }
> 
> I am _still_ waiting for John Curran to answer the simple question.
> 
> Look John, this is very simple.... I have read comments about various
> entities undergoing a "utilization audit".
> 
> Do such things exist?  Does ARIN perform any such?
> 
Yes... See section 12 of the NRPM.

and Yes. See staff comments regarding draft policy 2010-11 at ARIN XXVI.

> (Those are both simple yes/no questions, by the way.)
> 
> If such things DO NOT exist and/or if ARIN DOES NOT perform any such, then
> why have I read several people commenting about such audits and/or fretting
> aloud that they may have to undergo one?
> 
N/A...

> Conversely, if such things DO exist and if ARIN DOES perform any such,
> then please do stop beating about the bush and just describe how that is
> done.
> 
Why? There are very good reasons for ARIN not to publicly disclose the
techniques and methods they use for conducting these audits. The details
of any particular audit cannot be public because of non-disclosure issues
and privacy issues related to the resource holder. This is completely 
legitimate.

> I'm not asking either you or ``the community'' to invent anything new or
> to consider anything new or to ratify anything new.  My question is about
> current existing practice at ARIN.
> 
To the extent valid and possible, your question has been answered, even
if you didn't like the answer.

> If ARIN, at present, DOES NOT do any utilization audits or reviews, then
> please have the coutesy to just say that.
> 
> Conversely, if ARIN, at present, DOES perform utilization audits or reviews,
> then please just describe, briefly, how an organization either passes or fails
> such a thing.
> 
If the organization holds resources and has utilization of those resources that
is compliant with the policies set forth in the NRPM, then, they pass. If they are
not in compliance with the policies in the NRPM, then, they do not pass and
ARIN will work with them to resolve the issue as described in NRPM 12.

> But whatever you do, please have the courtesy not to treat me to another
> long winded digression on how ``the community'' must evolve approaches to
> this, that, or the other.  I haven't asked about the future.  I want to
> know what you are doing right now, today, in the way of reviewing utilization
> of existing allocations.  (And if the answer is "nothing", then don't be
> bashful... just say "nothing".  Nobody will begrudge you for the truth.)
> 
What is happening right now has been explained and is documented
in the NRPM. I'm not sure what else you expect John to tell you.

Owen



From marty at akamai.com  Thu Nov  4 09:36:49 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 4 Nov 2010 09:36:49 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call (textrevised)
In-Reply-To: <27141.1288874999@tristatelogic.com>
Message-ID: <C8F82F31.162C8%marty@akamai.com>




On 11/4/10 8:49 AM, "Ronald F. Guilmette" <rfg at tristatelogic.com> wrote:

> 
> In message <9E11B785-FFA2-4C62-824B-23B5F6071673 at arin.net>,
> John Curran <jcurran at arin.net> wrote:
> 
>> On Nov 4, 2010, at 3:49 AM, Ronald F. Guilmette wrote:
>>> I have been waiting weeks now for John Curran to answer my simple question:
>>> i.e. What does, and what does not constitute "utilization fraud", and
>>> although I see that he's found time to participate here, he apparently
>>> hasn't found time to answer that question, the answer to which would help
>>> me to spot even MORE utilization fraud than I am already aware of.
>> 
>> Good morning Ron -
>> 
>> {... big buch of non-responsive platitudes snipped... }
> 
> I am _still_ waiting for John Curran to answer the simple question.
> 
> Look John, this is very simple.... I have read comments about various
> entities undergoing a "utilization audit".
> 
> Do such things exist?  Does ARIN perform any such?

Yes. 



-M<



From jcurran at arin.net  Thu Nov  4 09:58:53 2010
From: jcurran at arin.net (John Curran)
Date: Thu, 4 Nov 2010 09:58:53 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <27141.1288874999@tristatelogic.com>
References: <27141.1288874999@tristatelogic.com>
Message-ID: <0F135456-F298-40D4-95BB-5C4087637B67@arin.net>

On Nov 4, 2010, at 5:49 AM, Ronald F. Guilmette wrote:
> In message <9E11B785-FFA2-4C62-824B-23B5F6071673 at arin.net>, John Curran <jcurran at arin.net> wrote:
> 
>> On Nov 4, 2010, at 3:49 AM, Ronald F. Guilmette wrote:
>>> I have been waiting weeks now for John Curran to answer my simple question:
>>> i.e. What does, and what does not constitute "utilization fraud", and
>>> although I see that he's found time to participate here, he apparently
>>> hasn't found time to answer that question, the answer to which would help
>>> me to spot even MORE utilization fraud than I am already aware of.
>> 
>> Good morning Ron -
>> 
>> 
> {... big buch of non-responsive platitudes snipped... }

Actually, I was providing clarity regarding the state of the registry information on legacy resources and what constitutes number resource fraud.  I thought that was what you were asking about, but easily could have been wrong.

> I am _still_ waiting for John Curran to answer the simple question.
> 
> Look John, this is very simple.... I have read comments about various
> entities undergoing a "utilization audit".
> 
> Do such things exist?  Does ARIN perform any such?
> 
> (Those are both simple yes/no questions, by the way.)

Yes, they do exist.  Yes, we perform such.

They are routinely performed during the application for new or additional resources.  They are sometimes performed as a result of NRPM section 12.  They are *now* sometimes performed as a result of NRPM section 8.2 during M&A transfers.

> If such things DO NOT exist and/or if ARIN DOES NOT perform any such, then
> why have I read several people commenting about such audits and/or fretting
> aloud that they may have to undergo one?
> 
> Conversely, if such things DO exist and if ARIN DOES perform any such,
> then please do stop beating about the bush and just describe how that is
> done.

We request many different types of information to confirm the veracity of statements made by resource holders. The information asked varies depending on the specific assertions.

> I'm not asking either you or ``the community'' to invent anything new or
> to consider anything new or to ratify anything new.  My question is about
> current existing practice at ARIN.
> 
> If ARIN, at present, DOES NOT do any utilization audits or reviews, then
> please have the coutesy to just say that.
> 
> Conversely, if ARIN, at present, DOES perform utilization audits or reviews,
> then please just describe, briefly, how an organization either passes or fails
> such a thing.

Example: if an applicant says "we have X CPE devices/routers/widgets, and hence need Y additional number resources", we will ask for various hard-to-replicate materials that might back of those assertions regarding the X devices that they assert they have.  This could be copies of configurations, output of various commands, various business documentation, etc. 

> But whatever you do, please have the courtesy not to treat me to another
> long winded digression on how ``the community'' must evolve approaches to
> this, that, or the other.

Ron - I believe I've extended you every courtesy, even in absence of same.

The "long winded digression" was my attempt to answer your question of what constitutes number resource fraud.  This includes making false statements during a request to ARIN regarding resource utilization.  I was not aware that you were seeking details regarding audits, but hopefully this email will address that.

>  I haven't asked about the future.  I want to
> know what you are doing right now, today, in the way of reviewing utilization
> of existing allocations.  (And if the answer is "nothing", then don't be
> bashful... just say "nothing".  Nobody will begrudge you for the truth.)

Reviewing utilization of existing resources doesn't generally occur unless you're apply for additional resources, and hence may not be relevant to the vast majority of legacy resource holders.

/John

John Curran
President and CEO
ARIN

From matthew at matthew.at  Thu Nov  4 11:55:27 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 04 Nov 2010 08:55:27 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <24271.1288866146@tristatelogic.com>
References: <24271.1288866146@tristatelogic.com>
Message-ID: <4CD2D76F.6060101@matthew.at>

On 11/4/2010 3:22 AM, Ronald F. Guilmette wrote:
>
> At present, it appears that Mr. Page is using very little of that /16.
> It would be Nice if ARIN could get some or all of that back.
It would be equally "nice" (perhaps better) if "people who need IPv4 
space" could get some of it (after all, the only reason you want ARIN to 
get it back is to they can turn around and give it to people who need 
space), which they can do under a transfer policy, and which the holder 
will be willing to do once the people who need the space are willing to 
pay him enough. Among other things, unlike ARIN's "here's a block, for 
nearly free" policies, the price paid would scale all on its own with an 
address market, and these particular addresses (as having been used by a 
spammer) would actually have that history reflected in their (presumably 
discounted) price.

Matthew Kaufman


From matthew at matthew.at  Thu Nov  4 21:16:08 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 04 Nov 2010 18:16:08 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
References: <4CCAF8EA.7080109@arin.net>	<20101029164738.GA49730@ussenterprise.ufp.org>	<4CCB08F9.1030303@umn.edu>	<75822E125BCB994F8446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu>	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>	<75822E125BCB994F8446858C4B19F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
Message-ID: <4CD35AD8.4060701@matthew.at>

On 11/2/2010 10:29 AM, John Curran wrote:
>
> Correct.  They may bring their resources under an RSA or LRSA or not, as they wish. They may also transfer resources under agreement according to the policies adopted in the region, or not transfer them (again as they wish.)
>
> The only they can't do is transfer resources outside of the policies, as ARIN has to maintain the registration database in accordance with the community policies as adopted.
Only if by "transfer" you narrowly define it to be "change the 
registration database through the transfer process to point to the 
acquiring entity".

As has been pointed out, there's lots of other ways to "transfer 
resources outside of the policies", including updating the POC records 
on legacy resources, leaving the registration database as-is but issuing 
LOAs, etc.

Unless you believe that there's a way for ARIN to prohibit legacy 
non-RSA, non-LRSA block holders from doing these things.

Matthew Kaufman


From cgrundemann at gmail.com  Thu Nov  4 21:46:55 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 4 Nov 2010 19:46:55 -0600
Subject: [arin-ppml] Reclaiming unused IPv4 space (WAS: Draft Policy
 2010-10 (Global Proposal):GlobalPolicy for IPv4 Allocations by the IANA
 Post Exhaustion- Last Call (textrevised))
In-Reply-To: <20101103175943.GA75185@ussenterprise.ufp.org>
References: <AANLkTimeB9DjRvW2+Ypbsr-C2vmuOcc8XtROKXwU9+Uk@mail.gmail.com>
	<4E69FCA4-4D0A-45E0-9519-226AB59ADF81@arin.net>
	<9F511332-D701-433C-AC98-AC7F3E2D2088@i2bnetworks.com>
	<20101103170246.GA72090@ussenterprise.ufp.org>
	<AANLkTinzJONJeMnQOWCtcvtqhZ3fF_b2XcMRLQQypFj+@mail.gmail.com>
	<20101103175943.GA75185@ussenterprise.ufp.org>
Message-ID: <AANLkTi=rZhNC82owyimYAvicoaJn46rJ1LpbK8YGsXv1@mail.gmail.com>

On Wed, Nov 3, 2010 at 11:59, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Wed, Nov 03, 2010 at 11:16:43AM -0600, Chris Grundemann wrote:
>> Section 3.6 of the NRPM (the result of dp 2008-7), was meant to help
>> resolve this problem by requiring POCs to respond to an annual "ping."
>
> All this policy does is allow POC's to be marked as invalid, there
> is no way to remove the POC, much less the resource record entirely.

As I see it, there are four parts to this policy:
1) ARIN is required to perform the annual email ping.
2) Unresponsive POC email addresses shall be marked as such in the
database. As you note.
3) POCs which ARIN deems wholly unresponsive (likely after phone and
postal mail contact attempts fail) are marked as invalid.
4) Resources with zero valid POCs are cast out of the shadows for what they are.

There was a concern that removing the record could potentially cause
harm, where marking it appropriately was the best of both worlds; you
still have a POC to try, but you are aware that the POC is likely not
going to respond. For blocks with no valid contacts at all - perhaps
filtering becomes attractive, to mitigate your exposure.

> To that end, it is a first step to identify the resources that might
> be abandoned, but it is not the process to actually recover them.

Agreed, that policy is merely a first step and does not address reclamation.

To the extent that anyone believes there is a need to take the next
step and create a policy to push ARIN towards reclamation of unused
space, particularly space without a valid registrant, I have some
policy text put together and would love to hear from you off list. I
invite all interested parties to contact me.

>> I suspect class Cs and especially Bs may be worth more than we might
>> now guess, shortly.
>
> I won't speculate on price, just their ability to "extend runout" or
> serve the potential demand. ?By those measures I think they are
> insignificant.

Fair enough. I fully agree that address recovery is highly unlikely to
extend runout in any meaningful way. But I also agree with you that it
has value in other dimensions.

>> > IMHO the minimum that ARIN should do is have yearly contact with
>> > anyone holding a number resource, including legacy holders. ?I don't
>> > know what the cost is to send a letter, get back a respose and check
>> > off "yes that person still exists", but I can't imagine it is a
>> > lot. ?I would be very supportive of a policy that caused ARIN to
>> > charge a fee to legacy holders of $5, or $10 or whatever that cost
>> > is per year to "keep their database entry current" so the community
>> > can detect situations like this one.
>>
>> Wouldn't that require them to sign something (like an LRSA)?
>
> Sign a check, most definately. :)
>
> I'm not going to wade into which contract (RSA/LRSA, or something all
> together new) would need to be signed. ?I'm fairly sure the contract
> issues can be resolved if folks really want to resolve them.

The problem that I see here is that in many cases it appears that only
folks on one side of the contract want the issues resolved, which
creates an impasse. How hard it is to overcome that impasse I am
unsure of.

~Chris

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

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From stephen at sprunk.org  Thu Nov  4 23:23:16 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Thu, 04 Nov 2010 22:23:16 -0500
Subject: [arin-ppml] Audits
In-Reply-To: <0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
Message-ID: <4CD378A4.7010907@sprunk.org>

On 04 Nov 2010 08:58, John Curran wrote:
> On Nov 4, 2010, at 5:49 AM, Ronald F. Guilmette wrote:
>> I haven't asked about the future.  I want to know what you are doing right now, today, in the way of reviewing utilization of existing allocations.  (And if the answer is "nothing", then don't be bashful... just say "nothing".  Nobody will begrudge you for the truth.)
> Reviewing utilization of existing resources doesn't generally occur unless you're apply for additional resources, and hence may not be relevant to the vast majority of legacy resource holders.

IMHO, that is unfortunate.  My intent (I can't speak for Owen's) behind
2007-14 was that ARIN would actively seek out unused/abandoned resources
for reclamation.  The policy did not _force_ ARIN to do so because I
believed you would proceed as quickly as ARIN's staffing and finances
allowed.  It appears I was wrong, and I'll look at submitting a proposal
to "correct" this problem in the next cycle; hopefully it won't be too
late to matter.

POC invalidation should be an input (one of many) into the selection of
targets for an active review program, not merely something that is just
marked in the database and promptly forgotten.  If an org doesn't
respond to validation requests, odds are they won't respond to review
requests either and reclamation will be nearly automatic (after an
appropriate time-out period, of course).

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101104/6cc01624/attachment.p7s>

From stephen at sprunk.org  Fri Nov  5 00:06:03 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Thu, 04 Nov 2010 23:06:03 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <4CD0D768.3060905@ipinc.net>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net>
Message-ID: <4CD382AB.1030107@sprunk.org>

On 02 Nov 2010 22:30, Ted Mittelstaedt wrote:
> On 11/2/2010 5:38 PM, Bill Darte wrote:
>> Never, in my memory, has the debate over recovery of legacy addresses
>> been given more than superficial treatment.
>>
>
> I think that this is because ultimately the goal isn't to take legacy
> resources away that are IN USE.

IMHO, that depends on the degree of non-compliance.  I've worked with
dozens of orgs with legacy space, and not a single one of them could
even come close to justifying their space _that was in use_.

However, I don't see any point in targeting orgs using their space
inefficiently until we've dealt with all the ones (and I really do mean
every last one that can be found) not using their space _at all_.

> Ultimately the goal should be to take legacy resources away that are
> either being hoarded, or are abandoned.

"Hoarded" is a loaded term, and it's difficult to prove someone's doing
it.  "Justified" is easily determined, though, since we _already_ have
dozens of pages of policy describing exactly what that means.

>> Seems that the typical statements that stop debate is that such a
>> course would be prohibitively expensive from a legal point of view
>
> Rubbish.  If ARIN takes over an abandoned Legacy resource then since
> it is abandoned, the original org that had it cannot suffer damages,
> and since it hasn't suffered damages, it has no standing to sue in court.
>
> The problem is that since the original Legacy holder did NOT ever sign
> an agreement with ARIN then ARIN has no contractual justification to
> take over an abandoned Legacy assignment even if they know it's unused,

AFAICT, if the registrant does not have a contract (i.e. RSA or LRSA)
with ARIN for registry services, ARIN has no obligation to continue
providing them, especially for free.  There are many who feel ARIN has a
_moral_ obligation to do so, but that's not a matter for the courts.

> because so far the community has not given ARIN permission to do this
> via policy in the NRPM.

That all depends on how one interprets NRPM 12.8.

IMHO, ARIN _already_ had the power to apply policy to legacy space or
revoke it entirely, and therefore NRPM 12 actually _limits_ how ARIN may
do so, as it does for non-legacy resources.

> Right now, Legacy netblocks that are attached to POCs that ARIN
> determines are non-respondent, can ultimately be freed up.  All ARIN
> has to do is determine a POC is abandoned and when ALL POCs that are
> on a particular Legacy block change to abandoned status, then the
> resource is, (in my opinion) effectively freed, and (in my opinion)
> ARIN should move it back into the free pool of assignable IPv4

Wrong.  ARIN would need to follow the procedure in NRPM 12, which
governs _all_ reclamation activities.

However, if all the POCs are unresponsive, then presumably they will not
respond with justification as required in 12.1, they will not
voluntarily return the resource(s) as required in 12.4, and eventually
ARIN can revoke the resource(s) under 12.5.

>
> But that does not answer the Legacy space that is unused, yet still
> has a respondent POC on it.  Or Legacy space that the master block
> has an abandoned POC but has active POC's that are in SWIPS that
> were filed on parts of it.

One can address most of those by having other processes that add to the
same list of resources to be reviewed.  For instance, one might consider
a resource not appearing in the DFZ to be a sign of probable
non-compliance which triggers a review.  Or resources which have not
been updated in the last N years.  Or not having valid rDNS servers.  If
the review concludes they're valid, the registrant has 24 months before
they have to worry about being hassled again.

Yes, a sufficiently cagey registrant may be able to avoid all of our
heuristics, but most won't even try to.  It's reasonable to lose a
battle to a skilled and dedicated opponent; it's absolutely indefensible
to surrender a battle when your opponent doesn't even show up, which is
where we are right now.  Let's fix the latter problem before we worry
about the former.

> And on top of that, not too long ago I thought the AC stated they
> would no longer entertain drafts of policy changes that dealt entirely
> with IPv4.  So please don't duck behind this "if you think you have a
> better method then make a proposal" bullcrap.

Most of the problems with legacy IPv4 blocks also apply to legacy ASNs,
so proposals along these lines need to say "resources" anyway.

> There are too many people now in the ARIN community that just want to
> bury IPv4 and really aren't interested in mining possibly usable IPv4
> from Legacy resources.  They want to believe if we just ignore it we
> can leave IPv4 behind in a few years and switch everything to IPv6 and
> they won't believe this isn't going to happen right away until it just
> doesn't happen right away.  Maybe they are right.  I just hope that if
> they are not, that they start mining.

I don't think that "mining" IPv4 blocks for reclamation will have any
meaningful effect on runout, but I still think it's worthwhile for
several other reasons.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101104/a678e272/attachment.p7s>

From owen at delong.com  Fri Nov  5 02:32:36 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Nov 2010 23:32:36 -0700
Subject: [arin-ppml] Audits
In-Reply-To: <4CD378A4.7010907@sprunk.org>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<4CD378A4.7010907@sprunk.org>
Message-ID: <AA2DDE2A-9038-408C-BF29-483518455D1C@delong.com>


On Nov 4, 2010, at 8:23 PM, Stephen Sprunk wrote:

> On 04 Nov 2010 08:58, John Curran wrote:
>> On Nov 4, 2010, at 5:49 AM, Ronald F. Guilmette wrote:
>>> I haven't asked about the future.  I want to know what you are doing right now, today, in the way of reviewing utilization of existing allocations.  (And if the answer is "nothing", then don't be bashful... just say "nothing".  Nobody will begrudge you for the truth.)
>> Reviewing utilization of existing resources doesn't generally occur unless you're apply for additional resources, and hence may not be relevant to the vast majority of legacy resource holders.
> 
> IMHO, that is unfortunate.  My intent (I can't speak for Owen's) behind
> 2007-14 was that ARIN would actively seek out unused/abandoned resources
> for reclamation.  The policy did not _force_ ARIN to do so because I
> believed you would proceed as quickly as ARIN's staffing and finances
> allowed.  It appears I was wrong, and I'll look at submitting a proposal
> to "correct" this problem in the next cycle; hopefully it won't be too
> late to matter.
> 
> POC invalidation should be an input (one of many) into the selection of
> targets for an active review program, not merely something that is just
> marked in the database and promptly forgotten.  If an org doesn't
> respond to validation requests, odds are they won't respond to review
> requests either and reclamation will be nearly automatic (after an
> appropriate time-out period, of course).
> 
2007-14 (now NRPM 12) specifically doesn't allow ARIN to target legacy
resources beyond what they would have done before NRPM 12, but,
does allow ARIN to count utilization data for legacy resources when
measuring utilization for an organization which has both legacy and
non-legacy resources.

The LRSA provides additional protection for legacy holders which have
signed it.

I do think that in the case of POC abandonment or invalidation, ARIN
should be actively seeking to reclaim that space. I am not sure it should
be placed in to the free pool or issued to other organizations unless
ARIN is absolutely certain the previous resource holder is no more.

Owen




From owen at delong.com  Fri Nov  5 02:56:42 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Nov 2010 23:56:42 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last
	Call	(textrevised)
In-Reply-To: <4CD382AB.1030107@sprunk.org>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net> <4CD382AB.1030107@sprunk.org>
Message-ID: <C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>


On Nov 4, 2010, at 9:06 PM, Stephen Sprunk wrote:

> On 02 Nov 2010 22:30, Ted Mittelstaedt wrote:
>> On 11/2/2010 5:38 PM, Bill Darte wrote:
>>> Never, in my memory, has the debate over recovery of legacy addresses
>>> been given more than superficial treatment.
>>> 
>> 
>> I think that this is because ultimately the goal isn't to take legacy
>> resources away that are IN USE.
> 
> IMHO, that depends on the degree of non-compliance.  I've worked with
> dozens of orgs with legacy space, and not a single one of them could
> even come close to justifying their space _that was in use_.
> 
> However, I don't see any point in targeting orgs using their space
> inefficiently until we've dealt with all the ones (and I really do mean
> every last one that can be found) not using their space _at all_.
> 
IMHO, targeting legacy holders for non-compliance with today's
ARIN policies is dubious at best. I agree we should seek to actively
reclaim abandoned resources (resources where the ORG no
longer exists). I think we should possibly reach out and request that
ORGs no longer using their legacy resources voluntarily return
them.

Legacy holders received their resources under very different
requirements with very different expectations. While ARIN is the
successor registry of record, legacy holders (other than LRSA
signatories) have no agreement with ARIN and never agreed
to be bound by the ARIN policy process. I think attempting to
take such resources is an almost certain path to very costly
litigation with a very uncertain outcome. There are better things
for ARIN to do with their legal budget, IMHO.

>> Ultimately the goal should be to take legacy resources away that are
>> either being hoarded, or are abandoned.
> 
> "Hoarded" is a loaded term, and it's difficult to prove someone's doing
> it.  "Justified" is easily determined, though, since we _already_ have
> dozens of pages of policy describing exactly what that means.
> 
What we don't have is any form of agreement by the legacy holders
that the ARIN definition of justified applies to them. Non-signatories
to the LRSA are, thus, in an uncertain area. Signatories of the LRSA
are clearly protected from current and future ARIN policies in this
regard.

>>> Seems that the typical statements that stop debate is that such a
>>> course would be prohibitively expensive from a legal point of view
>> 
>> Rubbish.  If ARIN takes over an abandoned Legacy resource then since
>> it is abandoned, the original org that had it cannot suffer damages,
>> and since it hasn't suffered damages, it has no standing to sue in court.
>> 
>> The problem is that since the original Legacy holder did NOT ever sign
>> an agreement with ARIN then ARIN has no contractual justification to
>> take over an abandoned Legacy assignment even if they know it's unused,
> 
> AFAICT, if the registrant does not have a contract (i.e. RSA or LRSA)
> with ARIN for registry services, ARIN has no obligation to continue
> providing them, especially for free.  There are many who feel ARIN has a
> _moral_ obligation to do so, but that's not a matter for the courts.
> 
I agree that ARIN has a moral obligation to legacy holders.

I am uncertain about what legal obligations ARIN has to legacy holders.

I think that involuntary reclamation of legacy resources or "termination of
services" to legacy holders is contrary to ARIN's best interests. I think that
going beyond "termination of services" to the step of placing resources
back into the free pool and issuing them to other organizations would
be outright counter-productive for all concerned (except in the case of
clear abandonment).

>> because so far the community has not given ARIN permission to do this
>> via policy in the NRPM.
> 
> That all depends on how one interprets NRPM 12.8.
> 
> IMHO, ARIN _already_ had the power to apply policy to legacy space or
> revoke it entirely, and therefore NRPM 12 actually _limits_ how ARIN may
> do so, as it does for non-legacy resources.
> 
Where did this power come from? For non-legacy holders, it comes from
the RSA which is a binding contract between the resource holder and ARIN
which entitles ARIN to revoke resources according to the NRPM.

There is no document anywhere that I know of which gives ARIN any
such authority to revoke legacy resources based on current ARIN policy
where it differs from the policies in effect under which the legacy resources
were issued.

>> Right now, Legacy netblocks that are attached to POCs that ARIN
>> determines are non-respondent, can ultimately be freed up.  All ARIN
>> has to do is determine a POC is abandoned and when ALL POCs that are
>> on a particular Legacy block change to abandoned status, then the
>> resource is, (in my opinion) effectively freed, and (in my opinion)
>> ARIN should move it back into the free pool of assignable IPv4
> 
> Wrong.  ARIN would need to follow the procedure in NRPM 12, which
> governs _all_ reclamation activities.
> 

> However, if all the POCs are unresponsive, then presumably they will not
> respond with justification as required in 12.1, they will not
> voluntarily return the resource(s) as required in 12.4, and eventually
> ARIN can revoke the resource(s) under 12.5.
> 
Presumably the later stages of POC validation would include the notices
required under 12.1 such that by the time the POCs were marked invalid,
we would have at least completed the 12.4 waiting period as well, thus
making 12.5 effective pretty much as described above.

>> 
>> But that does not answer the Legacy space that is unused, yet still
>> has a respondent POC on it.  Or Legacy space that the master block
>> has an abandoned POC but has active POC's that are in SWIPS that
>> were filed on parts of it.
> 
> One can address most of those by having other processes that add to the
> same list of resources to be reviewed.  For instance, one might consider
> a resource not appearing in the DFZ to be a sign of probable
> non-compliance which triggers a review.  Or resources which have not
> been updated in the last N years.  Or not having valid rDNS servers.  If
> the review concludes they're valid, the registrant has 24 months before
> they have to worry about being hassled again.
> 
There are specific policies allowing for non-connected networks and always
have been. Why would the fact that a resource does not appear in one
particular view (or even several views) of the DFZ be considered a sign
of probable non-compliance? As to update cycle, some organizations
are actually extremely stable.

What value of N would you propose? 5? 10? 15?

When did maintaining valid rDNS become a requirement even for a non-
legacy holder? I can't find that requirement anywhere in the NRPM.

> Yes, a sufficiently cagey registrant may be able to avoid all of our
> heuristics, but most won't even try to.  It's reasonable to lose a
> battle to a skilled and dedicated opponent; it's absolutely indefensible
> to surrender a battle when your opponent doesn't even show up, which is
> where we are right now.  Let's fix the latter problem before we worry
> about the former.
> 
When did this shift from stewardship to seeking battles with legacy
holders? That certainly was not my intent in NRPM 12.

>> And on top of that, not too long ago I thought the AC stated they
>> would no longer entertain drafts of policy changes that dealt entirely
>> with IPv4.  So please don't duck behind this "if you think you have a
>> better method then make a proposal" bullcrap.
> 
> Most of the problems with legacy IPv4 blocks also apply to legacy ASNs,
> so proposals along these lines need to say "resources" anyway.
> 
The AC did not make such a statement. The statement made was that
we felt further policies for IPv4 resources were likely moot and the
AC would probably abandon such policies absent a clear need for
the policy.

In my personal opinion, making this statement was ill-advised on the
part of the AC and I am on record as a dissenting vote. One of the
reasons for my dissent was the probability of the statement being
misconstrued in this manner.

>> There are too many people now in the ARIN community that just want to
>> bury IPv4 and really aren't interested in mining possibly usable IPv4
>> from Legacy resources.  They want to believe if we just ignore it we
>> can leave IPv4 behind in a few years and switch everything to IPv6 and
>> they won't believe this isn't going to happen right away until it just
>> doesn't happen right away.  Maybe they are right.  I just hope that if
>> they are not, that they start mining.
> 
> I don't think that "mining" IPv4 blocks for reclamation will have any
> meaningful effect on runout, but I still think it's worthwhile for
> several other reasons.
> 
I understand the "other reasons" for reclamation of abandoned resources.
They're a good target for abuse. What reasons do you have for actively
seeking to reclaim legacy resources that are not abandoned just because
you feel like ARIN can enforce current policy against organizations that
have no contractual relationship with ARIN and have never consented
to the current policy process?

Owen



From rfg at tristatelogic.com  Fri Nov  5 03:53:28 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Fri, 05 Nov 2010 00:53:28 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <DDE139AF-24A9-4F9A-B524-2CB78272E735@delong.com> 
Message-ID: <39856.1288943608@tristatelogic.com>


In message <DDE139AF-24A9-4F9A-B524-2CB78272E735 at delong.com>, 
Owen DeLong <owen at delong.com> wrote:

>rfg:
>> Conversely, if such things DO exist and if ARIN DOES perform any such
>> {utilization audits}
>> then please do stop beating about the bush and just describe how that is
>> done.
>>
>Why? There are very good reasons for ARIN not to publicly disclose the
>techniques and methods they use for conducting these audits.

I'm listening.  What are those?

Do they outweigh the many obvious good reasons to have a clear and transparent
statement of the process that all members know they may be held to, without
prejudice or favor?

>The details of any particular audit cannot be public because of non-disclosure

I took that as a given.  But that's not what I asked about.  I didn't ask
about any _specific_ review.  I have asked about how reviews/audits are done,
in general.

And I am still awaiting even some small clue of what such a thing might entail.

Look, I think I've made my interest clear.  I believe, based on evidence,
that there is rampant and profligate waste and fraud in IPv4 allocations
within ARIN-land, and most of it is unambiguously in the service of spammers.
The waste and fraud hasn't been a big issue for most folks.. with the possible
exception of virulent die-hand anti-spammers like me... as long as there were
plenty of IPv4 addresses to go around.  Next year, as I understand it, that
is all going to change, and leigitimate companies may perhaps start offering
their eye teeth, just to get a small bit of IPv4 space, once official
"exhaustion" occurs.  Based on that, I think that it may be safely predicted
that I and my current opinions (_and_ my current rudeness, such as it is)
will ultimately be seen to have been but a harbinger of what is sure to come,
i.e. a whole lot of other and different people asking a whole lot of very
similar sorts of very pointed questions about EXACTLY how so many organizations
seem to manage to get away with such apparently large amounts of waste and
fraud, year after year.

When and if that does indeed occur, I do think that ARIN is going to have to
come up with some better answer than just saying that it's all secret, and
that (thus) nobody is even allowed to question the process, or whether it
is being perform fairly, or whether it is being performed with the best
possible techniques and technology (e.g. for getting a _true_ measure of
"hosts" within a given space), or whether it is being performed at all.


Regards,
rfg


P.S.  Although it may seem otherwise, my actual goal is not to simply
criticise or throw rocks at ARIN's existing utilization review processes,
but rather to try to offer (if it would be accepted) some of my own tools
and techniques to possibly aid and improve the utilization audit process
further.  That would be a win-win all around I think... I and others would
see fewer spammers on the net and the entire ARIN community might benefit
from having more accurate utilization audits.  But in case it isn't obvious,
I and other such wlling souls cannot possibly offer any improved technology
which might be mixed in to improve the existing audit process if we... and
everyone else on the planet... are all kept utterly in the dark about whatever
ARIN currently is or isn't doing with respect to the conduct of these audits.

How can any well-meaning soul offer improvements to a process that is kept
entirely hidden behind the curtain, rather like the Wizard of Oz?


From owen at delong.com  Fri Nov  5 04:24:45 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 5 Nov 2010 01:24:45 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <39856.1288943608@tristatelogic.com>
References: <39856.1288943608@tristatelogic.com>
Message-ID: <E44E6428-C3AA-48A6-82A2-9FA24E98E018@delong.com>


On Nov 5, 2010, at 12:53 AM, Ronald F. Guilmette wrote:

> 
> In message <DDE139AF-24A9-4F9A-B524-2CB78272E735 at delong.com>, 
> Owen DeLong <owen at delong.com> wrote:
> 
>> rfg:
>>> Conversely, if such things DO exist and if ARIN DOES perform any such
>>> {utilization audits}
>>> then please do stop beating about the bush and just describe how that is
>>> done.
>>> 
>> Why? There are very good reasons for ARIN not to publicly disclose the
>> techniques and methods they use for conducting these audits.
> 
> I'm listening.  What are those?
> 
> Do they outweigh the many obvious good reasons to have a clear and transparent
> statement of the process that all members know they may be held to, without
> prejudice or favor?
> 
The process is documented in NRPM12 and is pretty clear.

The specific investigative techniques used inside of ARIN and they particular
smell tests they use to discover fraud should not be disclosed because disclosure
of the techniques makes it easier to circumvent them.

>> The details of any particular audit cannot be public because of non-disclosure
> 
> I took that as a given.  But that's not what I asked about.  I didn't ask
> about any _specific_ review.  I have asked about how reviews/audits are done,
> in general.
> 
Whether it was you or someone else, certain people have brought up their
belief about things that did or did not happen with specific reports that they
had made in this discussion.

> And I am still awaiting even some small clue of what such a thing might entail.
> 
Have you read NRPM 12?

> Look, I think I've made my interest clear.  I believe, based on evidence,
> that there is rampant and profligate waste and fraud in IPv4 allocations
> within ARIN-land, and most of it is unambiguously in the service of spammers.

Care to make any specific claims to back up that sweeping accusation?
As yet I am not convinced this is an accurate statement.

> The waste and fraud hasn't been a big issue for most folks.. with the possible
> exception of virulent die-hand anti-spammers like me... as long as there were
> plenty of IPv4 addresses to go around.  Next year, as I understand it, that
> is all going to change, and leigitimate companies may perhaps start offering
> their eye teeth, just to get a small bit of IPv4 space, once official
> "exhaustion" occurs.  Based on that, I think that it may be safely predicted
> that I and my current opinions (_and_ my current rudeness, such as it is)
> will ultimately be seen to have been but a harbinger of what is sure to come,
> i.e. a whole lot of other and different people asking a whole lot of very
> similar sorts of very pointed questions about EXACTLY how so many organizations
> seem to manage to get away with such apparently large amounts of waste and
> fraud, year after year.

Yes, we're running out of IPv4 addresses. Yes, there will probably be some
people so stubbornly clinging to the idea of continuing to expand the IPv4
legacy environment that they will be willing to surrender large sums of
money towards doing so. Those same people have put off the migration to
IPv6 within their organizations for years (close to a decade at this point)
because they couldn't see the need. I have little sympathy for them.

As I see it, even if you consider "rampant and profligate waste", you might expect
ARIN to reclaim, what, maybe 10 /8s worth of space over the next 5 years? The
internet is consuming 2 /8s per month. 2 per year isn't even a drop in the bucket.

Like it or not, reclamation is a slow, deliberate, careful process that takes
significant time. IPv4 is a quagmire of allocations and assignments that
were issued before ARIN existed. For those allocations and assignments,
it's very unclear that ARIN has any authority to make such reclamations
unless the resources are outright abandoned by the original recipient
or voluntarily returned.

If you think there is rampant and profligate waste and fraud in space
issued by ARIN since ARIN was formed, please present evidence. I am
of the impression that:

	1.	There is not as much fraud and waste as some people would like
		to claim.

	2.	What waste there is is primarily in legacy registrations.

	3.	Most of the legacy registrations that are not abandoned are used
		in compliance with the policies under which they were issued.

	4.	Spammers hijack a lot of space and good reclamation of
		abandoned space _MAY_ be worth while to reduce the
		impact of those hijackings. However, transition to IPv6 and
		subsequent general deprecation of IPv4 will do much more
		to improve this situation than any reclamation efforts could.

	5.	Reclamation for the sake of meeting the perceived needs for
		a continuous supply of IPv4 addresses is like giving small
		doses of heroin to a junky. It doesn't meet their physiological
		needs but it continues their addiction.

> 
> When and if that does indeed occur, I do think that ARIN is going to have to
> come up with some better answer than just saying that it's all secret, and
> that (thus) nobody is even allowed to question the process, or whether it
> is being perform fairly, or whether it is being performed with the best
> possible techniques and technology (e.g. for getting a _true_ measure of
> "hosts" within a given space), or whether it is being performed at all.
> 
I stated that the specific investigative techniques used by staff are secret.
The procedure and the policies to which staff holds resource recipients are
not in any way secret. They are, as previously stated, documented in the
NRPM.

Owen

> 
> Regards,
> rfg
> 
> 
> P.S.  Although it may seem otherwise, my actual goal is not to simply
> criticise or throw rocks at ARIN's existing utilization review processes,
> but rather to try to offer (if it would be accepted) some of my own tools
> and techniques to possibly aid and improve the utilization audit process
> further.  That would be a win-win all around I think... I and others would
> see fewer spammers on the net and the entire ARIN community might benefit
> from having more accurate utilization audits.  But in case it isn't obvious,
> I and other such wlling souls cannot possibly offer any improved technology
> which might be mixed in to improve the existing audit process if we... and
> everyone else on the planet... are all kept utterly in the dark about whatever
> ARIN currently is or isn't doing with respect to the conduct of these audits.
> 
IPv4 reclamation is far less effective in this regard than IPv6 migration.

> How can any well-meaning soul offer improvements to a process that is kept
> entirely hidden behind the curtain, rather like the Wizard of Oz?

The ARIN consultation and suggestion process?

You can always offer whatever tools and suggestions you have.

Again, the process is documented. The exact methods and techniques
used by ARIN staff to carry it out are not disclosed to the public just
as any fraud examiner or other investigative agency does not disclose
their particular methods.

Owen



From rfg at tristatelogic.com  Fri Nov  5 05:34:43 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Fri, 05 Nov 2010 02:34:43 -0700
Subject: [arin-ppml] Audits
In-Reply-To: <0F135456-F298-40D4-95BB-5C4087637B67@arin.net> 
Message-ID: <40820.1288949683@tristatelogic.com>


In message <0F135456-F298-40D4-95BB-5C4087637B67 at arin.net>, 
John Curran <jcurran at arin.net> wrote:

>> {... big buch of non-responsive platitudes snipped... }
>
>Actually, I was providing clarity regarding the state of the registry infor
>mation on legacy resources and what constitutes number resource fraud.  I t
>hought that was what you were asking about, but easily could have been wron
>g.

No, John, I wasn't asking about any registry information.  And I think you
knew that.  I was asking the same question that I have asked you repeatedly
in private e-mail over several weeks, without any response from you whatsoever.

Again, just to repeat what I have already asked you in private e-mail (without
any reply), I, and also others I know would very much like to know exactly
how much unmitigated and unambiguous waste and fraud some entity holding
ARIN number resources can get away with before ARIN will see fit to do
anything about it.  I mean how much does the waste/fraud have to be?  What
is the "action" threshold?  25% ? 50% ? 75% ?

It really isn't just me that wants to know the answer here.  Numerous people
on the various anti-spam lists I'm on are, like me, often puzzeled when
they see ARIN handling out fresh /18 allocations to crooked ISPs who only
need the new allocations because their resident snowshoe spammers have
already throughly "burned" all of the IP space the ISP previously gave them,
i.e. they've already gotten all that old space blacklisted to hell and
back, forever, and so now they come back to ARIN and get a new, virginal
/19 or /18 or /17, then they put just two or three spammers into that, and
then start the cycle all over again.  Rinse, lather, repeat.

What's even more puzzling is that way all this has been happening in what
has been alleged to be a time of "scarcity".

(For some strange reason that I can't quite explain, I and others would like
to see this sort of cycle and this sort of practice ended, and would like
to see some of these crooked ISPs be held to account for a change, e.g. by
_not_ routinely being granted big new IP blocks, by ARIN... out of the ever
dwindling remaining pile... when what these crooked ISPs have done previously
was to utterly waste what was already given to them.)

And as I also asked you in private e-mail (also without any reply) does
ARIN care about and/or will ARIN _do_ anything about deliberately fradulent
sub-allocation WHOIS records?

I have already a record of several dozens of these... all being used by
a handful of crooked ISPs to give cover to their pet snowshoe spammers
(to whom, as I have told you, they typically give a /24 for each single
actual host).

So, if I report them all, will ARIN even bother to investigate any of these
bogus/fradulent WHOIS records?  Or should I not even waste my time, e.g.
because ARIN doesn't give a flying fig about SUB-allocation WHOIS records?
(Or should I not waste my time because as long as any given ARIN member stays
below, e.g., 15% fraud, ARIN will consider that inconsequential, in the
Grand Scheme of Things.)

I really would like to know, you know, before I waste all that time typing
into your fraud form, just to be told, e.g. that ARIN doesn't ``police''
fraud in SUB-allocation records.

And of course, I'd also like to know if ARIN is still dedicated to making
the task of reporting fradulent use of number resources as painful, slow
and as tedious as possible, i.e. by (1) following the ICANN model, refusing
to accept any more than one single report at a time and by (2) leaving
your fraud reporting form just exactly as it has been for months now,
i.e. with no more than a postage stamp sized data entry hole in which
the reporter is expected to explain to the ARIN reviewer exactly how the
conclusion was reached that a given registration is fradulent.

I gotta say, that if you folks running ARIN set out to maximally disuade
people from even reporting waste and/or fraud... well... then you have
succeded.  The rules for what is and isn't fraud and/or waste have been
made as opaque as possible, and the reporting _mechanism_ has been made
as tedious, laborious, and as painful as possible[1].

>>Conversely, if ARIN, at present, DOES perform utilization audits or reviews,
>>then please just describe, briefly, how an organization either passes or
>>fails such a thing.
>
>Example: if an applicant says "we have X CPE devices/routers/widgets, and h
>ence need Y additional number resources", we will ask for various hard-to-r
>eplicate materials that might back of those assertions regarding the X devi
>ces that they assert they have.  This could be copies of configurations, ou
>tput of various commands, various business documentation, etc.

Define "have".  What if two crooked ISPs work together?  So today, one of
them has 200 routers.  Tomorrow, the other one has 200 routers.  Does "have"
mean "own" or does "have" maybe mean "borrowed"?

And also, what's the allocation formula?  If I come to you and I say that
I have twelve Cisco 7204's (and give you the purchase reciepts for all
of them, so you know I really bought them) then what do I get from you?
A /18 ?  What?

>Ron - I believe I've extended you every courtesy, even in absence of same.

Well, ya know, answering, rather than just ignoring my private e-mails would
have been nice, even if only to tell me to buzz off.  (After all, you _did_
previously suggest to me that you'd be willing to answer my questions off
list, but then, in practice, apparently not so much.)  But we'll let that
go for now.


Regards,
rfg


===========================
[1]  As It happens, I broke two metacarpals in my right hand in late May,
and I'm still recouperating from that.  Typing on the keyboard is no longer
totally painful, but it is sufficiently so so that I do not relish the
thought of typing each one of the dozens of fradulent sub-allocation records
I know about into your form individually.

I hesitate to ask if you would consider allowing ``bulk'' submissions of
fraud reports, e.g. by trained and experienced investigators, because as
things stand now it looks to me like your organization doesn't even really
want to accept such reports, even when they are submitted one-at-a-time.


From jcurran at arin.net  Fri Nov  5 07:15:35 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 5 Nov 2010 07:15:35 -0400
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <4CD35AD8.4060701@matthew.at>
References: <4CCAF8EA.7080109@arin.net>
	<20101029164738.GA49730@ussenterprise.ufp.org>
	<4CCB08F9.1030303@umn.edu>
	<75822E125BCB994F8446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu>
	<6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net>
	<75822E125BCB994F8446858C4B19F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>
	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>
	<4CD35AD8.4060701@matthew.at>
Message-ID: <019F0C59-B2E7-42B5-8C02-956508D741F3@arin.net>

On Nov 4, 2010, at 9:16 PM, Matthew Kaufman wrote:
On 11/2/2010 10:29 AM, John Curran wrote:
>> 
>> Correct.  They may bring their resources under an RSA or LRSA or not, as they wish. They may also transfer resources under agreement according to the policies adopted in the region, or not transfer them (again as they wish.)
>> 
>> The only they can't do is transfer resources outside of the policies, as ARIN has to maintain the registration database in accordance with the community policies as adopted.
> 
> Only if by "transfer" you narrowly define it to be "change the registration database through the transfer process to point to the acquiring entity".

The Whois database defines the party who has use of the resource accordingly the community developed policy. 

> As has been pointed out, there's lots of other ways to "transfer resources outside of the policies", including updating the POC records on legacy resources, leaving the registration database as-is but issuing LOAs, etc.
> 
> Unless you believe that there's a way for ARIN to prohibit legacy non-RSA, non-LRSA block holders from doing these things.

ARIN will follow community-developed policy in this area for all records (including legacy resource holders), and service providers find the Whois database operationally useful as a result.  This includes the policies which have been adopted which specify how transfers should occur.  If these transfer policies aren't the right ones, then they should be fixed promptly, since presently attempts to assign number resources outside of policy can readily result in resource reclamation and reissuance.

Information on submitting policy proposals may be found here: <https://www.arin.net/policy/pdp_appendix_b.html>

/John

John Curran
President and CEO
ARIN




From jcurran at arin.net  Fri Nov  5 07:27:20 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 5 Nov 2010 07:27:20 -0400
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <39856.1288943608@tristatelogic.com>
References: <39856.1288943608@tristatelogic.com>
Message-ID: <76036B6C-C69D-451D-B2C8-0BBA036428CC@arin.net>

On Nov 5, 2010, at 3:53 AM, Ronald F. Guilmette wrote:
> 
> P.S.  Although it may seem otherwise, my actual goal is not to simply
> criticise or throw rocks at ARIN's existing utilization review processes,
> but rather to try to offer (if it would be accepted) some of my own tools
> and techniques to possibly aid and improve the utilization audit process
> further.  That would be a win-win all around I think... I and others would
> see fewer spammers on the net and the entire ARIN community might benefit
> from having more accurate utilization audits.  But in case it isn't obvious,
> I and other such wlling souls cannot possibly offer any improved technology
> which might be mixed in to improve the existing audit process if we... and
> everyone else on the planet... are all kept utterly in the dark about whatever
> ARIN currently is or isn't doing with respect to the conduct of these audits.

Ron - 
 
  ARIN would be happy to study and learn from any/all of your tools and
  techniques in this area, and would be happy to receive any information
  that you'd like to send in this area.  I'll note that some techniques
  in use by the anti-spam community may not meet the fairness and process 
  requirements that ARIN operates under, and I recognize that this may be
  annoying to you, but reflects the reality of our legal system.

  If you'd prefer to supply information on your tools and techniques under
  NDA, please send that to my attention or let me know and I'll send ARIN's
  NDA out for your review.

Best,
/John

John Curran
President and CEO
ARIN
 

From rfg at tristatelogic.com  Fri Nov  5 08:20:01 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Fri, 05 Nov 2010 05:20:01 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last Call
	(textrevised)
In-Reply-To: <E44E6428-C3AA-48A6-82A2-9FA24E98E018@delong.com> 
Message-ID: <45933.1288959601@tristatelogic.com>


In message <E44E6428-C3AA-48A6-82A2-9FA24E98E018 at delong.com>, 
Owen DeLong <owen at delong.com> wrote:

>
>On Nov 5, 2010, at 12:53 AM, Ronald F. Guilmette wrote:
>
>>
>> In message <DDE139AF-24A9-4F9A-B524-2CB78272E735 at delong.com>,
>> Owen DeLong <owen at delong.com> wrote:
>>> Why? There are very good reasons for ARIN not to publicly disclose the
>>> techniques and methods they use for conducting these audits.
>>
>> I'm listening.  What are those?
>> Do they outweigh the many obvious good reasons to have a clear and transparent
>> statement of the process that all members know they may be held to, without
>> prejudice or favor?
>>
>The process is documented in NRPM12 and is pretty clear.

I think not.  NRPM Section 12 describes in great detail _who_ may be audited
and _when_ they may be audited.  It doesn't say a damn thing about the ``how''
of auditing.

>The specific investigative techniques used inside of ARIN and they particular
>smell tests they use to discover fraud should not be disclosed because disclosure
>of the techniques makes it easier to circumvent them.

That assertion, even if taken as true, does not answer the question I asked.
I asked if the reasons you just stated for why the process should remain
secret _outweigh_ the reasons why it should be made transparent and public.

Granted, there may in some limited cases be some small advantage derived
from keeping the process secret and secretive, e.g. making the process
slightly harder to ``game''.  But what is that in comparison to the kind
of public trust that accrues to a transparent and open public process?

In this country, at least, we tend to favor the transparent, and the public,
over the secret and hidden.  In the words of late Supreme Court Justice
Louis Brandeis, ``Sunlight is the best disinfectant''.

Secrecy breeds suspicion.  And when I and others see some of the stuff that's
been going on... like the stuff attached to the end of this message...  we
_do_ start to wonder what _really_ goes on inside of ARIN.

>> And I am still awaiting even some small clue of what such {an audit}
>>might entail.
>>
>Have you read NRPM 12?

Yes, and it _still_ only describes the who and the when of auditing, and
it still avoids entirely the how of it.

>> Look, I think I've made my interest clear.  I believe, based on evidence,
>> that there is rampant and profligate waste and fraud in IPv4 allocations
>> within ARIN-land, and most of it is unambiguously in the service of spammers.
>
>Care to make any specific claims to back up that sweeping accusation?

I believe that I already did.  Didn't I just the other day post a list of
specific CIDRs that I believe are associated with fradulent WHOIS records?

If you want more, I'll give you more.  There's no shortage of such things,
believe me.

Just as some small additional examples, I am attaching below a list of all
currently announced routes for AS33475 and AS1632.  And also I am attaching
below those route listsing some listings of domain names that are getting
DNS from various addresses in blocks announced by those ASes.  (Notice how
they are all in big clumps of .com domains?)  Some of the routes for the
latter AS are associated with Level3 IP space, and since Level3
apparently escaped any requirement to properly create either ARIN whois
records or even rwhois records for their customers, I cannot say that
those specific routes are associated with ``fraud'' per se, but that's
only because in those cases, there _are_ no directly applicable whois or
rwhois records.

For the rest however, you can, I'm sure, find all of the relevant ARIN
AS and/or IP block whois records.  All of those are fradulent, to one
degree or another.  All this IP space, and all of the associated whois
records are being used as fradulent covers for a single large scale
snowshoe spamming operation located in Chicago.  Although this organization
does have, as you will see, quite a sizable farm of snowshoe spamming domains,
numbering over four thousand, I doubt that it has all that much in the way
of actual networking equipment and/or "hosts", and I don't believe that
the operation has any ``customers'' other than itself.  Still, as you will
see, it somehow has snookered its way past any possible ARIN vetting to
amass quite a lot of IP space.

This is just one example. There are plenty more where this came from.
And I haven't even mentioned the company in Southern California which
specializes in getting IP space for snowshoe spammers and which had
amassed over 500 separate /24s... most with associated fradulent ARIN
whois records... as of the last time I collated my data on them in detail,
about a year ago.  (They still have most of this space, I believe.)

I could go on and on.  The problem isn't finding this stuff.  The problem
is finding anybody in the ARIN community or in ARIN management who gives
a damn.

>As yet I am not convinced this is an accurate statement.

I know you're not.  I also know you haven't seen everything I have seen.
If you had, then you would have no doubts that fraud and waste are indeed
rampant and widespread in ARIN-land.

>Yes, we're running out of IPv4 addresses. Yes, there will probably be some
>people so stubbornly clinging to the idea of continuing to expand the IPv4
>legacy environment that they will be willing to surrender large sums of
>money towards doing so. Those same people have put off the migration to
>IPv6 within their organizations for years (close to a decade at this point)
>because they couldn't see the need. I have little sympathy for them.

Maybe, ya know, some of the people you are talking about _do not_ own
stock in Cisco or in Arbor, or in any other network hardware vendor.
And maybe some of them, like me, have seen that ICANN and its ilk have
fattened themselves at the trough of artificial ``scarcity'', e.g. in
the gTLDs, particularly .COM.  And maybe some of them, like me, know
that IPv4 could have been made to last forever... thus _not_ requiring
the expenditure of massive sums for an artifically created hardware
upgrade cycle... if only the 4 billion+ addresses had been ``shepherded''
properly, starting some long time ago. The fact that you personally have
no sympathy for such folks doesn't prove that they have acted in any-
thing other than a completely rational manner, nor does your personal
rapture over the benefits of IPv6 prove that the only rational course
of action for all players is to immediately switch over to that, lock,
stock, and barrel, and to expend the considerable sums that may be re-
quired in order to do so.

>As I see it, even if you consider "rampant and profligate waste", you 
>might expect
>ARIN to reclaim, what, maybe 10 /8s worth of space over the next 5 
>years? The
>internet is consuming 2 /8s per month. 2 per year isn't even a drop in 
>the bucket.

And who exactly is giving out those two /8s per month?  And what, if anything,
are those folks doing to encourage the wider use of NAT and/or to educate
the space-consuming community about its proper use and potential?

As someone else here just observed, you could most probably put Microsoft's
entire Redmond campus into a single /24 if you just simply did it right.

>Like it or not, reclamation is a slow, deliberate, careful process that 
>takes significant time.

Someone else here was just suggested a few ideas to speed that all up.
And those sounded pretty reasonable to me.

>IPv4 is a quagmire of allocations and assignments that
>were issued before ARIN existed. For those allocations and assignments,
>it's very unclear that ARIN has any authority to make such reclamations
>unless the resources are outright abandoned by the original recipient
>or voluntarily returned.

It is equally unclear that they lack such authority, but that is neither
here nor there, I think.  There are vast gobs of IPv4 space that have
succumbed to fraud, vast sums that have been lost to waste, and vast
amounts that are sitting idle, unused, and unrouted, even as we speak.

Hey now!  Here's an idea!  ARIN doesn't want to create a lot of conflict
with the legacy owners who are, in effect, squatting on (i.e. hoarding)
vast amounts of space that they don't even route.  OK.  Fine.  So instead
of ARIN going to these organizations and just rudely and unilaterally
announcing that they are ``taking'' or ``taking back'' the unused space,
how about if ARIN just instead told these organizations ``Hey, look,
we're real sorry about this, but you know, there's a shortage.  So, ummm...
that /10 you have lying fallow over there... well... um... we're going to
BORROW it from you for the next 12 months and let somebody else actually
USE the damn thing.  After that, unless you really have some use for it...
even a lame one... we may borrow it again for another 12 months.  But
don't worry!  No need to get uptight or to call your lawyer.  You still
are, and you will still be the one and only ``official registrant'' of
that space. OK?  No problem.  Thanks a bunch.  And here are two free
tickets to Disneyland, a copy of Yani's latest CD, and an official ARIN
coffee mug, all of which we will be sending to you in apperciation for
you're helping the community in this time of need.''

Well... it sounds a hell of a lot better than ``Get out of the way.  We
are here to repossess your IP space.''

>If you think there is rampant and profligate waste and fraud in space
>issued by ARIN since ARIN was formed...

Wait just a minute there.  Hold your horses.  You just slipped in a qualifier
that *I* never used.  I said that there's rampant and profligate waste and
fraud in ARIN-land, meaning in this RiR geographical region.  I did not
qualify that as being _only_ in post-ARIN-formation ARIN-allocated space,
nor did I qualify it as being in pre-ARIN space.  I didn't qualify it one
way or the other.

But yea, not that you bring it up, yes, most of the instances of fraud
and/or waste in the ARIN goegraphical region that I am seeing are indeed
related to post-ARIN-formation ARIN-allocated space.

>... please present evidence.

See below.  As I have said, there's plenty more where this came from.
And I really would like to know how non-existant entities managed to get
so much space allocated to them from ARIN.  It is truly stunning.

Yea yea yea.  I know what you are going to say... ``We can't tell you because
it is all confidential and all under NDA.''  Yea.  Right.  Bullcrap.  Please
explain gto me how ARIN has _any_ binding contractual commitments to totally
fradulent/fabricated entities which themselves have no legal existance?

This I gotta hear.

Take your time.

>I am of the impression that:
>
>	1.	There is not as much fraud and waste as some people 
>               would like to claim.

I understand that that is your impression.


>	5.	Reclamation for the sake of meeting the perceived needs for
>		a continuous supply of IPv4 addresses is like giving small
>		doses of heroin to a junky. It doesn't meet their physiological
>		needs but it continues their addiction.

Yea.  And while we are at it, lets' all run out and buy the biggest gas-guzzling
SUVs we can find, because after all, we all _know_ that we're going to run
out of recoverable oil reseves eventually anyway (and we already know that
the polar ice caps are doomed), so let's all live it up while the sun shines
are leave our grandchildren nothing.

Brilliant.


Regards,
rfg


P.S.  When investigating the existance, or lack thereof, of some alleged
``company'' (such as Layer8Colo, LLC, allegedly of Seattle, WA) it is helpful
to make use of this resource, which was prepared by my friend and fellow
anti-spam plaintiff, Dan Balsam:

   http://www.danhatesspam.com/sos.html

Now will somebody please tell me how a non-existant company manages to get
from ARIN _both_ (a) its own AS number and also (b) quite a lot of IPv4
address space.  (See below for AS1632.)

Yea yea yea.  I know. It's all covered under NDA and can't be revealed,
even though this hypothetical binding NDA was a contract entered into by
ARIN on the one hand, and by a bogus non-existant legal fiction on the
other hand.  So now please do remind me... In this case, ARIN has a legal
responsibility to who (or what) exactly?

Nevermind.  I think I know the answer already... "It's secret."  That seems
to be the answer to just about every question that ARIN wuld prefer not to
answer.




AS33475 routes:
--------------------
63.221.208.0/24
63.221.209.0/24
63.221.210.0/24
63.221.211.0/24
63.221.212.0/24
63.221.213.0/24
63.221.214.0/24
63.221.215.0/24
63.221.216.0/24
63.221.217.0/24
63.221.218.0/24
63.221.219.0/24
63.221.220.0/24
63.221.221.0/24
63.221.222.0/24
63.221.223.0/24
63.222.224.0/24
63.222.225.0/24
63.222.226.0/24
63.222.227.0/24
63.222.228.0/24
63.222.229.0/24
63.222.230.0/24
63.222.231.0/24
63.222.232.0/24
63.222.233.0/24
63.222.234.0/24
63.222.235.0/24
63.222.236.0/24
63.222.237.0/24
63.222.238.0/24
63.222.239.0/24
66.198.240.0/24
66.198.241.0/24
66.198.242.0/24
66.198.243.0/24
66.198.244.0/24
66.198.245.0/24
66.198.246.0/24
66.198.247.0/24
66.198.248.0/24
66.198.249.0/24
66.198.250.0/24
66.198.251.0/24
66.198.252.0/24
66.198.253.0/24
66.198.254.0/24
66.198.255.0/24
67.106.78.0/24
67.109.72.0/24
67.109.73.0/24
67.109.74.0/24
67.209.112.0/24
67.209.113.0/24
67.209.114.0/24
67.209.115.0/24
67.209.116.0/24
67.209.117.0/24
67.209.118.0/24
67.209.119.0/24
67.209.120.0/24
67.209.121.0/24
67.209.122.0/24
67.209.123.0/24
67.209.124.0/24
67.209.125.0/24
67.209.126.0/24
67.209.127.0/24
68.66.192.0/24
68.66.193.0/24
68.66.194.0/24
68.66.195.0/24
68.66.196.0/24
68.66.197.0/24
68.66.198.0/24
68.66.199.0/24
68.66.200.0/24
68.66.201.0/24
68.66.202.0/24
68.66.203.0/24
68.66.204.0/24
68.66.205.0/24
68.66.206.0/24
68.66.207.0/24
68.66.208.0/24
68.66.209.0/24
68.66.210.0/24
68.66.211.0/24
68.66.212.0/24
68.66.213.0/24
68.66.214.0/24
68.66.215.0/24
68.66.216.0/24
68.66.217.0/24
68.66.218.0/24
68.66.219.0/24
68.66.220.0/24
68.66.221.0/24
68.66.222.0/24
68.66.223.0/24
68.66.224.0/24
68.66.225.0/24
68.66.226.0/24
68.66.227.0/24
68.66.228.0/24
68.66.229.0/24
68.66.230.0/24
68.66.231.0/24
68.66.232.0/24
68.66.233.0/24
68.66.234.0/24
68.66.235.0/24
68.66.236.0/24
68.66.237.0/24
68.66.238.0/24
68.66.239.0/24
68.66.240.0/24
68.66.241.0/24
68.66.242.0/24
68.66.243.0/24
68.66.244.0/24
68.66.245.0/24
68.66.246.0/24
68.66.247.0/24
68.66.248.0/24
68.66.249.0/24
68.66.250.0/24
68.66.251.0/24
68.66.252.0/24
68.66.253.0/24
68.66.254.0/24
68.66.255.0/24
68.232.96.0/24
68.232.97.0/24
68.232.98.0/24
68.232.99.0/24
68.232.100.0/24
68.232.101.0/24
68.232.102.0/24
68.232.103.0/24
68.232.104.0/24
68.232.105.0/24
68.232.106.0/24
68.232.107.0/24
68.232.108.0/24
68.232.109.0/24
68.232.110.0/24
68.232.111.0/24
70.32.0.0/24
70.32.1.0/24
70.32.2.0/24
70.32.3.0/24
70.32.4.0/24
70.32.5.0/24
70.32.6.0/24
70.32.7.0/24
70.32.8.0/24
70.32.9.0/24
70.32.10.0/24
70.32.11.0/24
70.32.12.0/24
70.32.13.0/24
70.32.14.0/24
70.32.15.0/24
70.32.16.0/24
70.32.17.0/24
70.32.18.0/24
70.32.19.0/24
70.32.20.0/24
70.32.21.0/24
70.32.22.0/24
70.32.23.0/24
70.32.24.0/24
70.32.25.0/24
70.32.26.0/24
70.32.27.0/24
70.32.28.0/24
70.32.29.0/24
70.32.30.0/24
70.32.31.0/24
71.5.84.0/24
71.5.85.0/24
71.5.87.0/24
96.45.48.0/24
96.45.49.0/24
96.45.50.0/24
96.45.51.0/24
96.45.52.0/24
96.45.53.0/24
96.45.54.0/24
96.45.55.0/24
96.45.56.0/24
96.45.57.0/24
96.45.58.0/24
96.45.59.0/24
96.45.60.0/24
96.45.61.0/24
96.45.62.0/24
96.45.63.0/24
205.177.88.0/24
205.177.90.0/24
205.177.91.0/24
205.177.92.0/24
205.177.93.0/24
206.173.132.0/24
206.173.133.0/24
206.173.134.0/24


AS1632 routes:
-----------------------
8.24.112.0/24
8.24.113.0/24
8.24.114.0/24
8.24.115.0/24
8.24.116.0/24
8.24.117.0/24
8.24.118.0/24
8.24.119.0/24
8.24.120.0/24
8.24.121.0/24
8.24.122.0/24
8.24.123.0/24
8.24.124.0/24
8.24.125.0/24
8.24.126.0/24
8.24.127.0/24
96.45.144.0/20
205.186.208.0/24
205.186.209.0/24
205.186.210.0/24
205.186.211.0/24
205.186.212.0/24
205.186.213.0/24
205.186.214.0/24
205.186.215.0/24
205.186.216.0/24
205.186.217.0/24
205.186.218.0/24
205.186.219.0/24
205.186.220.0/24
205.186.221.0/24
205.186.222.0/24
205.186.223.0/24
207.226.192.0/24
207.226.193.0/24
207.226.194.0/24
207.226.195.0/24
207.226.196.0/24
207.226.197.0/24
207.226.198.0/24
207.226.199.0/24
207.226.200.0/24
207.226.201.0/24
207.226.202.0/24
207.226.203.0/24
207.226.204.0/24
207.226.205.0/24
207.226.206.0/24
207.226.207.0/24


AS33475 domains (snowshoe):
-----------------------------
63.221.209.2 1
	ns1.marlaug.com 32
		incorpartewisehealth.com
		comfortinsol.com
		peformancewortha.com
		getanaplus.com
		researchinmovement.com
		entreethrudraft.com
		thebrightoncorp.com
		chronicsnackshop.com
		thedealupdate.com
		wellnesswary.com
		muchatchronic.com
		accessbydsign.com
		restorecomprom.com
		healthwiseinc.com
		extraplusa.com
		exploreinmotion.com
		neverendingsnacks.com
		aplusperfom.com
		corporationbrighton.com
		workwithbright.com
		inquiryinmotion.com
		reviseconcepts.com
		relaxatsolace.com
		admissionviaart.com
		pactadvocate.com
		getyoursolace.com
		connectionwithmotif.com
		brightoncorps.com
		researchinchange.com
		yummysnackschr.com
		vigoreducation.com
		thereliefspa.com
63.221.209.3 1
	ns2.marlaug.com 32
		incorpartewisehealth.com
		comfortinsol.com
		peformancewortha.com
		getanaplus.com
		researchinmovement.com
		entreethrudraft.com
		thebrightoncorp.com
		chronicsnackshop.com
		thedealupdate.com
		wellnesswary.com
		muchatchronic.com
		accessbydsign.com
		restorecomprom.com
		healthwiseinc.com
		extraplusa.com
		exploreinmotion.com
		neverendingsnacks.com
		aplusperfom.com
		corporationbrighton.com
		workwithbright.com
		inquiryinmotion.com
		reviseconcepts.com
		relaxatsolace.com
		admissionviaart.com
		pactadvocate.com
		getyoursolace.com
		connectionwithmotif.com
		brightoncorps.com
		researchinchange.com
		yummysnackschr.com
		vigoreducation.com
		thereliefspa.com
63.221.210.2 1
	ns1.dethrod.com 32
		notforpupssupply.com
		marketzillsa.com
		webmarketzilla.com
		thefooodguy.com
		riversidemgmtcomp.com
		floristmcshan.com
		bankelevationadmin.com
		aerialden.com
		captainssecret.com
		flowersbymcs.com
		marketzillaonline.com
		eaglenestshere.com
		chickenfoodguy.com
		bigcaninegoods.com
		stockpooch.com
		managebytheriver.com
		weflylikeeagles.com
		streamrimorg.com
		theeatguy.com
		navigatoraeire.com
		brookboundarydirect.com
		bulldogsupplyonline.com
		budwithmc.com
		manaboutfood.com
		irishblooms.com
		creekborderexec.com
		runaspectco.com
		eaglesnestnet.com
		aviatorathome.com
		waterwayface.com
		tradezillsa.com
		pilotsquat.com
63.221.210.3 1
	ns2.dethrod.com 32
		notforpupssupply.com
		marketzillsa.com
		webmarketzilla.com
		thefooodguy.com
		riversidemgmtcomp.com
		floristmcshan.com
		bankelevationadmin.com
		aerialden.com
		captainssecret.com
		flowersbymcs.com
		marketzillaonline.com
		eaglenestshere.com
		chickenfoodguy.com
		bigcaninegoods.com
		stockpooch.com
		managebytheriver.com
		weflylikeeagles.com
		streamrimorg.com
		theeatguy.com
		navigatoraeire.com
		brookboundarydirect.com
		bulldogsupplyonline.com
		budwithmc.com
		manaboutfood.com
		irishblooms.com
		creekborderexec.com
		runaspectco.com
		eaglesnestnet.com
		aviatorathome.com
		waterwayface.com
		tradezillsa.com
		pilotsquat.com
63.221.211.2 1
	ns1.panegma.com 32
		theconnectingpt.com
		divanjoint.com
		bunktalus.com
		bestislastprdc.com
		advertizefusion.com
		admixturepromos.com
		rhomboidfellow.com
		quartetswainprep.com
		trundleossein.com
		lastmanonfour.com
		blenderpubrel.com
		bridgecrossingbit.com
		cruiseondls.com
		tetradbrother.com
		mixturecommunications.com
		melangecmun.com
		bargnavigation.com
		pluggedmite.com
		thedealcrossing.com
		productionfourthman.com
		pointlinking.com
		numberfourevents.com
		intermixpress.com
		hookflyspeck.com
		crossfordeals.com
		connexparticle.com
		combiningspeck.com
		bednbone.com
		alloypulicity.com
		affixingiota.com
		comboediting.com
		quadbeauresults.com
63.221.211.3 1
	ns2.panegma.com 32
		theconnectingpt.com
		divanjoint.com
		bunktalus.com
		bestislastprdc.com
		advertizefusion.com
		admixturepromos.com
		rhomboidfellow.com
		quartetswainprep.com
		trundleossein.com
		lastmanonfour.com
		blenderpubrel.com
		bridgecrossingbit.com
		cruiseondls.com
		tetradbrother.com
		mixturecommunications.com
		melangecmun.com
		bargnavigation.com
		pluggedmite.com
		thedealcrossing.com
		productionfourthman.com
		pointlinking.com
		numberfourevents.com
		intermixpress.com
		hookflyspeck.com
		crossfordeals.com
		connexparticle.com
		combiningspeck.com
		bednbone.com
		alloypulicity.com
		affixingiota.com
		comboediting.com
		quadbeauresults.com
63.221.212.2 1
	ns1.kaycle.com 32
		gettpro.com
		contractorssmart.com
		acryldeal.com
		weboffersector.com
		tpbest.com
		storecatanese.com
		onlineoffersector.com
		sbrothersbuy.com
		onlinecatanese.com
		onacrylitech.com
		netacrylitech.com
		tilenew.com
		newsoffersector.com
		schweikertclick.com
		getoffersector.com
		conprobest.com
		firetecs.com
		proconbiz.com
		restoraidbiz.com
		catanesemarket.com
		acrylitechs.com
		linkrestdeal.com
		cataneses.com
		firetecbuy.com
		restoraids.com
		restdealalert.com
		profcreative.com
		profiretec.com
		schweikertbiz.com
		contractorsbuy.com
		tilecode.com
		sbrotherslink.com
63.221.212.3 1
	ns2.kaycle.com 32
		gettpro.com
		contractorssmart.com
		acryldeal.com
		weboffersector.com
		tpbest.com
		storecatanese.com
		onlineoffersector.com
		sbrothersbuy.com
		onlinecatanese.com
		onacrylitech.com
		netacrylitech.com
		tilenew.com
		newsoffersector.com
		schweikertclick.com
		getoffersector.com
		conprobest.com
		firetecs.com
		proconbiz.com
		restoraidbiz.com
		catanesemarket.com
		acrylitechs.com
		linkrestdeal.com
		cataneses.com
		firetecbuy.com
		restoraids.com
		restdealalert.com
		profcreative.com
		profiretec.com
		schweikertbiz.com
		contractorsbuy.com
		tilecode.com
		sbrotherslink.com
63.221.213.2 1
	ns1.bomberta.com 32
		tigerairsale.com
		offersectormarket.com
		tigerairbiz.com
		paragonbuy.com
		tradejk.com
		tprogroup.com
		tigerairbuy.com
		jkclick.com
		bizparagon.com
		sourcejk.com
		offersectors.com
		paragongrouptrade.com
		oneparagon.com
		onlineitemsgalore.com
		tbizcash.com
		paragongroupsource.com
		paragonworlds.com
		clickjagger.com
		newoffsector.com
		paragondeal.com
		galorehome.com
		fromts.com
		dealoffernetwork.com
		galorenew.com
		tbizs.com
		tonlines.com
		jkcares.com
		itemsgalores.com
		dealjandk.com
		paragongrouplive.com
		jaggerdeal.com
		jaggercone.com
63.221.213.3 1
	ns2.bomberta.com 32
		tigerairsale.com
		offersectormarket.com
		tigerairbiz.com
		paragonbuy.com
		tradejk.com
		tprogroup.com
		tigerairbuy.com
		jkclick.com
		bizparagon.com
		sourcejk.com
		offersectors.com
		paragongrouptrade.com
		oneparagon.com
		onlineitemsgalore.com
		tbizcash.com
		paragongroupsource.com
		paragonworlds.com
		clickjagger.com
		newoffsector.com
		paragondeal.com
		galorehome.com
		fromts.com
		dealoffernetwork.com
		galorenew.com
		tbizs.com
		tonlines.com
		jkcares.com
		itemsgalores.com
		dealjandk.com
		paragongrouplive.com
		jaggerdeal.com
		jaggercone.com
63.221.214.2 1
	ns1.tacapr.com 32
		iwataworld.com
		greeniwata.com
		locksabusiness.com
		aroundglobalco.com
		onemle.com
		mleshop.com
		youlocksa.com
		webmle.com
		globalcodeal.com
		homelocksa.com
		locksabiz.com
		dealoffersector.com
		automle.com
		offersectorstore.com
		mlenterprisespro.com
		newslocksa.com
		marketkldenterprises.com
		globalcoshop.com
		oneiwata.com
		mlebiz.com
		locksa.com
		shoplocksa.com
		netkld.com
		bestoffersector.com
		marketmle.com
		offersectorsite.com
		kldentlife.com
		kldent.com
		iwataforyou.com
		clickglobalco.com
		buymle.com
		thelocksa.com
63.221.214.3 1
	ns2.tacapr.com 32
		iwataworld.com
		greeniwata.com
		locksabusiness.com
		aroundglobalco.com
		onemle.com
		mleshop.com
		youlocksa.com
		webmle.com
		globalcodeal.com
		homelocksa.com
		locksabiz.com
		dealoffersector.com
		automle.com
		offersectorstore.com
		mlenterprisespro.com
		newslocksa.com
		marketkldenterprises.com
		globalcoshop.com
		oneiwata.com
		mlebiz.com
		locksa.com
		shoplocksa.com
		netkld.com
		bestoffersector.com
		marketmle.com
		offersectorsite.com
		kldentlife.com
		kldent.com
		iwataforyou.com
		clickglobalco.com
		buymle.com
		thelocksa.com
63.221.215.2 1
	ns1.gerretum.com 32
		kmhsupplygroup.com
		homekmh.com
		aserviceshome.com
		loveparma.com
		adelinagroup.com
		intbazaar.com
		ablesbiz.com
		parmalogs.com
		kmhsupplys.com
		shopkmh.com
		aserviceslist.com
		trademromax.com
		offersectorinc.com
		findadelina.com
		bizoffersectorinc.com
		offsector.com
		bizwithadelina.com
		bcandys.com
		intbazaaronline.com
		clickcandybreak.com
		internationalbazaars.com
		parmaworlds.com
		adhomeshop.com
		ablesclick.com
		promromax.com
		offersectorincdeal.com
		newmromax.com
		mromaxs.com
		internationalbazaarmarket.com
		bcandyonline.com
		parmabest.com
		buycandybreak.com
63.221.215.3 1
	ns2.gerretum.com 32
		kmhsupplygroup.com
		homekmh.com
		aserviceshome.com
		loveparma.com
		adelinagroup.com
		intbazaar.com
		ablesbiz.com
		parmalogs.com
		kmhsupplys.com
		shopkmh.com
		aserviceslist.com
		trademromax.com
		offersectorinc.com
		findadelina.com
		bizoffersectorinc.com
		offsector.com
		bizwithadelina.com
		bcandys.com
		intbazaaronline.com
		clickcandybreak.com
		internationalbazaars.com
		parmaworlds.com
		adhomeshop.com
		ablesclick.com
		promromax.com
		offersectorincdeal.com
		newmromax.com
		mromaxs.com
		internationalbazaarmarket.com
		bcandyonline.com
		parmabest.com
		buycandybreak.com
63.221.216.2 1
	ns1.clasko.com 32
		examinedy.com
		epinexam.com
		allyreaserch.com
		reaserchsker.com
		brireview.com
		losmonitor.com
		exotscdata.com
		tscmple.com
		thesurveyno.com
		reviewspar.com
		pollsion.com
		tscdataex.com
		inspectdo.com
		opinionuist.com
		reportsinternet.com
		citypollma.com
		casttsc.com
		examteca.com
		thesurveyitalics.com
		studyce.com
		reviewayer.com
		marketsearchon.com
		misexamine.com
		surveyen.com
		gruopinion.com
		dissurvey.com
		thesurveyclicking.com
		neoexamsas.com
		ghstudy.com
		websurveyed.com
		tscdatavide.com
		polliary.com
63.221.216.3 1
	ns2.clasko.com 32
		examinedy.com
		epinexam.com
		allyreaserch.com
		reaserchsker.com
		brireview.com
		losmonitor.com
		exotscdata.com
		tscmple.com
		thesurveyno.com
		reviewspar.com
		pollsion.com
		tscdataex.com
		inspectdo.com
		opinionuist.com
		reportsinternet.com
		citypollma.com
		casttsc.com
		examteca.com
		thesurveyitalics.com
		studyce.com
		reviewayer.com
		marketsearchon.com
		misexamine.com
		surveyen.com
		gruopinion.com
		dissurvey.com
		thesurveyclicking.com
		neoexamsas.com
		ghstudy.com
		websurveyed.com
		tscdatavide.com
		polliary.com
63.221.217.2 1
	ns1.clondiko.com 26
		monitorwo.com
		analyzereportby.com
		analyzedatail.com
		inspectsurveyon.com
		dataenginees.com
		actionella.com
		eufigure.com
		figureabao.com
		wallthecalculate.com
		lomonitoring.com
		flexamineopinion.com
		almaction.com
		pinmarketnoise.com
		lynexamineopinion.com
		analyzedatasity.com
		abcalculate.com
		theopinionasum.com
		blanalyzedata.com
		monitoringpuzz.com
		impanalyzereport.com
		dataenginebond.com
		cantestthem.com
		thecalculateoter.com
		monitorania.com
		marketnoisess.com
		anotheopinion.com
63.221.217.3 1
	ns2.clondiko.com 26
		monitorwo.com
		analyzereportby.com
		analyzedatail.com
		inspectsurveyon.com
		dataenginees.com
		actionella.com
		eufigure.com
		figureabao.com
		wallthecalculate.com
		lomonitoring.com
		flexamineopinion.com
		almaction.com
		pinmarketnoise.com
		lynexamineopinion.com
		analyzedatasity.com
		abcalculate.com
		theopinionasum.com
		blanalyzedata.com
		monitoringpuzz.com
		impanalyzereport.com
		dataenginebond.com
		cantestthem.com
		thecalculateoter.com
		monitorania.com
		marketnoisess.com
		anotheopinion.com
63.221.218.2 1
	ns1.clikonik.com 40
		tcspowerurry.com
		seetscbase.com
		thesurveymasteral.com
		setsurveyon.com
		datapushwo.com
		optinclicker.com
		powersurveyck.com
		humanpollarna.com
		citisurveyweb.com
		yoroundtable.com
		thesurveycollectorio.com
		tcspowerse.com
		opinioneerty.com
		humanpollli.com
		focusgroupwill.com
		thesurveymasterym.com
		sinaroundtable.com
		resultiker.com
		wikisurveyss.com
		youropinionwn.com
		surveyresultorch.com
		seetscni.com
		petresultcollector.com
		opinionbasege.com
		clickabouton.com
		calculationck.com
		recoversurvey.com
		pushopiniontype.com
		focusgroupel.com
		resultcollectorst.com
		tosetsurvey.com
		thesurveyth.com
		surveywebesto.com
		opinionbaseed.com
		minecalculation.com
		exroundtable.com
		resultikot.com
		pushopinioner.com
		thesurveycollectoryard.com
		anodatapush.com
63.221.218.3 1
	ns2.clikonik.com 40
		tcspowerurry.com
		seetscbase.com
		thesurveymasteral.com
		setsurveyon.com
		datapushwo.com
		optinclicker.com
		powersurveyck.com
		humanpollarna.com
		citisurveyweb.com
		yoroundtable.com
		thesurveycollectorio.com
		tcspowerse.com
		opinioneerty.com
		humanpollli.com
		focusgroupwill.com
		thesurveymasterym.com
		sinaroundtable.com
		resultiker.com
		wikisurveyss.com
		youropinionwn.com
		surveyresultorch.com
		seetscni.com
		petresultcollector.com
		opinionbasege.com
		clickabouton.com
		calculationck.com
		recoversurvey.com
		pushopiniontype.com
		focusgroupel.com
		resultcollectorst.com
		tosetsurvey.com
		thesurveyth.com
		surveywebesto.com
		opinionbaseed.com
		minecalculation.com
		exroundtable.com
		resultikot.com
		pushopinioner.com
		thesurveycollectoryard.com
		anodatapush.com
63.221.219.2 1
	ns1.plannation.com 32
		surveysbusiness.com
		gatherbeat.com
		blendconnect.com
		findevaluatesurvey.com
		mailpolls.com
		clickersurvey.com
		massscreen.com
		clickerevaluate.com
		casesurveyclick.com
		surveysdeal.com
		registerblend.com
		surveysbook.com
		maxsnap.com
		experimentbeat.com
		jibemonitor.com
		webpollsurvey.com
		transpirereview.com
		surveysmail.com
		rapportfile.com
		pollsfun.com
		concordsurvey.com
		beatcompare.com
		zoomsnapdigest.com
		snapemaildigest.com
		referendumdata.com
		pollssearch.com
		pokeregister.com
		officesnapdigest.com
		digitalsurveyz.com
		coderapport.com
		achieverzsearch.com
		studybizz.com
63.221.219.3 1
	ns2.plannation.com 32
		surveysbusiness.com
		gatherbeat.com
		blendconnect.com
		findevaluatesurvey.com
		mailpolls.com
		clickersurvey.com
		massscreen.com
		clickerevaluate.com
		casesurveyclick.com
		surveysdeal.com
		registerblend.com
		surveysbook.com
		maxsnap.com
		experimentbeat.com
		jibemonitor.com
		webpollsurvey.com
		transpirereview.com
		surveysmail.com
		rapportfile.com
		pollsfun.com
		concordsurvey.com
		beatcompare.com
		zoomsnapdigest.com
		snapemaildigest.com
		referendumdata.com
		pollssearch.com
		pokeregister.com
		officesnapdigest.com
		digitalsurveyz.com
		coderapport.com
		achieverzsearch.com
		studybizz.com
63.221.220.253 1
	ns1.singzen.com 32
		surveysbuy.com
		updatemass.com
		measureconcord.com
		pollsdeal.com
		electioneasyaccord.com
		motivatorsearch.com
		maxianalyzer.com
		experimentbreak.com
		pollsnapzone.com
		surveysart.com
		solutionsstudy.com
		chartmass.com
		codepolls.com
		chartblend.com
		verifyblend.com
		referenduminfo.com
		homepolls.com
		testtranspire.com
		surveyattache.com
		referendumsolutions.com
		referendummedia.com
		processjibe.com
		evaluatepollpage.com
		dealssnap.com
		concordcompare.com
		breakcritique.com
		blendclassify.com
		testharmony.com
		surveysblue.com
		pollsbiz.com
		datajibed.com
		chartpoke.com
63.221.220.254 1
	ns2.singzen.com 32
		surveysbuy.com
		updatemass.com
		measureconcord.com
		pollsdeal.com
		electioneasyaccord.com
		motivatorsearch.com
		maxianalyzer.com
		experimentbreak.com
		pollsnapzone.com
		surveysart.com
		solutionsstudy.com
		chartmass.com
		codepolls.com
		chartblend.com
		verifyblend.com
		referenduminfo.com
		homepolls.com
		testtranspire.com
		surveyattache.com
		referendumsolutions.com
		referendummedia.com
		processjibe.com
		evaluatepollpage.com
		dealssnap.com
		concordcompare.com
		breakcritique.com
		blendclassify.com
		testharmony.com
		surveysblue.com
		pollsbiz.com
		datajibed.com
		chartpoke.com
63.221.221.2 1
	ns1.teccup.com 24
		surveyscity.com
		electioncode.com
		transpirecompare.com
		surveysfly.com
		harmonyexperiment.com
		nextsnapdigest.com
		extractconcord.com
		evaluatesurvey.com
		themodelplex.com
		surveyshost.com
		sourcesnap.com
		snapnext.com
		respondpoke.com
		pollclickbiz.com
		pokecompile.com
		massclassify.com
		grouppolls.com
		fusionsnap.com
		dealstudy.com
		critiquepop.com
		popexamine.com
		pollsclick.com
		compolls.com
		snapjumppoll.com
63.221.221.3 1
	ns2.teccup.com 24
		surveyscity.com
		electioncode.com
		transpirecompare.com
		surveysfly.com
		harmonyexperiment.com
		nextsnapdigest.com
		extractconcord.com
		evaluatesurvey.com
		themodelplex.com
		surveyshost.com
		sourcesnap.com
		snapnext.com
		respondpoke.com
		pollclickbiz.com
		pokecompile.com
		massclassify.com
		grouppolls.com
		fusionsnap.com
		dealstudy.com
		critiquepop.com
		popexamine.com
		pollsclick.com
		compolls.com
		snapjumppoll.com
63.222.224.2 2
	ns2.optimediamail.com 1
		optimediamail.com
	ns1.optimediamail.com 1
		optimediamail.com
63.222.225.2 1
	ns1.choussi.com 30
		publicityedge.com
		reviewendurance.com
		logcommunication.com
		classifycommunication.com
		paradoxdelegate.com
		increaseparadox.com
		clarifystatistics.com
		reviewimpro.com
		revitalizereality.com
		photographfacts.com
		studiesfocus.com
		realityillustrate.com
		evaluationmetropolis.com
		detectdistribution.com
		instilmarketing.com
		collaborateadvertising.com
		densityextract.com
		surveycommunicate.com
		merchandisingmediate.com
		factsoriginate.com
		motivatepress.com
		promogenerate.com
		plemedia.com
		transmitstudies.com
		statisticspromote.com
		holsurvey.com
		formulatemerchandising.com
		extractpromotion.com
		presscompute.com
		advertisingjoin.com
63.222.225.3 1
	ns2.choussi.com 30
		publicityedge.com
		reviewendurance.com
		logcommunication.com
		classifycommunication.com
		paradoxdelegate.com
		increaseparadox.com
		clarifystatistics.com
		reviewimpro.com
		revitalizereality.com
		photographfacts.com
		studiesfocus.com
		realityillustrate.com
		evaluationmetropolis.com
		detectdistribution.com
		instilmarketing.com
		collaborateadvertising.com
		densityextract.com
		surveycommunicate.com
		merchandisingmediate.com
		factsoriginate.com
		motivatepress.com
		promogenerate.com
		plemedia.com
		transmitstudies.com
		statisticspromote.com
		holsurvey.com
		formulatemerchandising.com
		extractpromotion.com
		presscompute.com
		advertisingjoin.com
63.222.226.2 1
	ns1.gistodwi.com 32
		surveydistribution.com
		createfacts.com
		villageevaluation.com
		registerconnections.com
		publicizestatistics.com
		appraisepress.com
		factsmodel.com
		evaluationcity.com
		teachstudies.com
		reviewvital.com
		studiesstimulate.com
		reviewrhythm.com
		connectionscatalogue.com
		discussstatistics.com
		merchandisingfurnish.com
		draftadvertising.com
		surveypromote.com
		supplycommunication.com
		contractparadox.com
		advertisingpublicize.com
		realityshape.com
		testpromotion.com
		mediarket.com
		merchandisingrecruit.com
		classifyconnections.com
		paradoxlead.com
		connectionsroute.com
		speakmerchandising.com
		pressprovide.com
		enlistadvertising.com
		conductmarketing.com
		apppublicity.com
63.222.226.3 1
	ns2.gistodwi.com 32
		surveydistribution.com
		createfacts.com
		villageevaluation.com
		registerconnections.com
		publicizestatistics.com
		appraisepress.com
		factsmodel.com
		evaluationcity.com
		teachstudies.com
		reviewvital.com
		studiesstimulate.com
		reviewrhythm.com
		connectionscatalogue.com
		discussstatistics.com
		merchandisingfurnish.com
		draftadvertising.com
		surveypromote.com
		supplycommunication.com
		contractparadox.com
		advertisingpublicize.com
		realityshape.com
		testpromotion.com
		mediarket.com
		merchandisingrecruit.com
		classifyconnections.com
		paradoxlead.com
		connectionsroute.com
		speakmerchandising.com
		pressprovide.com
		enlistadvertising.com
		conductmarketing.com
		apppublicity.com
63.222.227.253 1
	ns1.grugreve.com 26
		surveywrite.com
		factsdisplay.com
		attainparadox.com
		qualifypress.com
		planreality.com
		loudreview.com
		communicatesurvey.com
		superstarreview.com
		paradoxrecommend.com
		publicityemail.com
		operateconnections.com
		motivatestudies.com
		promoschedule.com
		performfacts.com
		connectionslog.com
		evaluationavenue.com
		conductpromotion.com
		fitpublicity.com
		presssimplify.com
		mediatoty.com
		displayreality.com
		strengthenpromo.com
		strongreview.com
		synthesizestatistics.com
		studiestransmit.com
		reportstatistics.com
63.222.227.254 1
	ns2.grugreve.com 26
		surveywrite.com
		factsdisplay.com
		attainparadox.com
		qualifypress.com
		planreality.com
		loudreview.com
		communicatesurvey.com
		superstarreview.com
		paradoxrecommend.com
		publicityemail.com
		operateconnections.com
		motivatestudies.com
		promoschedule.com
		performfacts.com
		connectionslog.com
		evaluationavenue.com
		conductpromotion.com
		fitpublicity.com
		presssimplify.com
		mediatoty.com
		displayreality.com
		strengthenpromo.com
		strongreview.com
		synthesizestatistics.com
		studiestransmit.com
		reportstatistics.com
63.222.228.2 1
	ns1.roriell.com 32
		benefitsbase.com
		glorebates.com
		tareplatinum.com
		werebates.com
		deductionlo.com
		chiallurement.com
		micreward.com
		hoobuilder.com
		allidesigner.com
		adaptdiscount.com
		tareing.com
		guruconstructor.com
		eventtare.com
		discountdeed.com
		constructorlinks.com
		specializediscount.com
		shopallurement.com
		solutionconstructor.com
		builderly.com
		createrollback.com
		rollbacket.com
		panrollback.com
		rollbackcyber.com
		zininventor.com
		subbenefits.com
		premiumperform.com
		laimpulse.com
		deductionshop.com
		benefitsow.com
		achreward.com
		motivationtery.com
		discountcritique.com
63.222.228.3 1
	ns2.roriell.com 32
		benefitsbase.com
		glorebates.com
		tareplatinum.com
		werebates.com
		deductionlo.com
		chiallurement.com
		micreward.com
		hoobuilder.com
		allidesigner.com
		adaptdiscount.com
		tareing.com
		guruconstructor.com
		eventtare.com
		discountdeed.com
		constructorlinks.com
		specializediscount.com
		shopallurement.com
		solutionconstructor.com
		builderly.com
		createrollback.com
		rollbacket.com
		panrollback.com
		rollbackcyber.com
		zininventor.com
		subbenefits.com
		premiumperform.com
		laimpulse.com
		deductionshop.com
		benefitsow.com
		achreward.com
		motivationtery.com
		discountcritique.com
63.222.229.253 1
	ns1.sentagma.com 30
		dopremium.com
		allurementsavings.com
		yetreward.com
		premiumestablish.com
		nessdesigner.com
		taregold.com
		learntare.com
		inventorro.com
		condiscount.com
		taredigi.com
		designerdste.com
		linkstare.com
		energyrollback.com
		rollbackal.com
		rewardmini.com
		impulserest.com
		rollbackbrain.com
		platinumconstructor.com
		libenefits.com
		discountfortify.com
		subpdeduction.com
		smarbuilder.com
		forexconstructor.com
		entertaindiscount.com
		benefitsdrive.com
		discountexplore.com
		constructormix.com
		sigrollback.com
		rollbackchat.com
		plerebates.com
63.222.229.254 1
	ns2.sentagma.com 30
		dopremium.com
		allurementsavings.com
		yetreward.com
		premiumestablish.com
		nessdesigner.com
		taregold.com
		learntare.com
		inventorro.com
		condiscount.com
		taredigi.com
		designerdste.com
		linkstare.com
		energyrollback.com
		rollbackal.com
		rewardmini.com
		impulserest.com
		rollbackbrain.com
		platinumconstructor.com
		libenefits.com
		discountfortify.com
		subpdeduction.com
		smarbuilder.com
		forexconstructor.com
		entertaindiscount.com
		benefitsdrive.com
		discountexplore.com
		constructormix.com
		sigrollback.com
		rollbackchat.com
		plerebates.com
63.222.230.2 1
	ns1.tidemi.com 28
		builderye.com
		rollbackads.com
		ransreward.com
		impulsery.com
		expmotivation.com
		abfdesigner.com
		plandeduction.com
		benefitsindex.com
		discountdebug.com
		designerng.com
		constructorcyber.com
		tarecare.com
		microtare.com
		allurementmarket.com
		rewardovel.com
		premiumcreate.com
		iminventor.com
		constructorcam.com
		rollbackre.com
		rollbackmili.com
		tareace.com
		discountto.com
		perdesigner.com
		discountlocate.com
		benefitsworm.com
		rebatesst.com
		givepremium.com
		revitalizediscount.com
63.222.230.3 1
	ns2.tidemi.com 28
		builderye.com
		rollbackads.com
		ransreward.com
		impulsery.com
		expmotivation.com
		abfdesigner.com
		plandeduction.com
		benefitsindex.com
		discountdebug.com
		designerng.com
		constructorcyber.com
		tarecare.com
		microtare.com
		allurementmarket.com
		rewardovel.com
		premiumcreate.com
		iminventor.com
		constructorcam.com
		rollbackre.com
		rollbackmili.com
		tareace.com
		discountto.com
		perdesigner.com
		discountlocate.com
		benefitsworm.com
		rebatesst.com
		givepremium.com
		revitalizediscount.com
63.222.231.2 1
	ns1.scoccos.com 28
		consumerli.com
		luckybuyerfind.com
		allebetter.com
		branfaves.com
		balconsumnow.com
		allabouttopproduct.com
		airbestpurchase.com
		mustbuyer.com
		shophighclick.com
		marketcynical.com
		marketcinail.com
		capsumarket.com
		buyerspoints.com
		needconsumerhere.com
		musthavealotus.com
		lawhappyfaves.com
		isconsumer.com
		crazypurchaser.com
		betterbuysy.com
		findthebests.com
		lifeisshoppings.com
		shophighs.com
		productsaround.com
		cavapopular.com
		gottahaveitbest.com
		olifavoriteplace.com
		spenditalls.com
		comfortbuyhere.com
63.222.231.3 1
	ns2.scoccos.com 28
		consumerli.com
		luckybuyerfind.com
		allebetter.com
		branfaves.com
		balconsumnow.com
		allabouttopproduct.com
		airbestpurchase.com
		mustbuyer.com
		shophighclick.com
		marketcynical.com
		marketcinail.com
		capsumarket.com
		buyerspoints.com
		needconsumerhere.com
		musthavealotus.com
		lawhappyfaves.com
		isconsumer.com
		crazypurchaser.com
		betterbuysy.com
		findthebests.com
		lifeisshoppings.com
		shophighs.com
		productsaround.com
		cavapopular.com
		gottahaveitbest.com
		olifavoriteplace.com
		spenditalls.com
		comfortbuyhere.com
63.222.232.2 1
	ns1.constarcos.com 30
		forconsumte.com
		profishoppers.com
		marketplacearound.com
		betterthanmoneys.com
		bestpurchasera.com
		popularplacehot.com
		consfestivalgosp.com
		comebuyitall.com
		consumnowtr.com
		fiestaforyou.com
		allallpurchaser.com
		zirchappyfaves.com
		variconfaves.com
		listtohave.com
		everyspendmy.com
		betterrase.com
		spenddollar.com
		purchsional.com
		jianmarket.com
		favoritferb.com
		franklyspendnt.com
		consumerpointan.com
		comebuyitalls.com
		buyconcepts.com
		albestforyou.com
		safebuybiz.com
		pleasurepointti.com
		heretopurchase.com
		shopomaniacs.com
		allfordime.com
63.222.232.3 1
	ns2.constarcos.com 30
		forconsumte.com
		profishoppers.com
		marketplacearound.com
		betterthanmoneys.com
		bestpurchasera.com
		popularplacehot.com
		consfestivalgosp.com
		comebuyitall.com
		consumnowtr.com
		fiestaforyou.com
		allallpurchaser.com
		zirchappyfaves.com
		variconfaves.com
		listtohave.com
		everyspendmy.com
		betterrase.com
		spenddollar.com
		purchsional.com
		jianmarket.com
		favoritferb.com
		franklyspendnt.com
		consumerpointan.com
		comebuyitalls.com
		buyconcepts.com
		albestforyou.com
		safebuybiz.com
		pleasurepointti.com
		heretopurchase.com
		shopomaniacs.com
		allfordime.com
63.222.233.2 1
	ns1.scuderos.com 32
		seergemarket.com
		moneyisnothings.com
		shiproductforall.com
		shoppoterapy.com
		expworldofall.com
		consumerheavenom.com
		newsforseller.com
		letforbuyogra.com
		wishmixtter.com
		marketmixs.com
		comeandbuyfish.com
		favoritetobuy.com
		closertoyourwishpful.com
		worldofallca.com
		reepurchase.com
		mysbuybuycons.com
		favoritestochoose.com
		pleasurepointcter.com
		consumerpointns.com
		consumerlifeishere.com
		allpurchaseray.com
		tifranklyspend.com
		storefavesti.com
		profishopperub.com
		nodoubttospend.com
		zebrabunchofall.com
		marketeyebest.com
		sandcomeandbuy.com
		forcoinphil.com
		comeverydaysale.com
		everydaysaledsto.com
		conlafiesta.com
63.222.233.3 1
	ns2.scuderos.com 32
		seergemarket.com
		moneyisnothings.com
		shiproductforall.com
		shoppoterapy.com
		expworldofall.com
		consumerheavenom.com
		newsforseller.com
		letforbuyogra.com
		wishmixtter.com
		marketmixs.com
		comeandbuyfish.com
		favoritetobuy.com
		closertoyourwishpful.com
		worldofallca.com
		reepurchase.com
		mysbuybuycons.com
		favoritestochoose.com
		pleasurepointcter.com
		consumerpointns.com
		consumerlifeishere.com
		allpurchaseray.com
		tifranklyspend.com
		storefavesti.com
		profishopperub.com
		nodoubttospend.com
		zebrabunchofall.com
		marketeyebest.com
		sandcomeandbuy.com
		forcoinphil.com
		comeverydaysale.com
		everydaysaledsto.com
		conlafiesta.com
63.222.234.253 1
	ns1.tintopinto.com 26
		drawtestychoise.com
		shoparoundus.com
		wholesaleralin.com
		allclosetoyouttik.com
		goandspendoola.com
		bunchofall.com
		muswishmix.com
		placetoshopart.com
		friplacetobuy.com
		yourmoneying.com
		colorshoppings.com
		everydaysalecool.com
		gooddealme.com
		abunchofallla.com
		testychoise.com
		happybuyerersp.com
		consumeredian.com
		comeandbuyer.com
		allforthefamilys.com
		preciousonly.com
		purchaseheretrop.com
		productfall.com
		prodmixedia.com
		pricedropcash.com
		jewgoandspend.com
		buybuyladyby.com
63.222.234.254 1
	ns2.tintopinto.com 26
		drawtestychoise.com
		shoparoundus.com
		wholesaleralin.com
		allclosetoyouttik.com
		goandspendoola.com
		bunchofall.com
		muswishmix.com
		placetoshopart.com
		friplacetobuy.com
		yourmoneying.com
		colorshoppings.com
		everydaysalecool.com
		gooddealme.com
		abunchofallla.com
		testychoise.com
		happybuyerersp.com
		consumeredian.com
		comeandbuyer.com
		allforthefamilys.com
		preciousonly.com
		purchaseheretrop.com
		productfall.com
		prodmixedia.com
		pricedropcash.com
		jewgoandspend.com
		buybuyladyby.com
63.222.235.253 1
	ns1.bedsoni.com 30
		experimentmarketing.com
		realityact.com
		promotionexamine.com
		communicationroute.com
		pressassess.com
		moderatesurvey.com
		mediaion.com
		entertainreality.com
		statisticsadvertise.com
		revitalizefacts.com
		reviewpersonal.com
		presscoordinate.com
		paradoxauthorize.com
		studiescoordinate.com
		marketingsimulate.com
		reviewacoustic.com
		promoappoint.com
		collectconnections.com
		tutorstudies.com
		evaluationlistings.com
		agentsevaluation.com
		advertisingconfer.com
		streamlineparadox.com
		clarifyadvertising.com
		statisticsenlist.com
		publicitybase.com
		surveyadvertise.com
		factsentertain.com
		enhamedia.com
		wavepublicity.com
63.222.235.254 1
	ns2.bedsoni.com 30
		experimentmarketing.com
		realityact.com
		promotionexamine.com
		communicationroute.com
		pressassess.com
		moderatesurvey.com
		mediaion.com
		entertainreality.com
		statisticsadvertise.com
		revitalizefacts.com
		reviewpersonal.com
		presscoordinate.com
		paradoxauthorize.com
		studiescoordinate.com
		marketingsimulate.com
		reviewacoustic.com
		promoappoint.com
		collectconnections.com
		tutorstudies.com
		evaluationlistings.com
		agentsevaluation.com
		advertisingconfer.com
		streamlineparadox.com
		clarifyadvertising.com
		statisticsenlist.com
		publicitybase.com
		surveyadvertise.com
		factsentertain.com
		enhamedia.com
		wavepublicity.com
63.222.236.2 1
	ns1.gluxs.com 28
		risetosell.com
		waysforcashs.com
		artideabiz.com
		thinkaroundbusiness.com
		streamthe.com
		buyworldideas.com
		chooseideablog.com
		mundexrule.com
		newtrendone.com
		trendworldmarkets.com
		futureworldofidea.com
		newwayfinderfun.com
		elmercadodelmundos.com
		onefortrend.com
		verychoises.com
		easyideacreators.com
		compromistrades.com
		onlytrendfind.com
		trandwaysdeal.com
		worldcaptains.com
		worldlinebiz.com
		rutabosques.com
		marketrulebox.com
		trendshoppings.com
		ideasintheairfinder.com
		ideasallarounds.com
		randtosale.com
		liferulesblog.com
63.222.236.3 1
	ns2.gluxs.com 28
		risetosell.com
		waysforcashs.com
		artideabiz.com
		thinkaroundbusiness.com
		streamthe.com
		buyworldideas.com
		chooseideablog.com
		mundexrule.com
		newtrendone.com
		trendworldmarkets.com
		futureworldofidea.com
		newwayfinderfun.com
		elmercadodelmundos.com
		onefortrend.com
		verychoises.com
		easyideacreators.com
		compromistrades.com
		onlytrendfind.com
		trandwaysdeal.com
		worldcaptains.com
		worldlinebiz.com
		rutabosques.com
		marketrulebox.com
		trendshoppings.com
		ideasintheairfinder.com
		ideasallarounds.com
		randtosale.com
		liferulesblog.com
63.222.237.253 1
	ns1.chulans.com 30
		worldoffortunes.com
		thinkgenerators.com
		mundoforcash.com
		directioner.com
		clicktorule.com
		opportunitydata.com
		trendguys.com
		smallworldtobuy.com
		thinkmarketdeal.com
		marketcodecool.com
		marketderections.com
		globalcoclick.com
		mercadobest.com
		marketderection.com
		clicktohave.com
		directioners.com
		randtosalebiz.com
		clearenceofideas.com
		oneideaalotofcash.com
		mundojuntos.com
		worldlinecode.com
		worldonsales.com
		ideasoceans.com
		ideasintheairfinders.com
		formarketcash.com
		globalcobiz.com
		ideaforcasino.com
		newinbusinesscity.com
		marketolla.com
		gorganzolla.com
63.222.237.254 1
	ns2.chulans.com 30
		worldoffortunes.com
		thinkgenerators.com
		mundoforcash.com
		directioner.com
		clicktorule.com
		opportunitydata.com
		trendguys.com
		smallworldtobuy.com
		thinkmarketdeal.com
		marketcodecool.com
		marketderections.com
		globalcoclick.com
		mercadobest.com
		marketderection.com
		clicktohave.com
		directioners.com
		randtosalebiz.com
		clearenceofideas.com
		oneideaalotofcash.com
		mundojuntos.com
		worldlinecode.com
		worldonsales.com
		ideasoceans.com
		ideasintheairfinders.com
		formarketcash.com
		globalcobiz.com
		ideaforcasino.com
		newinbusinesscity.com
		marketolla.com
		gorganzolla.com
66.198.243.2 1
	ns1.oreleasy.com 7
		podesort.com
		aboveready.com
		clickedsmashdirect.com
		talkmeineasy.com
		excnewspost.com
		dealofzryst.com
		bargainpure.com
66.198.243.3 1
	ns2.oreleasy.com 7
		podesort.com
		aboveready.com
		clickedsmashdirect.com
		talkmeineasy.com
		excnewspost.com
		dealofzryst.com
		bargainpure.com
66.198.253.253 1
	ns1.pathrinxit.com 8
		dpgetselect.com
		volumemulti.com
		timelyao.com
		undereffort.com
		cyberblinkstore.com
		trysource.com
		ebamust.com
		waything.com
66.198.253.254 1
	ns2.pathrinxit.com 8
		dpgetselect.com
		volumemulti.com
		timelyao.com
		undereffort.com
		cyberblinkstore.com
		trysource.com
		ebamust.com
		waything.com
67.109.72.5 1
	ns1.sbadns.com 14
		rdpassword1.com
		smartbargdaily.com
		smartbargalerts.com
		rewarddepot5.com
		rdpassword3.com
		rewarddepot2.com
		rewarddepot3.com
		rewarddepot4.com
		rdpassword2.com
		smartbargdirect.com
		smartbargalert.com
		rewarddepot1.com
		smartbargreward.com
		therewarddepotnews.com
67.109.72.6 1
	ns2.sbadns.com 14
		rdpassword1.com
		smartbargdaily.com
		smartbargalerts.com
		rewarddepot5.com
		rdpassword3.com
		rewarddepot2.com
		rewarddepot3.com
		rewarddepot4.com
		rdpassword2.com
		smartbargdirect.com
		smartbargalert.com
		rewarddepot1.com
		smartbargreward.com
		therewarddepotnews.com
67.109.72.7 1
	ns3.sbadns.com 14
		rdpassword1.com
		smartbargdaily.com
		smartbargalerts.com
		rewarddepot5.com
		rdpassword3.com
		rewarddepot2.com
		rewarddepot3.com
		rewarddepot4.com
		rdpassword2.com
		smartbargdirect.com
		smartbargalert.com
		rewarddepot1.com
		smartbargreward.com
		therewarddepotnews.com
67.109.73.2 1
	ns3.rsndns3.com 73
		312tech.net
		publicsmokingsurveys.com
		directshoppersavings.com
		specialoffercentral.com
		restaurantdiscountsdirect.com
		hotelectronicssavings.com
		discountholidayshoppers.com
		yourparentingresources.com
		designersavingsdirect.com
		incredibleholidaysavings.com
		hotshoppingnetwork.com
		restaurantreviewpanel.com
		ezgamegear.com
		travelguidesavings.com
		consumeropinionrewards.com
		shoppersreviewnetwork.com
		econsumerpanel.com
		destinationsurveys.com
		hdtvsaver.com
		usareviewpanel.com
		consumerreviewnetwork.com
		americanreviewpanel.com
		mygiftcardcentral.com
		chefdiscountcookware.com
		usaresearchpanel.com
		wirelesstechsavings.com
		eresearchpanel.com
		thelaptopsaver.com
		holidaysavingsguide.com
		eshoppersavings.com
		nationalmagazinereview.com
		desktopreviewpanel.com
		cooklikepros.com
		todayshealthyliving.com
		sportsworldsavings.com
		skincaresavingsdirect.com
		tvopinionpolls.com
		parentingneedsdirect.com
		opinionresearchpanel.com
		americansportspolls.com
		gamer-hookups.com
		hotcameratechnology.com
		handbagreviewpanel.com
		hdreviewpanel.com
		yourgiftcardsdirect.com
		egamerworld.com
		shopperdealsdirect.com
		rsndns1.com
		discountshoppercentral.com
		laptopreviewpanel.com
		hdtvdirectsavings.com
		surveyreviewpanel.com
		evacationsonline.com
		esurveypanel.com
		magazinereviewpanel.com
		homeremodelnetwork.com
		todayshottestgadgets.com
		rsndns2.com
		elaptopsaver.com
		yourlaptopsavings.com
		aqclick.com
		gadgetreviewpanel.com
		newelectronicssavings.com
		sportinggoodssavings.com
		retailreviewpanel.com
		thinnest-laptop.com
		greenlivingrewards.com
		camerareviewpanel.com
		topdesignersavings.com
		eshoppingpanel.com
		usaopinionpanel.com
		hdtv-savings.com
		americanopinionpanel.com
67.109.73.110 1
	ns1.bloworn.com 28
		themessagestep.com
		todaysannouncements.com
		sourcebroadcast.com
		reportprobe.com
		reportknownow.com
		topupdatenow.com
		newslettercircle.com
		daytodayannouncements.com
		ideabulletin.com
		messagemycircle.com
		mywaynewsletter.com
		occasiononebyone.com
		linkstonewsletter.com
		discoverthereport.com
		messagebestoffer.com
		metalbroadcast.com
		thedayannouncements.com
		eachdayannouncements.com
		redcommon.com
		infoconstantly.com
		gatetoreports.com
		newsletterglobal.com
		driveamessage.com
		newsbulletindigital.com
		bulletinred.com
		broadcasttheoverview.com
		broadcastnewssky.com
		bulletinbest.com
67.109.73.111 1
	ns2.bloworn.com 28
		themessagestep.com
		todaysannouncements.com
		sourcebroadcast.com
		reportprobe.com
		reportknownow.com
		topupdatenow.com
		newslettercircle.com
		daytodayannouncements.com
		ideabulletin.com
		messagemycircle.com
		mywaynewsletter.com
		occasiononebyone.com
		linkstonewsletter.com
		discoverthereport.com
		messagebestoffer.com
		metalbroadcast.com
		thedayannouncements.com
		eachdayannouncements.com
		redcommon.com
		infoconstantly.com
		gatetoreports.com
		newsletterglobal.com
		driveamessage.com
		newsbulletindigital.com
		bulletinred.com
		broadcasttheoverview.com
		broadcastnewssky.com
		bulletinbest.com
67.209.114.2 1
	ns1.relloyer.com 131
		prestach.com
		isconfly.com
		ischall.com
		ataxide.com
		tosspec.com
		bequeno.com
		etonde.com
		ederyle.com
		kathlik.com
		lingdocu.com
		otolipper.com
		loincer.com
		clinozo.com
		clavitro.com
		cathyme.com
		sherpore.com
		almertetr.com
		nomineph.com
		incenumbi.com
		ectras.com
		aelophy.com
		ootyrdac.com
		akroferr.com
		nerylate.com
		dividol.com
		yeldsh.com
		ghyllum.com
		fartlas.com
		beaterry.com
		cassonazi.com
		schmoni.com
		problicum.com
		aerotric.com
		whiterocksbar.com
		rockapparelboutique.com
		regalatlas.com
		partyfavoremp.com
		summitartgallery.com
		neetstreethome.com
		cherrywoodanchors.com
		baysidebrewhouse.com
		julesta.com
		flapbog.com
		ingclick.com
		abbotgo.com
		gombalia.com
		coclown.com
		arlretail.com
		leitmotiftime.com
		ersack.com
		cringov.com
		clautal.com
		bartgo.com
		strodani.com
		penkino.com
		askstro.com
		campalert.com
		ettson.com
		dronir.com
		cribson.com
		cloncri.com
		nanahomedecor.com
		gagaforgreens.com
		coturegraphics.com
		greenhousetreats.com
		thefishermanpub.com
		shakbor.com
		gonebi.com
		sonicli.com
		demoltal.com
		delgluk.com
		blummbog.com
		arqubor.com
		agsprice.com
		clickopla.com
		clowntopia.com
		bakersknott.com
		yourvillageemporium.com
		woofwoofclub.com
		treasurevalleyshop.com
		thechocolatefact.com
		sprintershoppe.com
		remembermegift.com
		pattiesbythesea.com
		enviouscreatives.com
		dominicillustrations.com
		unlmtpetsuppliers.com
		acadiagymnasium.com
		bestsoupinthecity.com
		mustsuk.com
		anoker.com
		mouoker.com
		glukiose.com
		bigstro.com
		angrid.com
		kinbog.com
		estachoy.com
		risiblejoy.com
		webtuhola.com
		tortuousroad.com
		bassack.com
		seawaysouveniers.com
		kabloombuds.com
		metrowirelessserv.com
		micksbestburgers.com
		jamiesgiantjems.com
		gotpixelsinc.com
		yourpapergeeks.com
		primocraftstore.com
		panaceaway.com
		premierpioneersystems.com
		tugrid.com
		strour.com
		clipkino.com
		kinolate.com
		preygone.com
		hillcrestretailers.com
		hamblerholdings.com
		artisiantreasurs.com
		overthelandflowers.com
		scrappsdeli.com
		thebarkharbor.com
		writeras.com
		strangefey.com
		lilthingluv.com
		odiousyou.com
		atelierstud.com
		revvenerate.com
		jambohello.com
		expalbatross.com
		enjoinu.com
67.209.114.3 1
	ns2.relloyer.com 131
		prestach.com
		isconfly.com
		ischall.com
		ataxide.com
		tosspec.com
		bequeno.com
		etonde.com
		ederyle.com
		kathlik.com
		lingdocu.com
		otolipper.com
		loincer.com
		clinozo.com
		clavitro.com
		cathyme.com
		sherpore.com
		almertetr.com
		nomineph.com
		incenumbi.com
		ectras.com
		aelophy.com
		ootyrdac.com
		akroferr.com
		nerylate.com
		dividol.com
		yeldsh.com
		ghyllum.com
		fartlas.com
		beaterry.com
		cassonazi.com
		schmoni.com
		problicum.com
		aerotric.com
		whiterocksbar.com
		rockapparelboutique.com
		regalatlas.com
		partyfavoremp.com
		summitartgallery.com
		neetstreethome.com
		cherrywoodanchors.com
		baysidebrewhouse.com
		julesta.com
		flapbog.com
		ingclick.com
		abbotgo.com
		gombalia.com
		coclown.com
		arlretail.com
		leitmotiftime.com
		ersack.com
		cringov.com
		clautal.com
		bartgo.com
		strodani.com
		penkino.com
		askstro.com
		campalert.com
		ettson.com
		dronir.com
		cribson.com
		cloncri.com
		nanahomedecor.com
		gagaforgreens.com
		coturegraphics.com
		greenhousetreats.com
		thefishermanpub.com
		shakbor.com
		gonebi.com
		sonicli.com
		demoltal.com
		delgluk.com
		blummbog.com
		arqubor.com
		agsprice.com
		clickopla.com
		clowntopia.com
		bakersknott.com
		yourvillageemporium.com
		woofwoofclub.com
		treasurevalleyshop.com
		thechocolatefact.com
		sprintershoppe.com
		remembermegift.com
		pattiesbythesea.com
		enviouscreatives.com
		dominicillustrations.com
		unlmtpetsuppliers.com
		acadiagymnasium.com
		bestsoupinthecity.com
		mustsuk.com
		anoker.com
		mouoker.com
		glukiose.com
		bigstro.com
		angrid.com
		kinbog.com
		estachoy.com
		risiblejoy.com
		webtuhola.com
		tortuousroad.com
		bassack.com
		seawaysouveniers.com
		kabloombuds.com
		metrowirelessserv.com
		micksbestburgers.com
		jamiesgiantjems.com
		gotpixelsinc.com
		yourpapergeeks.com
		primocraftstore.com
		panaceaway.com
		premierpioneersystems.com
		tugrid.com
		strour.com
		clipkino.com
		kinolate.com
		preygone.com
		hillcrestretailers.com
		hamblerholdings.com
		artisiantreasurs.com
		overthelandflowers.com
		scrappsdeli.com
		thebarkharbor.com
		writeras.com
		strangefey.com
		lilthingluv.com
		odiousyou.com
		atelierstud.com
		revvenerate.com
		jambohello.com
		expalbatross.com
		enjoinu.com
68.66.194.130 1
	ns1.infoorep.com 32
		broadcastch.com
		takeglobe.com
		radiuscoordinate.com
		getholdoftheday.com
		alistadministration.com
		bluenightly.com
		topadministration.com
		seizestheday.com
		newthinkonline.com
		storyred.com
		newsdefine.com
		televisionub.com
		meditatenet.com
		radioflashy.com
		roundmanagement.com
		reportdo.com
		radiuslogistic.com
		comprehendnet.com
		surmiseweb.com
		alistdirection.com
		seizeworld.com
		seizeuniverse.com
		regionlogistics.com
		contemplatenet.com
		atopmanagement.com
		scopeplanning.com
		betteremboss.com
		justinhot.com
		telecastbiz.com
		urgentdrive.com
		supernewdo.com
		airingnet.com
68.66.194.131 1
	ns2.infoorep.com 32
		broadcastch.com
		takeglobe.com
		radiuscoordinate.com
		getholdoftheday.com
		alistadministration.com
		bluenightly.com
		topadministration.com
		seizestheday.com
		newthinkonline.com
		storyred.com
		newsdefine.com
		televisionub.com
		meditatenet.com
		radioflashy.com
		roundmanagement.com
		reportdo.com
		radiuslogistic.com
		comprehendnet.com
		surmiseweb.com
		alistdirection.com
		seizeworld.com
		seizeuniverse.com
		regionlogistics.com
		contemplatenet.com
		atopmanagement.com
		scopeplanning.com
		betteremboss.com
		justinhot.com
		telecastbiz.com
		urgentdrive.com
		supernewdo.com
		airingnet.com
68.66.195.128 1
	ns1.bursant.com 32
		thetruconnections.com
		rockandrollfuncable.com
		increasingexamples.com
		throwreport.com
		urgentlook.com
		validties.com
		entrancemanagement.com
		rockitentertainmentmedia.com
		cesinews.com
		mytruconnections.com
		validbonds.com
		justininfo.com
		expandingideals.com
		aptradio.com
		gatewaydirection.com
		entryadministration.com
		televisioncool.com
		supernewplay.com
		rockitdiversioncable.com
		storyenrapt.com
		telecastcity.com
		entrancebosses.com
		truthbonds.com
		broadcastie.com
		expandingexamples.com
		growingexamples.com
		nightlycity.com
		rockitentertainme.com
		rocknrollfunbroadcast.com
		entrywaymgmt.com
		growingmodel.com
		airingone.com
68.66.195.129 1
	ns2.bursant.com 32
		thetruconnections.com
		rockandrollfuncable.com
		increasingexamples.com
		throwreport.com
		urgentlook.com
		validties.com
		entrancemanagement.com
		rockitentertainmentmedia.com
		cesinews.com
		mytruconnections.com
		validbonds.com
		justininfo.com
		expandingideals.com
		aptradio.com
		gatewaydirection.com
		entryadministration.com
		televisioncool.com
		supernewplay.com
		rockitdiversioncable.com
		storyenrapt.com
		telecastcity.com
		entrancebosses.com
		truthbonds.com
		broadcastie.com
		expandingexamples.com
		growingexamples.com
		nightlycity.com
		rockitentertainme.com
		rocknrollfunbroadcast.com
		entrywaymgmt.com
		growingmodel.com
		airingone.com
68.66.196.125 1
	ns1.strawhe.com 32
		lotpaper.com
		behotwire.com
		townengineering.com
		liquidsynergistic.com
		goldenshoreadventure.com
		bridgeworkbuilding.com
		bigvillagetech.com
		goldshoreenterprise.com
		copronounce.com
		chatterhot.com
		funtelecast.com
		releasebig.com
		featannounce.com
		metrotechcity.com
		overpassconstruct.com
		finemetalenterprise.com
		citytechcentral.com
		bridgeworkdevelopment.com
		articlered.com
		thbrief.com
		fluidinteractional.com
		finemetalbusiness.com
		citytechvillage.com
		goldcoastadventure.com
		frameworkconstruct.com
		watercollaborate.com
		fluidcommunicate.com
		tjiroppo.com
		liquidinteract.com
		pointmessage.com
		writeupintra.com
		bridgejobconstruct.com
68.66.196.126 1
	ns2.strawhe.com 32
		lotpaper.com
		behotwire.com
		townengineering.com
		liquidsynergistic.com
		goldenshoreadventure.com
		bridgeworkbuilding.com
		bigvillagetech.com
		goldshoreenterprise.com
		copronounce.com
		chatterhot.com
		funtelecast.com
		releasebig.com
		featannounce.com
		metrotechcity.com
		overpassconstruct.com
		finemetalenterprise.com
		citytechcentral.com
		bridgeworkdevelopment.com
		articlered.com
		thbrief.com
		fluidinteractional.com
		finemetalbusiness.com
		citytechvillage.com
		goldcoastadventure.com
		frameworkconstruct.com
		watercollaborate.com
		fluidcommunicate.com
		tjiroppo.com
		liquidinteract.com
		pointmessage.com
		writeupintra.com
		bridgejobconstruct.com
68.66.197.159 1
	ns1.viticem.com 32
		twintertainment.com
		diversifiedmethod.com
		enthusiasticpartner.com
		zodiacentertain.com
		hotwirecity.com
		vservicesgroup.com
		voltservgroup.com
		pronouncecool.com
		scoopdebate.com
		writeupall.com
		joltserveclub.com
		tjirweb.com
		opinionfly.com
		vhelpclub.com
		diversifiedanswer.com
		reportbest.com
		differingsolutions.com
		avidcoowner.com
		alertaffiliates.com
		voltageaidbunch.com
		varysolutions.com
		enthusiasticassociate.com
		releasefast.com
		geminifun.com
		alertpartners.com
		opinionlisten.com
		paperfiery.com
		pointbrief.com
		variedfix.com
		geminientertain.com
		zodiacsignent.com
		chattergreen.com
68.66.197.160 1
	ns2.viticem.com 32
		twintertainment.com
		diversifiedmethod.com
		enthusiasticpartner.com
		zodiacentertain.com
		hotwirecity.com
		vservicesgroup.com
		voltservgroup.com
		pronouncecool.com
		scoopdebate.com
		writeupall.com
		joltserveclub.com
		tjirweb.com
		opinionfly.com
		vhelpclub.com
		diversifiedanswer.com
		reportbest.com
		differingsolutions.com
		avidcoowner.com
		alertaffiliates.com
		voltageaidbunch.com
		varysolutions.com
		enthusiasticassociate.com
		releasefast.com
		geminifun.com
		alertpartners.com
		opinionlisten.com
		paperfiery.com
		pointbrief.com
		variedfix.com
		geminientertain.com
		zodiacsignent.com
		chattergreen.com
68.66.198.98 1
	ns1.resurde.com 32
		formalmessage.com
		sunnyaffiliate.com
		euphoriapr.com
		cobaltcomp.com
		cobaltbluecompany.com
		cobaltbiz.com
		blisspublictime.com
		blisspublicrelation.com
		awolstory.com
		flybroadcast.com
		nightlylive.com
		hardyradio.com
		getsupernew.com
		elementassociation.com
		announceth.com
		daylightpartner.com
		televisiontop.com
		briefget.com
		reporthot.com
		sunlightmate.com
		onlineairing.com
		observescoop.com
		tjironline.com
		pointopinion.com
		imtelecast.com
		daylightcoowner.com
		happypublicrelations.com
		blucolorbusiness.com
		cityjustin.com
		catchurgent.com
		sunlightpartner.com
		happinesspr.com
68.66.198.99 1
	ns2.resurde.com 32
		formalmessage.com
		sunnyaffiliate.com
		euphoriapr.com
		cobaltcomp.com
		cobaltbluecompany.com
		cobaltbiz.com
		blisspublictime.com
		blisspublicrelation.com
		awolstory.com
		flybroadcast.com
		nightlylive.com
		hardyradio.com
		getsupernew.com
		elementassociation.com
		announceth.com
		daylightpartner.com
		televisiontop.com
		briefget.com
		reporthot.com
		sunlightmate.com
		onlineairing.com
		observescoop.com
		tjironline.com
		pointopinion.com
		imtelecast.com
		daylightcoowner.com
		happypublicrelations.com
		blucolorbusiness.com
		cityjustin.com
		catchurgent.com
		sunlightpartner.com
		happinesspr.com
68.66.199.2 1
	ns1.carlour.com 32
		paperextra.com
		biopinion.com
		stargazeglobal.com
		queenmiles.com
		brightoncubicle.com
		rightswriteup.com
		lightinoffices.com
		discussscoop.com
		kingstretch.com
		mindarticle.com
		findchatter.com
		milkywayuniverse.com
		announceprest.com
		tjirblog.com
		lightworkplace.com
		intelligentcubicle.com
		releaseza.com
		wihotwire.com
		pronounceer.com
		wantedpaper.com
		royalblock.com
		monarchblocks.com
		galaxygateglobal.com
		brightofficespace.com
		royaltymile.com
		stargazeworld.com
		mailchatter.com
		pronounceblue.com
		talkrelease.com
		gutsywriteup.com
		solargateworld.com
		messagest.com
68.66.199.3 1
	ns2.carlour.com 32
		paperextra.com
		biopinion.com
		stargazeglobal.com
		queenmiles.com
		brightoncubicle.com
		rightswriteup.com
		lightinoffices.com
		discussscoop.com
		kingstretch.com
		mindarticle.com
		findchatter.com
		milkywayuniverse.com
		announceprest.com
		tjirblog.com
		lightworkplace.com
		intelligentcubicle.com
		releaseza.com
		wihotwire.com
		pronounceer.com
		wantedpaper.com
		royalblock.com
		monarchblocks.com
		galaxygateglobal.com
		brightofficespace.com
		royaltymile.com
		stargazeworld.com
		mailchatter.com
		pronounceblue.com
		talkrelease.com
		gutsywriteup.com
		solargateworld.com
		messagest.com
68.66.200.127 1
	ns1.ormerry.com 32
		infoairing.com
		whitepebblespouse.com
		purerockaffiliate.com
		theempowermentent.com
		onebeaconclass.com
		writerstonepartners.com
		elsupernew.com
		readurgent.com
		whitestonespouse.com
		tonicannounce.com
		snarticle.com
		boontelevision.com
		newsinvolve.com
		mybeacongroup.com
		explainnews.com
		broadcasthot.com
		oneguidecrowd.com
		empowermentsenterprise.com
		carpradio.com
		singleguidegroup.com
		directiontask.com
		approvalenterprises.com
		listenscoop.com
		infonightly.com
		messagemaniac.com
		hotwirenew.com
		justinred.com
		briefog.com
		articleep.com
		mypowermenttask.com
		singledirectgroup.com
		inrushstory.com
68.66.200.128 1
	ns2.ormerry.com 32
		infoairing.com
		whitepebblespouse.com
		purerockaffiliate.com
		theempowermentent.com
		onebeaconclass.com
		writerstonepartners.com
		elsupernew.com
		readurgent.com
		whitestonespouse.com
		tonicannounce.com
		snarticle.com
		boontelevision.com
		newsinvolve.com
		mybeacongroup.com
		explainnews.com
		broadcasthot.com
		oneguidecrowd.com
		empowermentsenterprise.com
		carpradio.com
		singleguidegroup.com
		directiontask.com
		approvalenterprises.com
		listenscoop.com
		infonightly.com
		messagemaniac.com
		hotwirenew.com
		justinred.com
		briefog.com
		articleep.com
		mypowermenttask.com
		singledirectgroup.com
		inrushstory.com
68.66.201.130 1
	ns1.findhaven.com 32
		orderholiday.com
		getawaysdiscount.com
		comtechanswer.com
		basementadvertising.com
		comtekfixes.com
		bluemiddlecorp.com
		worthvacation.com
		visionocean.com
		goodratetrips.com
		worthcruise.com
		ventrip.com
		tropicalbook.com
		toursvalue.com
		mygroundmarketing.com
		comtechsolution.com
		priceweekend.com
		inmountains.com
		bluemediuminc.com
		firstfloorpromotion.com
		mycomteksolutions.com
		catalogtravel.com
		downstairsmarketing.com
		colormiddlebiz.com
		technicalfixes.com
		destinationhot.com
		dealgetaways.com
		advantagesea.com
		beachred.com
		underthestairsadvertising.com
		colormediumco.com
		skymidinc.com
		aninexpensive.com
68.66.201.131 1
	ns2.findhaven.com 32
		orderholiday.com
		getawaysdiscount.com
		comtechanswer.com
		basementadvertising.com
		comtekfixes.com
		bluemiddlecorp.com
		worthvacation.com
		visionocean.com
		goodratetrips.com
		worthcruise.com
		ventrip.com
		tropicalbook.com
		toursvalue.com
		mygroundmarketing.com
		comtechsolution.com
		priceweekend.com
		inmountains.com
		bluemediuminc.com
		firstfloorpromotion.com
		mycomteksolutions.com
		catalogtravel.com
		downstairsmarketing.com
		colormiddlebiz.com
		technicalfixes.com
		destinationhot.com
		dealgetaways.com
		advantagesea.com
		beachred.com
		underthestairsadvertising.com
		colormediumco.com
		skymidinc.com
		aninexpensive.com
68.66.202.129 1
	ns1.adeptee.com 32
		usawhitepicketfence.com
		curioustown.com
		objectivebook.com
		amountcruise.com
		worthfares.com
		newculturesurprise.com
		usagoalcompany.com
		myvaldest.com
		ivyinstructing.com
		hollyadvising.com
		toursgreen.com
		societyawerooms.com
		myshockworkshop.com
		inquiringvillage.com
		inquisitivecity.com
		getisland.com
		assetgoal.com
		societyshockstudio.com
		questioningcity.com
		americandreamincs.com
		americansleepinc.com
		excursionsbiz.com
		coendplace.com
		destinationbuy.com
		whitepicketfenceinc.com
		ivyleagueadviser.com
		valuesauto.com
		havencool.com
		curiousmetro.com
		cultureshockroom.com
		myvineadvice.com
		ivyleagueconsultants.com
68.66.202.130 1
	ns2.adeptee.com 32
		usawhitepicketfence.com
		curioustown.com
		objectivebook.com
		amountcruise.com
		worthfares.com
		newculturesurprise.com
		usagoalcompany.com
		myvaldest.com
		ivyinstructing.com
		hollyadvising.com
		toursgreen.com
		societyawerooms.com
		myshockworkshop.com
		inquiringvillage.com
		inquisitivecity.com
		getisland.com
		assetgoal.com
		societyshockstudio.com
		questioningcity.com
		americandreamincs.com
		americansleepinc.com
		excursionsbiz.com
		coendplace.com
		destinationbuy.com
		whitepicketfenceinc.com
		ivyleagueadviser.com
		valuesauto.com
		havencool.com
		curiousmetro.com
		cultureshockroom.com
		myvineadvice.com
		ivyleagueconsultants.com
68.66.203.130 1
	ns1.trumpan.com 32
		discountsresort.com
		redgetaway.com
		trustgoal.com
		myredlineservices.com
		getawaybest.com
		havennetwork.com
		scarletedgebusiness.com
		travelgoodrate.com
		toursbusiness.com
		crimsonedgebiz.com
		flightamount.com
		marketbeach.com
		excursionsdigital.com
		improvesea.com
		jetblackgrowth.com
		creativebusinessanswers.com
		blackrockarea.com
		codeholiday.com
		usefulbusinessfixes.com
		redpenbusiness.com
		redlinesservice.com
		dealresorts.com
		productivebizsolution.com
		obsidiansdevelopment.com
		endplaceinfo.com
		productivebizanswers.com
		obsidiangrowth.com
		coolvaldest.com
		beinexpensive.com
		creativecompanyanswers.com
		volcanicrockdevelopment.com
		promotionsvacation.com
68.66.203.131 1
	ns2.trumpan.com 32
		discountsresort.com
		redgetaway.com
		trustgoal.com
		myredlineservices.com
		getawaybest.com
		havennetwork.com
		scarletedgebusiness.com
		travelgoodrate.com
		toursbusiness.com
		crimsonedgebiz.com
		flightamount.com
		marketbeach.com
		excursionsdigital.com
		improvesea.com
		jetblackgrowth.com
		creativebusinessanswers.com
		blackrockarea.com
		codeholiday.com
		usefulbusinessfixes.com
		redpenbusiness.com
		redlinesservice.com
		dealresorts.com
		productivebizsolution.com
		obsidiansdevelopment.com
		endplaceinfo.com
		productivebizanswers.com
		obsidiangrowth.com
		coolvaldest.com
		beinexpensive.com
		creativecompanyanswers.com
		volcanicrockdevelopment.com
		promotionsvacation.com
68.66.204.125 1
	ns1.bonect.com 32
		sealena.com
		advantexassociation.com
		neonbrightmarketing.com
		grannysmithworld.com
		suitesea.com
		dealweekend.com
		goodrateresorts.com
		dealsgoodrate.com
		redappletreeworld.com
		brightpinkads.com
		brightgreenpromotion.com
		oceanget.com
		projectstravel.com
		valuecool.com
		inexpensivesky.com
		advatexfriend.com
		appletreeinternational.com
		listtrip.com
		tropicalfly.com
		orchardworldwide.com
		storedestination.com
		greenappleglobal.com
		holidaycool.com
		discountsisland.com
		mountainsbest.com
		daygloadvertising.com
		vantaxcolleague.com
		neoncolorsadvertising.com
		fairvacation.com
		athbeach.com
		advatexassociates.com
		advantagefriend.com
68.66.204.126 1
	ns2.bonect.com 32
		sealena.com
		advantexassociation.com
		neonbrightmarketing.com
		grannysmithworld.com
		suitesea.com
		dealweekend.com
		goodrateresorts.com
		dealsgoodrate.com
		redappletreeworld.com
		brightpinkads.com
		brightgreenpromotion.com
		oceanget.com
		projectstravel.com
		valuecool.com
		inexpensivesky.com
		advatexfriend.com
		appletreeinternational.com
		listtrip.com
		tropicalfly.com
		orchardworldwide.com
		storedestination.com
		greenappleglobal.com
		holidaycool.com
		discountsisland.com
		mountainsbest.com
		daygloadvertising.com
		vantaxcolleague.com
		neoncolorsadvertising.com
		fairvacation.com
		athbeach.com
		advatexassociates.com
		advantagefriend.com
68.66.205.159 1
	ns1.broseal.com 32
		marshdevelopments.com
		contemplaterelations.com
		trademarktru.com
		reddestination.com
		swamptechnologies.com
		contractstravel.com
		thamount.com
		soamount.com
		daydreamrelations.com
		contemplateconnection.com
		blackbookspromotions.com
		objectivesource.com
		reverieconnection.com
		goalefly.com
		linktropical.com
		valdestbiz.com
		oceanow.com
		darkbookmarketing.com
		mountainsfly.com
		panhandleswamptech.com
		floridaswamptech.com
		coolexcursions.com
		panhandlestechnologies.com
		nightnovelpromotions.com
		labeltrust.com
		labelconfidence.com
		logovalid.com
		savingsisland.com
		reverierelationship.com
		darknoveladvertising.com
		companytruth.com
		blackbooksmarketing.com
68.66.205.160 1
	ns2.broseal.com 32
		marshdevelopments.com
		contemplaterelations.com
		trademarktru.com
		reddestination.com
		swamptechnologies.com
		contractstravel.com
		thamount.com
		soamount.com
		daydreamrelations.com
		contemplateconnection.com
		blackbookspromotions.com
		objectivesource.com
		reverieconnection.com
		goalefly.com
		linktropical.com
		valdestbiz.com
		oceanow.com
		darkbookmarketing.com
		mountainsfly.com
		panhandleswamptech.com
		floridaswamptech.com
		coolexcursions.com
		panhandlestechnologies.com
		nightnovelpromotions.com
		labeltrust.com
		labelconfidence.com
		logovalid.com
		savingsisland.com
		reverierelationship.com
		darknoveladvertising.com
		companytruth.com
		blackbooksmarketing.com
68.66.206.130 1
	ns1.overpu.com 32
		lakeviewadvertising.com
		mountainscity.com
		expressiontableworkshop.com
		abilitycommunicate.com
		travellt.com
		fronttableoffice.com
		frontdeskstudios.com
		pricesvacation.com
		waterviewpromotions.com
		tripacct.com
		knightgroups.com
		worthbeach.com
		noblesgathering.com
		havenhot.com
		ableconversation.com
		abilityconnection.com
		pondvistamarketing.com
		facedeskstudio.com
		visionobjective.com
		discountskey.com
		ideatropical.com
		tripsvalue.com
		lakeseeadvertising.com
		endplacent.com
		resortscool.com
		facedesksstudios.com
		capabilityconnections.com
		waterseepromotions.com
		powercommunicate.com
		knightgrouponline.com
		mynoblecrew.com
		horsescrowds.com
68.66.206.131 1
	ns2.overpu.com 32
		lakeviewadvertising.com
		mountainscity.com
		expressiontableworkshop.com
		abilitycommunicate.com
		travellt.com
		fronttableoffice.com
		frontdeskstudios.com
		pricesvacation.com
		waterviewpromotions.com
		tripacct.com
		knightgroups.com
		worthbeach.com
		noblesgathering.com
		havenhot.com
		ableconversation.com
		abilityconnection.com
		pondvistamarketing.com
		facedeskstudio.com
		visionobjective.com
		discountskey.com
		ideatropical.com
		tripsvalue.com
		lakeseeadvertising.com
		endplacent.com
		resortscool.com
		facedesksstudios.com
		capabilityconnections.com
		waterseepromotions.com
		powercommunicate.com
		knightgrouponline.com
		mynoblecrew.com
		horsescrowds.com
68.66.207.253 1
	ns1.keweft.com 32
		bluestoneanswers.com
		insiderisland.com
		solutionstrip.com
		driftingtheglobe.com
		dakotamethodcommunication.com
		pricestours.com
		orendplace.com
		quickaheadpartners.com
		northsystemmedium.com
		expertsea.com
		smartexcursions.com
		inexpensivecity.com
		findvaldest.com
		wanderinginternational.com
		bluegemsolution.com
		goalseed.com
		holidaydigital.com
		infomountains.com
		wanderingglobal.com
		southmethodmedia.com
		inaocean.com
		fastfowardpartner.com
		preciousstonesolutions.com
		nomadicinternational.com
		speedyfrontcoowners.com
		sapphirefixes.com
		northplancommunication.com
		nomadiccountry.com
		quickaheadaffiliate.com
		fastfowardaffiliate.com
		dakotasystemsmedia.com
		bluegemfixes.com
68.66.207.254 1
	ns2.keweft.com 32
		bluestoneanswers.com
		insiderisland.com
		solutionstrip.com
		driftingtheglobe.com
		dakotamethodcommunication.com
		pricestours.com
		orendplace.com
		quickaheadpartners.com
		northsystemmedium.com
		expertsea.com
		smartexcursions.com
		inexpensivecity.com
		findvaldest.com
		wanderinginternational.com
		bluegemsolution.com
		goalseed.com
		holidaydigital.com
		infomountains.com
		wanderingglobal.com
		southmethodmedia.com
		inaocean.com
		fastfowardpartner.com
		preciousstonesolutions.com
		nomadicinternational.com
		speedyfrontcoowners.com
		sapphirefixes.com
		northplancommunication.com
		nomadiccountry.com
		quickaheadaffiliate.com
		fastfowardaffiliate.com
		dakotasystemsmedia.com
		bluegemfixes.com
68.66.208.127 1
	ns1.subunsa.com 32
		totesavings.com
		savecuff.com
		discountot.com
		coexemption.com
		deductiontravel.com
		sodisdel.com
		rollbackfind.com
		markdownworld.com
		cutcostpromo.com
		reduceblue.com
		onlinelowrate.com
		reductionlook.com
		thelettergroup.com
		traditionnovelweb.com
		typenovelsweb.com
		thelettercrowd.com
		thepostclass.com
		ritualpaperbacksnet.com
		webeasytalk.com
		themailgroups.com
		effortlesstalk.com
		myedatereview.com
		myeffortlessspeech.com
		myeasyspeak.com
		mymailcrew.com
		emeetingevaluation.com
		custombooksnet.com
		custombookonline.com
		edayreview.com
		edatecritique.com
		dateevaluation.com
		basiconversation.com
68.66.208.128 1
	ns2.subunsa.com 32
		totesavings.com
		savecuff.com
		discountot.com
		coexemption.com
		deductiontravel.com
		sodisdel.com
		rollbackfind.com
		markdownworld.com
		cutcostpromo.com
		reduceblue.com
		onlinelowrate.com
		reductionlook.com
		thelettergroup.com
		traditionnovelweb.com
		typenovelsweb.com
		thelettercrowd.com
		thepostclass.com
		ritualpaperbacksnet.com
		webeasytalk.com
		themailgroups.com
		effortlesstalk.com
		myedatereview.com
		myeffortlessspeech.com
		myeasyspeak.com
		mymailcrew.com
		emeetingevaluation.com
		custombooksnet.com
		custombookonline.com
		edayreview.com
		edatecritique.com
		dateevaluation.com
		basiconversation.com
68.66.209.162 1
	ns1.exopator.com 32
		providepro.com
		carriedfox.com
		rebatelife.com
		broughtclove.com
		transportif.com
		adtransferred.com
		redgive.com
		pedistribute.com
		deliveredblue.com
		barcede.com
		handoverbuy.com
		dealgraze.com
		primaryclickfriend.com
		primarychoosebuddy.com
		showsmedium.com
		mygadgetgear.com
		edirectmediaonline.com
		earliestselectcomrade.com
		livingreligionpaperback.com
		myhonestcommunication.com
		myfirstclickfriend.com
		mygizmoaccessories.com
		firsttapbuddy.com
		livefaithbooks.com
		livingbeliefbooks.com
		coolgadgetsupplies.com
		devicegearonline.com
		aimmedium.com
		devicesupplies.com
		alivebeliefnovels.com
		alivefaithnovels.com
		uninterruptedmedia.com
68.66.209.163 1
	ns2.exopator.com 32
		providepro.com
		carriedfox.com
		rebatelife.com
		broughtclove.com
		transportif.com
		adtransferred.com
		redgive.com
		pedistribute.com
		deliveredblue.com
		barcede.com
		handoverbuy.com
		dealgraze.com
		primaryclickfriend.com
		primarychoosebuddy.com
		showsmedium.com
		mygadgetgear.com
		edirectmediaonline.com
		earliestselectcomrade.com
		livingreligionpaperback.com
		myhonestcommunication.com
		myfirstclickfriend.com
		mygizmoaccessories.com
		firsttapbuddy.com
		livefaithbooks.com
		livingbeliefbooks.com
		coolgadgetsupplies.com
		devicegearonline.com
		aimmedium.com
		devicesupplies.com
		alivebeliefnovels.com
		alivefaithnovels.com
		uninterruptedmedia.com
68.66.210.125 1
	ns1.distion.com 32
		transferredbuy.com
		savingsinlet.com
		savefixate.com
		giverdeed.com
		decreasecity.com
		wowreduction.com
		hadishout.com
		discountget.com
		lowrateeasy.com
		delivereddeal.com
		impartdeduction.com
		rebatecarried.com
		wealthysclothing.com
		welloffoutfits.com
		richswear.com
		mywealthywear.com
		richsclothing.com
		grayrockonline.com
		momsconsider.com
		rainypebble.com
		mygraystone.com
		mothergaze.com
		mediashapers.com
		mediummolders.com
		broadcastchanger.com
		motherssight.com
		momssee.com
		mediamolders.com
		mediumshapers.com
		mumview.com
		gloomymarble.com
		gloomystone.com
68.66.210.126 1
	ns2.distion.com 32
		transferredbuy.com
		savingsinlet.com
		savefixate.com
		giverdeed.com
		decreasecity.com
		wowreduction.com
		hadishout.com
		discountget.com
		lowrateeasy.com
		delivereddeal.com
		impartdeduction.com
		rebatecarried.com
		wealthysclothing.com
		welloffoutfits.com
		richswear.com
		mywealthywear.com
		richsclothing.com
		grayrockonline.com
		momsconsider.com
		rainypebble.com
		mygraystone.com
		mothergaze.com
		mediashapers.com
		mediummolders.com
		broadcastchanger.com
		motherssight.com
		momssee.com
		mediamolders.com
		mediumshapers.com
		mumview.com
		gloomymarble.com
		gloomystone.com
68.66.211.192 1
	ns1.icplexit.com 32
		exemptioner.com
		disdeleasy.com
		optransferred.com
		marketdelivered.com
		distributend.com
		slipdeduction.com
		reduceget.com
		bookmarkdown.com
		decreasedeal.com
		carriedto.com
		cutcostshop.com
		rollbackmarket.com
		theworldpc.com
		thehotspotscout.com
		wholeearthpc.com
		theworldlaptop.com
		thehotspotdirect.com
		radiospaceonline.com
		theradiospace.com
		shortwavearea.com
		thelitonline.com
		litonlinecentral.com
		literatureontheweb.com
		myilluminatenet.com
		myglobalcomputer.com
		fmgalaxy.com
		funhangoutdirectory.com
		heatplacesdirect.com
		globelaptop.com
		illuminateweb.com
		coolplacesguide.com
		amgalaxy.com
68.66.211.193 1
	ns2.icplexit.com 32
		exemptioner.com
		disdeleasy.com
		optransferred.com
		marketdelivered.com
		distributend.com
		slipdeduction.com
		reduceget.com
		bookmarkdown.com
		decreasedeal.com
		carriedto.com
		cutcostshop.com
		rollbackmarket.com
		theworldpc.com
		thehotspotscout.com
		wholeearthpc.com
		theworldlaptop.com
		thehotspotdirect.com
		radiospaceonline.com
		theradiospace.com
		shortwavearea.com
		thelitonline.com
		litonlinecentral.com
		literatureontheweb.com
		myilluminatenet.com
		myglobalcomputer.com
		fmgalaxy.com
		funhangoutdirectory.com
		heatplacesdirect.com
		globelaptop.com
		illuminateweb.com
		coolplacesguide.com
		amgalaxy.com
68.66.212.189 1
	ns1.anquin.com 32
		shoptransport.com
		dishoutra.com
		provideck.com
		rebatesky.com
		cyclogive.com
		broughtze.com
		holidaybrought.com
		cedett.com
		handovergreen.com
		hereduce.com
		imploresave.com
		funobjective.com
		myglobesource.com
		webglobalsources.com
		worldwidebeginning.com
		personalizedsay.com
		paperbackequals.com
		novelofmatches.com
		echargeplus.com
		electricaddition.com
		earthsuppliesonline.com
		privatesayonline.com
		myglobalorigin.com
		minevoice.com
		mypersonalvoice.com
		myelectricplus.com
		bookoftwins.com
		myinnerspeak.com
		literatureofmatches.com
		bookofsticks.com
		batteriesadd.com
		batteriesaddition.com
68.66.212.190 1
	ns2.anquin.com 32
		shoptransport.com
		dishoutra.com
		provideck.com
		rebatesky.com
		cyclogive.com
		broughtze.com
		holidaybrought.com
		cedett.com
		handovergreen.com
		hereduce.com
		imploresave.com
		funobjective.com
		myglobesource.com
		webglobalsources.com
		worldwidebeginning.com
		personalizedsay.com
		paperbackequals.com
		novelofmatches.com
		echargeplus.com
		electricaddition.com
		earthsuppliesonline.com
		privatesayonline.com
		myglobalorigin.com
		minevoice.com
		mypersonalvoice.com
		myelectricplus.com
		bookoftwins.com
		myinnerspeak.com
		literatureofmatches.com
		bookofsticks.com
		batteriesadd.com
		batteriesaddition.com
68.66.213.191 1
	ns1.harleret.com 32
		distributecar.com
		abreduce.com
		savingsbuild.com
		airliftsave.com
		coolmarkdown.com
		minddiscount.com
		pointrebate.com
		bizhandover.com
		transportget.com
		topprovide.com
		rebrought.com
		exemptionauto.com
		lowrateblue.com
		mediarollback.com
		coaxdecrease.com
		cedegames.com
		disdelti.com
		andeduction.com
		reductionorder.com
		addressdecrease.com
		faircutcost.com
		storegive.com
		webselleronline.com
		sodalabeling.com
		theonlinevendor.com
		popbrandings.com
		ewebmerchants.com
		myinternetretailer.com
		mynetretailer.com
		mypopbranding.com
		burstlabeling.com
		burstmarking.com
68.66.213.192 1
	ns2.harleret.com 32
		distributecar.com
		abreduce.com
		savingsbuild.com
		airliftsave.com
		coolmarkdown.com
		minddiscount.com
		pointrebate.com
		bizhandover.com
		transportget.com
		topprovide.com
		rebrought.com
		exemptionauto.com
		lowrateblue.com
		mediarollback.com
		coaxdecrease.com
		cedegames.com
		disdelti.com
		andeduction.com
		reductionorder.com
		addressdecrease.com
		faircutcost.com
		storegive.com
		webselleronline.com
		sodalabeling.com
		theonlinevendor.com
		popbrandings.com
		ewebmerchants.com
		myinternetretailer.com
		mynetretailer.com
		mypopbranding.com
		burstlabeling.com
		burstmarking.com
68.66.214.125 1
	ns1.apostaf.com 32
		hecarried.com
		transferreddeal.com
		valuecutcost.com
		transportfly.com
		deductionto.com
		bestcede.com
		reddistribute.com
		taskreduction.com
		infohandover.com
		markdownbest.com
		pinchsavings.com
		hotlowrate.com
		bestexemption.com
		blogprovide.com
		prodelivered.com
		huntdiscount.com
		disdelbiz.com
		webnovelboutique.com
		webonlinebookstore.com
		stretchneighborhoods.com
		placeonask.com
		venuesondemand.com
		onlinebookstorecentral.com
		reachcommunities.com
		netnovelshop.com
		reachneighborhoods.com
		promoterightnow.com
		onlinepaperbackbuy.com
		rangelocal.com
		marketsondemands.com
		marketonrequest.com
		attainlocal.com
68.66.214.126 1
	ns2.apostaf.com 32
		hecarried.com
		transferreddeal.com
		valuecutcost.com
		transportfly.com
		deductionto.com
		bestcede.com
		reddistribute.com
		taskreduction.com
		infohandover.com
		markdownbest.com
		pinchsavings.com
		hotlowrate.com
		bestexemption.com
		blogprovide.com
		prodelivered.com
		huntdiscount.com
		disdelbiz.com
		webnovelboutique.com
		webonlinebookstore.com
		stretchneighborhoods.com
		placeonask.com
		venuesondemand.com
		onlinebookstorecentral.com
		reachcommunities.com
		netnovelshop.com
		reachneighborhoods.com
		promoterightnow.com
		onlinepaperbackbuy.com
		rangelocal.com
		marketsondemands.com
		marketonrequest.com
		attainlocal.com
68.66.215.160 1
	ns1.wanidol.com 32
		maddistribute.com
		totalitycounsel.com
		massrequestdeal.com
		massappealtrade.com
		attractionbalance.com
		submitmad.com
		hunkidea.com
		massappealel.com
		alluresavings.com
		charmbest.com
		bulkmetropolis.com
		extentdealod.com
		tropicbook.com
		transparentsight.com
		themanwearhouse.com
		transparentvision.com
		tropicalpaperbacks.com
		themensclothesplace.com
		largeexpectations.com
		rainforestreading.com
		myjunglebooks.com
		manstorage.com
		maledresshome.com
		mygreatbeliefs.com
		maleclothinghouse.com
		greatexpectancy.com
		largeresponsibilities.com
		cloudlesssight.com
		heavyexpectations.com
		junglenovels.com
		clearupvision.com
		clearimagination.com
68.66.215.161 1
	ns2.wanidol.com 32
		maddistribute.com
		totalitycounsel.com
		massrequestdeal.com
		massappealtrade.com
		attractionbalance.com
		submitmad.com
		hunkidea.com
		massappealel.com
		alluresavings.com
		charmbest.com
		bulkmetropolis.com
		extentdealod.com
		tropicbook.com
		transparentsight.com
		themanwearhouse.com
		transparentvision.com
		tropicalpaperbacks.com
		themensclothesplace.com
		largeexpectations.com
		rainforestreading.com
		myjunglebooks.com
		manstorage.com
		maledresshome.com
		mygreatbeliefs.com
		maleclothinghouse.com
		greatexpectancy.com
		largeresponsibilities.com
		cloudlesssight.com
		heavyexpectations.com
		junglenovels.com
		clearupvision.com
		clearimagination.com
68.66.216.253 1
	ns1.concami.com 32
		explorevolume.com
		programattraction.com
		totalitymessage.com
		magnitudesavings.com
		purchasemad.com
		infofascinate.com
		mymassappealdeal.com
		surveyvolume.com
		fascinateclick.com
		networkcharm.com
		savingsglamour.com
		allurepromo.com
		glamourinsider.com
		extentdealor.com
		bulkreal.com
		massappealer.com
		hunkalliance.com
		timemeanimal.com
		smartfemaleshops.com
		savvygirlstore.com
		savvywomanboutique.com
		numericbeeline.com
		digidirection.com
		computerizedpoint.com
		datesmypet.com
		datemylabrador.com
		digitaldirects.com
		digitalbeeline.com
		daymycat.com
		cleverwomanboutique.com
		cleverladystore.com
		appointmentmedog.com
68.66.216.254 1
	ns2.concami.com 32
		explorevolume.com
		programattraction.com
		totalitymessage.com
		magnitudesavings.com
		purchasemad.com
		infofascinate.com
		mymassappealdeal.com
		surveyvolume.com
		fascinateclick.com
		networkcharm.com
		savingsglamour.com
		allurepromo.com
		glamourinsider.com
		extentdealor.com
		bulkreal.com
		massappealer.com
		hunkalliance.com
		timemeanimal.com
		smartfemaleshops.com
		savvygirlstore.com
		savvywomanboutique.com
		numericbeeline.com
		digidirection.com
		computerizedpoint.com
		datesmypet.com
		datemylabrador.com
		digitaldirects.com
		digitalbeeline.com
		daymycat.com
		cleverwomanboutique.com
		cleverladystore.com
		appointmentmedog.com
68.66.217.130 1
	ns1.potheo.com 32
		attractionreduce.com
		magnitudevalue.com
		madmaintain.com
		reviewvolume.com
		webfascinate.com
		glamourasset.com
		charmbusiness.com
		extentdealph.com
		agentsbulk.com
		massappealew.com
		alluremarket.com
		hunkbusiness.com
		thepaperbacknook.com
		thenovelshelf.com
		thesuccesscrew.com
		winningcrew.com
		vegasvacationquick.com
		onlinereadshelf.com
		myvictorygroup.com
		vegasgetawaydirect.com
		sincitytripnow.com
		sincitygetawaydirect.com
		thebookcubbies.com
		nextbooksmedia.com
		nextbookmedium.com
		lasvegasvacationnow.com
		myvictorycrew.com
		mybookcubby.com
		afternovelcommunication.com
		followingpaperbackmedia.com
		ewingathering.com
		afternovelbroadcast.com
68.66.217.131 1
	ns2.potheo.com 32
		attractionreduce.com
		magnitudevalue.com
		madmaintain.com
		reviewvolume.com
		webfascinate.com
		glamourasset.com
		charmbusiness.com
		extentdealph.com
		agentsbulk.com
		massappealew.com
		alluremarket.com
		hunkbusiness.com
		thepaperbacknook.com
		thenovelshelf.com
		thesuccesscrew.com
		winningcrew.com
		vegasvacationquick.com
		onlinereadshelf.com
		myvictorygroup.com
		vegasgetawaydirect.com
		sincitytripnow.com
		sincitygetawaydirect.com
		thebookcubbies.com
		nextbooksmedia.com
		nextbookmedium.com
		lasvegasvacationnow.com
		myvictorycrew.com
		mybookcubby.com
		afternovelcommunication.com
		followingpaperbackmedia.com
		ewingathering.com
		afternovelbroadcast.com
68.66.218.193 1
	ns1.cardlear.com 32
		shopmagnitude.com
		mediaappealdeal.com
		totalityexperience.com
		volumelocate.com
		attractionqualify.com
		glamoursavings.com
		massappealnc.com
		listingsbulk.com
		extentdealpk.com
		charmthe.com
		hunkcompany.com
		allurevalue.com
		tripwiresmedia.com
		widespreadlabel.com
		triplinemedium.com
		webmorningnews.com
		stumblecablecommunication.com
		nationalbrandsonline.com
		nationalbrandsnet.com
		mycapitalmedium.com
		myearlynews.com
		countrywidelogo.com
		fallstringmedia.com
		mymorningreport.com
		earlypapers.com
		beginningdailyreport.com
		assestsmidway.com
		falllinemedium.com
		countrywidecompany.com
		capmedium.com
		capitalmiddle.com
		assetsmiddle.com
68.66.218.194 1
	ns2.cardlear.com 32
		shopmagnitude.com
		mediaappealdeal.com
		totalityexperience.com
		volumelocate.com
		attractionqualify.com
		glamoursavings.com
		massappealnc.com
		listingsbulk.com
		extentdealpk.com
		charmthe.com
		hunkcompany.com
		allurevalue.com
		tripwiresmedia.com
		widespreadlabel.com
		triplinemedium.com
		webmorningnews.com
		stumblecablecommunication.com
		nationalbrandsonline.com
		nationalbrandsnet.com
		mycapitalmedium.com
		myearlynews.com
		countrywidelogo.com
		fallstringmedia.com
		mymorningreport.com
		earlypapers.com
		beginningdailyreport.com
		assestsmidway.com
		falllinemedium.com
		countrywidecompany.com
		capmedium.com
		capitalmiddle.com
		assetsmiddle.com
68.66.219.194 1
	ns1.maidizan.com 32
		massappealhandle.com
		fascinatedata.com
		discountmagnitude.com
		totalityguidance.com
		respondmad.com
		locationsbulk.com
		charmeasy.com
		massappealng.com
		extentdealra.com
		glamourtransaction.com
		hunkexpert.com
		allurefair.com
		throwtoptalk.com
		planetspersonal.com
		orbitpeople.com
		onlineplanetpeople.com
		orbitsocialize.com
		studyandmake.com
		studynmakemoney.com
		hatshantynet.com
		learnandget.com
		myglobepersonals.com
		horsetoptalk.com
		bullheadconversate.com
		learnandearns.com
		capshantyweb.com
		helmetstorenet.com
		hatshutonline.com
		capshackonline.com
		buckleadcommunications.com
		buckheadcommunications.com
		absorbandearn.com
68.66.219.195 1
	ns2.maidizan.com 32
		massappealhandle.com
		fascinatedata.com
		discountmagnitude.com
		totalityguidance.com
		respondmad.com
		locationsbulk.com
		charmeasy.com
		massappealng.com
		extentdealra.com
		glamourtransaction.com
		hunkexpert.com
		allurefair.com
		throwtoptalk.com
		planetspersonal.com
		orbitpeople.com
		onlineplanetpeople.com
		orbitsocialize.com
		studyandmake.com
		studynmakemoney.com
		hatshantynet.com
		learnandget.com
		myglobepersonals.com
		horsetoptalk.com
		bullheadconversate.com
		learnandearns.com
		capshantyweb.com
		helmetstorenet.com
		hatshutonline.com
		capshackonline.com
		buckleadcommunications.com
		buckheadcommunications.com
		absorbandearn.com
68.66.220.98 1
	ns1.perselay.com 32
		totalityoffer.com
		attractionestimate.com
		sitefascinate.com
		adjustattraction.com
		promotionsmagnitude.com
		magnitudepromo.com
		madexecute.com
		totalityinfo.com
		pileappealdeal.com
		netfascinate.com
		volumereview.com
		flycharm.com
		massappealri.com
		allurediscount.com
		hunkaffiliate.com
		townbulk.com
		extentdealvi.com
		womansandalonline.com
		treewebusers.com
		treewebcustomer.com
		thefemaleslipper.com
		railwaydate.com
		railwayappointment.com
		onlinecityday.com
		myladyslipper.com
		femalesandal.com
		ladyfootwearstore.com
		mymetromeeting.com
		mymetrodate.com
		ashspiderclients.com
		dusttangledpeople.com
		ashwebclients.com
68.66.220.99 1
	ns2.perselay.com 32
		totalityoffer.com
		attractionestimate.com
		sitefascinate.com
		adjustattraction.com
		promotionsmagnitude.com
		magnitudepromo.com
		madexecute.com
		totalityinfo.com
		pileappealdeal.com
		netfascinate.com
		volumereview.com
		flycharm.com
		massappealri.com
		allurediscount.com
		hunkaffiliate.com
		townbulk.com
		extentdealvi.com
		womansandalonline.com
		treewebusers.com
		treewebcustomer.com
		thefemaleslipper.com
		railwaydate.com
		railwayappointment.com
		onlinecityday.com
		myladyslipper.com
		femalesandal.com
		ladyfootwearstore.com
		mymetromeeting.com
		mymetrodate.com
		ashspiderclients.com
		dusttangledpeople.com
		ashwebclients.com
68.66.221.222 1
	ns1.larinali.com 32
		savemagnitude.com
		fascinatedigital.com
		magnitudemart.com
		totalitydiscover.com
		retrieveattraction.com
		madregister.com
		massappealdealonline.com
		volumesurvey.com
		volumeexamine.com
		hunkglobal.com
		villagebulk.com
		charmsearch.com
		massappealtu.com
		dealsglamour.com
		boardglamour.com
		extentdealso.com
		allurecatalog.com
		wirelesstechsaving.com
		roofjunction.com
		wirelesstechfund.com
		recentgoodsweb.com
		radiotechsavings.com
		newstuffweb.com
		modernproductsonline.com
		mobiletechnologyfund.com
		mynewproductsonline.com
		mobileschoolmoney.com
		freshgoodsnet.com
		dometogether.com
		ceilingconnection.com
		domeconnections.com
		archedtoptogether.com
68.66.221.223 1
	ns2.larinali.com 32
		savemagnitude.com
		fascinatedigital.com
		magnitudemart.com
		totalitydiscover.com
		retrieveattraction.com
		madregister.com
		massappealdealonline.com
		volumesurvey.com
		volumeexamine.com
		hunkglobal.com
		villagebulk.com
		charmsearch.com
		massappealtu.com
		dealsglamour.com
		boardglamour.com
		extentdealso.com
		allurecatalog.com
		wirelesstechsaving.com
		roofjunction.com
		wirelesstechfund.com
		recentgoodsweb.com
		radiotechsavings.com
		newstuffweb.com
		modernproductsonline.com
		mobiletechnologyfund.com
		mynewproductsonline.com
		mobileschoolmoney.com
		freshgoodsnet.com
		dometogether.com
		ceilingconnection.com
		domeconnections.com
		archedtoptogether.com
68.66.224.2 1
	ns1.livract.com 32
		furesource.com
		furnishernet.com
		affordcherry.com
		camcaterer.com
		providerget.com
		livestocker.com
		equiptageo.com
		offsetfind.com
		reserveeat.com
		swincentive.com
		zareward.com
		purveynet.com
		popcontribute.com
		wehandover.com
		profitred.com
		yieldnews.com
		feederphoto.com
		purebates.com
		takeaccolade.com
		netredeem.com
		clipoutfit.com
		modpremium.com
		dividendbiz.com
		dispensebook.com
		protreasure.com
		delivercrafts.com
		endowpre.com
		bountynew.com
		benefittop.com
		bonusgive.com
		paymentjob.com
		brogain.com
68.66.224.3 1
	ns2.livract.com 32
		furesource.com
		furnishernet.com
		affordcherry.com
		camcaterer.com
		providerget.com
		livestocker.com
		equiptageo.com
		offsetfind.com
		reserveeat.com
		swincentive.com
		zareward.com
		purveynet.com
		popcontribute.com
		wehandover.com
		profitred.com
		yieldnews.com
		feederphoto.com
		purebates.com
		takeaccolade.com
		netredeem.com
		clipoutfit.com
		modpremium.com
		dividendbiz.com
		dispensebook.com
		protreasure.com
		delivercrafts.com
		endowpre.com
		bountynew.com
		benefittop.com
		bonusgive.com
		paymentjob.com
		brogain.com
68.66.225.253 1
	ns1.stitedwi.com 8
		talkrebates.com
		rewardblue.com
		accoladecatch.com
		paymentwalk.com
		redeemfind.com
		hebenefit.com
		ambonus.com
		incentivent.com
68.66.225.254 1
	ns2.stitedwi.com 8
		talkrebates.com
		rewardblue.com
		accoladecatch.com
		paymentwalk.com
		redeemfind.com
		hebenefit.com
		ambonus.com
		incentivent.com
68.66.226.253 1
	ns1.deerbi.com 32
		providergreen.com
		buildreserve.com
		caterersha.com
		affordpass.com
		flyresource.com
		tipgrow.com
		stockerstar.com
		producerlife.com
		producerto.com
		tapayment.com
		throwperk.com
		premmyield.com
		redfeeder.com
		profitcompare.com
		rentoutfit.com
		premiumdraw.com
		rewsupstore.com
		bountybest.com
		bluegrant.com
		benefitwin.com
		compensatecity.com
		dispensegames.com
		repaybiz.com
		purveybuy.com
		winreward.com
		hostoffset.com
		deliverworks.com
		dividendhost.com
		awarddrop.com
		honorget.com
		listprize.com
		decocontribute.com
68.66.226.254 1
	ns2.deerbi.com 32
		providergreen.com
		buildreserve.com
		caterersha.com
		affordpass.com
		flyresource.com
		tipgrow.com
		stockerstar.com
		producerlife.com
		producerto.com
		tapayment.com
		throwperk.com
		premmyield.com
		redfeeder.com
		profitcompare.com
		rentoutfit.com
		premiumdraw.com
		rewsupstore.com
		bountybest.com
		bluegrant.com
		benefitwin.com
		compensatecity.com
		dispensegames.com
		repaybiz.com
		purveybuy.com
		winreward.com
		hostoffset.com
		deliverworks.com
		dividendhost.com
		awarddrop.com
		honorget.com
		listprize.com
		decocontribute.com
68.66.227.2 1
	ns1.pregrig.com 32
		compensatetown.com
		contributecar.com
		chifurnish.com
		youprovider.com
		funcaterer.com
		cookreserve.com
		fineendow.com
		feederetwo.com
		gamehandover.com
		rewardcatch.com
		winbounty.com
		rewsupnet.com
		outfitseek.com
		tipstorkin.com
		equipgames.com
		handoverin.com
		storepremium.com
		dispenseth.com
		grantyou.com
		cordeliver.com
		purveyworld.com
		paymentri.com
		sourceprize.com
		crocprofit.com
		treasurecar.com
		pointoffset.com
		repaycool.com
		buildaccolade.com
		onegain.com
		incentivehot.com
		awardjump.com
		onefulfill.com
68.66.227.3 1
	ns2.pregrig.com 32
		compensatetown.com
		contributecar.com
		chifurnish.com
		youprovider.com
		funcaterer.com
		cookreserve.com
		fineendow.com
		feederetwo.com
		gamehandover.com
		rewardcatch.com
		winbounty.com
		rewsupnet.com
		outfitseek.com
		tipstorkin.com
		equipgames.com
		handoverin.com
		storepremium.com
		dispenseth.com
		grantyou.com
		cordeliver.com
		purveyworld.com
		paymentri.com
		sourceprize.com
		crocprofit.com
		treasurecar.com
		pointoffset.com
		repaycool.com
		buildaccolade.com
		onegain.com
		incentivehot.com
		awardjump.com
		onefulfill.com
68.66.228.2 1
	ns1.hagett.com 1
		marketfulfill.com
68.66.228.3 1
	ns2.hagett.com 1
		marketfulfill.com
68.66.231.253 1
	ns1.marylem.com 32
		resourcepo.com
		affordater.com
		contributecool.com
		furnisherba.com
		providercy.com
		voyreserve.com
		catererbest.com
		worlddividend.com
		styleendow.com
		wigdeliver.com
		tiprealestate.com
		passprofit.com
		skirtgrant.com
		rewsupmobile.com
		premiumnew.com
		perkmarket.com
		gainnew.com
		compensatest.com
		redeemeasy.com
		shopperk.com
		needoffset.com
		fulfillred.com
		coolyield.com
		prizeby.com
		tomaward.com
		olbounty.com
		mirepay.com
		rebatesget.com
		livehonor.com
		jetreasure.com
		musicbonus.com
		redispense.com
68.66.231.254 1
	ns2.marylem.com 32
		resourcepo.com
		affordater.com
		contributecool.com
		furnisherba.com
		providercy.com
		voyreserve.com
		catererbest.com
		worlddividend.com
		styleendow.com
		wigdeliver.com
		tiprealestate.com
		passprofit.com
		skirtgrant.com
		rewsupmobile.com
		premiumnew.com
		perkmarket.com
		gainnew.com
		compensatest.com
		redeemeasy.com
		shopperk.com
		needoffset.com
		fulfillred.com
		coolyield.com
		prizeby.com
		tomaward.com
		olbounty.com
		mirepay.com
		rebatesget.com
		livehonor.com
		jetreasure.com
		musicbonus.com
		redispense.com
68.66.232.2 1
	ns1.joreyet.com 32
		resourcered.com
		furnishercar.com
		afforderal.com
		youequip.com
		stockercity.com
		rewsupbox.com
		youhonor.com
		neckfeeder.com
		travelyield.com
		nearaendow.com
		handovercity.com
		producerstar.com
		upincentive.com
		perkgrow.com
		prizeta.com
		gainzi.com
		logrepay.com
		motreasure.com
		madividend.com
		accoladeget.com
		liproducer.com
		getredeem.com
		impstocker.com
		meatialtip.com
		fulfillblue.com
		drawrebates.com
		equipature.com
		outfitcloak.com
		bonusry.com
		docompensate.com
		doaward.com
		carrigrant.com
68.66.232.3 1
	ns2.joreyet.com 32
		resourcered.com
		furnishercar.com
		afforderal.com
		youequip.com
		stockercity.com
		rewsupbox.com
		youhonor.com
		neckfeeder.com
		travelyield.com
		nearaendow.com
		handovercity.com
		producerstar.com
		upincentive.com
		perkgrow.com
		prizeta.com
		gainzi.com
		logrepay.com
		motreasure.com
		madividend.com
		accoladeget.com
		liproducer.com
		getredeem.com
		impstocker.com
		meatialtip.com
		fulfillblue.com
		drawrebates.com
		equipature.com
		outfitcloak.com
		bonusry.com
		docompensate.com
		doaward.com
		carrigrant.com
68.66.233.2 1
	ns1.chielash.com 32
		theorygloss.com
		notionwind.com
		opinioninstant.com
		mesentiments.com
		shelverenter.com
		putmind.com
		beliefblue.com
		speculatecity.com
		offerge.com
		myrismoodity.com
		complyfun.com
		publishred.com
		edconclusion.com
		seascitytake.com
		nuthesis.com
		cavementor.com
		buildposition.com
		ecolobey.com
		attitudeinfo.com
		povgreen.com
		surmisestory.com
		viewsgive.com
		reworkinidea.com
		topicpresent.com
		agreevideo.com
		slantdrop.com
		starcomply.com
		givehelper.com
		chalkthought.com
		feelingdraw.com
		stancecity.com
		caperception.com
68.66.233.3 1
	ns2.chielash.com 32
		theorygloss.com
		notionwind.com
		opinioninstant.com
		mesentiments.com
		shelverenter.com
		putmind.com
		beliefblue.com
		speculatecity.com
		offerge.com
		myrismoodity.com
		complyfun.com
		publishred.com
		edconclusion.com
		seascitytake.com
		nuthesis.com
		cavementor.com
		buildposition.com
		ecolobey.com
		attitudeinfo.com
		povgreen.com
		surmisestory.com
		viewsgive.com
		reworkinidea.com
		topicpresent.com
		agreevideo.com
		slantdrop.com
		starcomply.com
		givehelper.com
		chalkthought.com
		feelingdraw.com
		stancecity.com
		caperception.com
68.66.234.253 1
	ns1.navvyky.com 8
		positiongive.com
		saysoread.com
		caveur.com
		thesison.com
		coolspeculate.com
		osslee.com
		viewsbuild.com
		lasentiments.com
68.66.234.254 1
	ns2.navvyky.com 8
		positiongive.com
		saysoread.com
		caveur.com
		thesison.com
		coolspeculate.com
		osslee.com
		viewsbuild.com
		lasentiments.com
68.66.235.2 1
	ns1.grouteu.com 32
		turnnotion.com
		ideainterpret.com
		submitcool.com
		stanceblog.com
		sourceos.com
		enterreport.com
		judgmentfind.com
		conclusioned.com
		povbest.com
		positionput.com
		teaccept.com
		speculateonline.com
		handinsh.com
		hostingtake.com
		slanttalk.com
		studyoped.com
		offerprove.com
		sentimentsbest.com
		provepresent.com
		makeviews.com
		makefeeling.com
		linkopsub.com
		yoperception.com
		thoughtwin.com
		surmiseegg.com
		thesisinstall.com
		opiniontrade.com
		tempuragive.com
		theoryclose.com
		favourstoop.com
		ideacomply.com
		attitudered.com
68.66.235.3 1
	ns2.grouteu.com 32
		turnnotion.com
		ideainterpret.com
		submitcool.com
		stanceblog.com
		sourceos.com
		enterreport.com
		judgmentfind.com
		conclusioned.com
		povbest.com
		positionput.com
		teaccept.com
		speculateonline.com
		handinsh.com
		hostingtake.com
		slanttalk.com
		studyoped.com
		offerprove.com
		sentimentsbest.com
		provepresent.com
		makeviews.com
		makefeeling.com
		linkopsub.com
		yoperception.com
		thoughtwin.com
		surmiseegg.com
		thesisinstall.com
		opiniontrade.com
		tempuragive.com
		theoryclose.com
		favourstoop.com
		ideacomply.com
		attitudered.com
68.66.236.253 1
	ns1.fastalia.com 32
		greatpublish.com
		judgmenthome.com
		handincool.com
		wradvice.com
		bornattitude.com
		mailstance.com
		replacethesis.com
		opedtell.com
		tellcave.com
		takethekield.com
		conclusionnew.com
		proposemy.com
		opinionmake.com
		saysodo.com
		justoop.com
		agreeta.com
		personalput.com
		easypov.com
		singlenviews.com
		beliefcashel.com
		throwidea.com
		tapiofeeling.com
		perceptionfind.com
		presentmatter.com
		sunsosurmise.com
		topicobey.com
		sentimentsinfo.com
		linkspeculate.com
		acceptnews.com
		crickerslant.com
		blueopsub.com
		submitmind.com
68.66.236.254 1
	ns2.fastalia.com 32
		greatpublish.com
		judgmenthome.com
		handincool.com
		wradvice.com
		bornattitude.com
		mailstance.com
		replacethesis.com
		opedtell.com
		tellcave.com
		takethekield.com
		conclusionnew.com
		proposemy.com
		opinionmake.com
		saysodo.com
		justoop.com
		agreeta.com
		personalput.com
		easypov.com
		singlenviews.com
		beliefcashel.com
		throwidea.com
		tapiofeeling.com
		perceptionfind.com
		presentmatter.com
		sunsosurmise.com
		topicobey.com
		sentimentsinfo.com
		linkspeculate.com
		acceptnews.com
		crickerslant.com
		blueopsub.com
		submitmind.com
68.66.237.2 1
	ns1.diplot.com 1
		perceptionone.com
68.66.237.3 1
	ns2.diplot.com 1
		perceptionone.com
68.66.238.2 1
	ns1.langlati.com 32
		jobbyutheory.com
		carriebelief.com
		curdlenotion.com
		opedcounsel.com
		obeywise.com
		remoffer.com
		attituderoid.com
		youstance.com
		povhosting.com
		vivagree.com
		sipresent.com
		judgmentop.com
		drawsayso.com
		conclusionsite.com
		surmiselive.com
		advicetheme.com
		thoughttop.com
		makeposition.com
		wisdomcave.com
		putsmart.com
		swingmy.com
		opsubcool.com
		pointsubmit.com
		cohandin.com
		teachenter.com
		sentimentsnet.com
		utilizethesis.com
		feelingfind.com
		acceptfly.com
		postulatemake.com
		stoopjot.com
		opinionwalk.com
68.66.238.3 1
	ns2.langlati.com 32
		jobbyutheory.com
		carriebelief.com
		curdlenotion.com
		opedcounsel.com
		obeywise.com
		remoffer.com
		attituderoid.com
		youstance.com
		povhosting.com
		vivagree.com
		sipresent.com
		judgmentop.com
		drawsayso.com
		conclusionsite.com
		surmiselive.com
		advicetheme.com
		thoughttop.com
		makeposition.com
		wisdomcave.com
		putsmart.com
		swingmy.com
		opsubcool.com
		pointsubmit.com
		cohandin.com
		teachenter.com
		sentimentsnet.com
		utilizethesis.com
		feelingfind.com
		acceptfly.com
		postulatemake.com
		stoopjot.com
		opinionwalk.com
68.66.239.253 1
	ns1.edgeoite.com 32
		benzeos.com
		obeyoffer.com
		myuncork.com
		lifesentiments.com
		postulatebuild.com
		heleoped.com
		notionblast.com
		workousubmit.com
		mediaagree.com
		acceptur.com
		stoopsolve.com
		offerthought.com
		saysoil.com
		judgmentat.com
		tricave.com
		complycity.com
		presentro.com
		slantsource.com
		opsubnet.com
		lehumor.com
		spacetake.com
		watchthought.com
		ideausher.com
		publishjeros.com
		osthe.com
		handinpoint.com
		tradepublish.com
		adviceenter.com
		beliefinfo.com
		talkpostulate.com
		adviceoffer.com
		theorypaint.com
68.66.239.254 1
	ns2.edgeoite.com 32
		benzeos.com
		obeyoffer.com
		myuncork.com
		lifesentiments.com
		postulatebuild.com
		heleoped.com
		notionblast.com
		workousubmit.com
		mediaagree.com
		acceptur.com
		stoopsolve.com
		offerthought.com
		saysoil.com
		judgmentat.com
		tricave.com
		complycity.com
		presentro.com
		slantsource.com
		opsubnet.com
		lehumor.com
		spacetake.com
		watchthought.com
		ideausher.com
		publishjeros.com
		osthe.com
		handinpoint.com
		tradepublish.com
		adviceenter.com
		beliefinfo.com
		talkpostulate.com
		adviceoffer.com
		theorypaint.com
68.66.242.253 1
	ns1.tampipa.com 1
		mediataste.com
68.66.242.254 1
	ns2.tampipa.com 1
		mediataste.com
68.66.243.2 1
	ns1.affecon.com 32
		bitesocial.com
		universityeat.com
		surelations.com
		hostingeat.com
		zingcrowd.com
		preferencebiz.com
		crowdquality.com
		appetitenews.com
		healthofbean.com
		forgiospicy.com
		palatelist.com
		forumsample.com
		flavorgym.com
		exquisitestar.com
		tradeexquisite.com
		policybest.com
		lostorage.com
		buschool.com
		opiniongreen.com
		prmake.com
		ropublic.com
		sweetfirm.com
		zingbackhemy.com
		deknown.com
		cookotor.com
		gosalty.com
		savoryweb.com
		watercliking.com
		spacesip.com
		tasteen.com
		marketbuds.com
		communitydrink.com
68.66.243.3 1
	ns2.affecon.com 32
		bitesocial.com
		universityeat.com
		surelations.com
		hostingeat.com
		zingcrowd.com
		preferencebiz.com
		crowdquality.com
		appetitenews.com
		healthofbean.com
		forgiospicy.com
		palatelist.com
		forumsample.com
		flavorgym.com
		exquisitestar.com
		tradeexquisite.com
		policybest.com
		lostorage.com
		buschool.com
		opiniongreen.com
		prmake.com
		ropublic.com
		sweetfirm.com
		zingbackhemy.com
		deknown.com
		cookotor.com
		gosalty.com
		savoryweb.com
		watercliking.com
		spacesip.com
		tasteen.com
		marketbuds.com
		communitydrink.com
68.66.244.253 1
	ns1.cajuper.com 32
		libraryred.com
		chopinion.com
		zingloop.com
		qualitymore.com
		redrelations.com
		meetingsip.com
		appetitegreen.com
		generalie.com
		inpreference.com
		flavorglobal.com
		recordsak.com
		ideasweet.com
		storecommunity.com
		policyget.com
		schooleat.com
		opengulp.com
		cookparking.com
		dashmember.com
		savorycrowd.com
		healthnetaxi.com
		spicyroseli.com
		prfind.com
		balcook.com
		worldtpt.com
		publictt.com
		knowncity.com
		eaterwe.com
		storagenew.com
		civicidea.com
		saltyme.com
		blogpalate.com
		hottmarket.com
68.66.244.254 1
	ns2.cajuper.com 32
		libraryred.com
		chopinion.com
		zingloop.com
		qualitymore.com
		redrelations.com
		meetingsip.com
		appetitegreen.com
		generalie.com
		inpreference.com
		flavorglobal.com
		recordsak.com
		ideasweet.com
		storecommunity.com
		policyget.com
		schooleat.com
		opengulp.com
		cookparking.com
		dashmember.com
		savorycrowd.com
		healthnetaxi.com
		spicyroseli.com
		prfind.com
		balcook.com
		worldtpt.com
		publictt.com
		knowncity.com
		eaterwe.com
		storagenew.com
		civicidea.com
		saltyme.com
		blogpalate.com
		hottmarket.com
68.66.245.2 1
	ns1.ravioca.com 32
		takeuniversity.com
		communityst.com
		savorydigital.com
		prdiet.com
		ideaquality.com
		bitelive.com
		centerflavor.com
		dillyceletpt.com
		centerpreference.com
		onlinezing.com
		imagecivic.com
		officialdash.com
		senseexpert.com
		policycook.com
		yahgood.com
		exquisitenet.com
		tangyblog.com
		blueeat.com
		knowngreen.com
		puppensample.com
		storageblue.com
		saltycool.com
		hottblue.com
		giveschool.com
		parkingum.com
		publicblue.com
		cityspicy.com
		thepeopleinfo.com
		readgeneral.com
		sipersixpenn.com
		recordstake.com
		grouplibrary.com
68.66.245.3 1
	ns2.ravioca.com 32
		takeuniversity.com
		communityst.com
		savorydigital.com
		prdiet.com
		ideaquality.com
		bitelive.com
		centerflavor.com
		dillyceletpt.com
		centerpreference.com
		onlinezing.com
		imagecivic.com
		officialdash.com
		senseexpert.com
		policycook.com
		yahgood.com
		exquisitenet.com
		tangyblog.com
		blueeat.com
		knowngreen.com
		puppensample.com
		storageblue.com
		saltycool.com
		hottblue.com
		giveschool.com
		parkingum.com
		publicblue.com
		cityspicy.com
		thepeopleinfo.com
		readgeneral.com
		sipersixpenn.com
		recordstake.com
		grouplibrary.com
68.66.246.2 1
	ns1.deephe.com 8
		flyopinion.com
		sweetmulti.com
		storepublic.com
		tangyworld.com
		sensefind.com
		infotpt.com
		peoplered.com
		spicysky.com
68.66.246.3 1
	ns2.deephe.com 8
		flyopinion.com
		sweetmulti.com
		storepublic.com
		tangyworld.com
		sensefind.com
		infotpt.com
		peoplered.com
		spicysky.com
68.66.247.253 1
	ns1.seassil.com 32
		poppreference.com
		storagecook.com
		nutripr.com
		recordseat.com
		frontgood.com
		samplearetta.com
		plutomedbite.com
		blogtpt.com
		dashgreen.com
		relationsart.com
		schoolka.com
		parkingdrink.com
		walkopen.com
		telibrary.com
		apexquisite.com
		tangynews.com
		palatebottie.com
		groupgeneral.com
		sensered.com
		teamflavor.com
		opinionfind.com
		tastetrade.com
		imagesalty.com
		civicresorte.com
		budsdulonger.com
		healthottels.com
		hotspro.com
		luggiosweet.com
		mediaappetite.com
		loopliking.com
		universitycook.com
		amthepeople.com
68.66.247.254 1
	ns2.seassil.com 32
		poppreference.com
		storagecook.com
		nutripr.com
		recordseat.com
		frontgood.com
		samplearetta.com
		plutomedbite.com
		blogtpt.com
		dashgreen.com
		relationsart.com
		schoolka.com
		parkingdrink.com
		walkopen.com
		telibrary.com
		apexquisite.com
		tangynews.com
		palatebottie.com
		groupgeneral.com
		sensered.com
		teamflavor.com
		opinionfind.com
		tastetrade.com
		imagesalty.com
		civicresorte.com
		budsdulonger.com
		healthottels.com
		hotspro.com
		luggiosweet.com
		mediaappetite.com
		loopliking.com
		universitycook.com
		amthepeople.com
68.66.248.2 1
	ns1.tangend.com 32
		generaleat.com
		universityto.com
		teambite.com
		savoryupware.com
		qualitytinge.com
		tptbusiness.com
		comprohealth.com
		budsbakewpro.com
		bluecivic.com
		plantertisip.com
		bopolicy.com
		birdohot.com
		likingonline.com
		catcappetite.com
		openhant.com
		libraryan.com
		factaste.com
		commercialgood.com
		drinkopen.com
		coolknown.com
		relationsbiz.com
		dorecords.com
		underatangy.com
		parkingidea.com
		thepeoplebest.com
		likingretion.com
		groupsample.com
		networkbuds.com
		dashathismoo.com
		walkcommunity.com
		headuffsense.com
		palatecity.com
68.66.248.3 1
	ns2.tangend.com 32
		generaleat.com
		universityto.com
		teambite.com
		savoryupware.com
		qualitytinge.com
		tptbusiness.com
		comprohealth.com
		budsbakewpro.com
		bluecivic.com
		plantertisip.com
		bopolicy.com
		birdohot.com
		likingonline.com
		catcappetite.com
		openhant.com
		libraryan.com
		factaste.com
		commercialgood.com
		drinkopen.com
		coolknown.com
		relationsbiz.com
		dorecords.com
		underatangy.com
		parkingidea.com
		thepeoplebest.com
		likingretion.com
		groupsample.com
		networkbuds.com
		dashathismoo.com
		walkcommunity.com
		headuffsense.com
		palatecity.com
68.66.249.2 1
	ns1.eamwit.com 32
		purchaserguidance.com
		peakbarg.com
		purchasesteer.com
		whisperbuy.com
		stsimple.com
		theshopperstips.com
		acquirecoop.com
		anshoppers.com
		spendinghelpcentral.com
		shopknowledgeweb.com
		cluemerchant.com
		tipsprices.com
		placemystical.com
		involvevendee.com
		advisesavings.com
		courseknow.com
		introducepurchaser.com
		catalogtips.com
		clarifyvendee.com
		baconsumer.com
		cluecatalog.com
		hoppersgive.com
		tipscart.com
		vendeeadvertise.com
		advisebuy.com
		insureclientele.com
		mywhisperbuy.com
		storeadvise.com
		marketmystic.com
		educateclientele.com
		ideapurchaser.com
		clienteleadvocate.com
68.66.249.3 1
	ns2.eamwit.com 32
		purchaserguidance.com
		peakbarg.com
		purchasesteer.com
		whisperbuy.com
		stsimple.com
		theshopperstips.com
		acquirecoop.com
		anshoppers.com
		spendinghelpcentral.com
		shopknowledgeweb.com
		cluemerchant.com
		tipsprices.com
		placemystical.com
		involvevendee.com
		advisesavings.com
		courseknow.com
		introducepurchaser.com
		catalogtips.com
		clarifyvendee.com
		baconsumer.com
		cluecatalog.com
		hoppersgive.com
		tipscart.com
		vendeeadvertise.com
		advisebuy.com
		insureclientele.com
		mywhisperbuy.com
		storeadvise.com
		marketmystic.com
		educateclientele.com
		ideapurchaser.com
		clienteleadvocate.com
68.66.250.253 1
	ns1.stropai.com 32
		apexbargonline.com
		purchaseridea.com
		purchaseusher.com
		storeclue.com
		consumeran.com
		joinvendee.com
		miraclest.com
		tipscompare.com
		buyhelpcoop.com
		tipssale.com
		trademystic.com
		vendeeincorporate.com
		spendinghelp.com
		vertexbarg.com
		purchaserlearn.com
		purchaserplan.com
		compareadvise.com
		encourageclientele.com
		infopurchaser.com
		fushoppers.com
		advisefair.com
		cluesave.com
		webspendinghelp.com
		stthink.com
		webwhisperbuy.com
		whisperget.com
		webshopknowledge.com
		carttips.com
		shopperstipsonline.com
		clientpeak.com
		discountclue.com
		clienteleaid.com
68.66.250.254 1
	ns2.stropai.com 32
		apexbargonline.com
		purchaseridea.com
		purchaseusher.com
		storeclue.com
		consumeran.com
		joinvendee.com
		miraclest.com
		tipscompare.com
		buyhelpcoop.com
		tipssale.com
		trademystic.com
		vendeeincorporate.com
		spendinghelp.com
		vertexbarg.com
		purchaserlearn.com
		purchaserplan.com
		compareadvise.com
		encourageclientele.com
		infopurchaser.com
		fushoppers.com
		advisefair.com
		cluesave.com
		webspendinghelp.com
		stthink.com
		webwhisperbuy.com
		whisperget.com
		webshopknowledge.com
		carttips.com
		shopperstipsonline.com
		clientpeak.com
		discountclue.com
		clienteleaid.com
68.66.251.2 1
	ns1.adiode.com 8
		cluevalue.com
		vendeeedit.com
		shoppersop.com
		advisemart.com
		consumeray.com
		tipsdiscount.com
		purchaserreport.com
		clientelecoach.com
68.66.251.3 1
	ns2.adiode.com 8
		cluevalue.com
		vendeeedit.com
		shoppersop.com
		advisemart.com
		consumeray.com
		tipsdiscount.com
		purchaserreport.com
		clientelecoach.com
68.66.252.253 1
	ns1.redrone.com 32
		classmystic.com
		storeneed.com
		myshopperstips.com
		shopperscy.com
		bestshopperstips.com
		discountadvise.com
		tipsvalue.com
		spendingaid.com
		purchasegirl.com
		merchandisetips.com
		vendeeclarify.com
		knowledgepurchaser.com
		whispersell.com
		cluecompare.com
		topicpurchaser.com
		reviewsadvise.com
		stpremium.com
		savingsclue.com
		expediteclientele.com
		shopknowing.com
		tipsmerchandise.com
		webmarketmystic.com
		spendingbetter.com
		merchandiseclue.com
		condensevendee.com
		adviseorder.com
		doconsumer.com
		purchaserinfo.com
		purchaserenhance.com
		confervendee.com
		clienteleanswer.com
		clientelecontribute.com
68.66.252.254 1
	ns2.redrone.com 32
		classmystic.com
		storeneed.com
		myshopperstips.com
		shopperscy.com
		bestshopperstips.com
		discountadvise.com
		tipsvalue.com
		spendingaid.com
		purchasegirl.com
		merchandisetips.com
		vendeeclarify.com
		knowledgepurchaser.com
		whispersell.com
		cluecompare.com
		topicpurchaser.com
		reviewsadvise.com
		stpremium.com
		savingsclue.com
		expediteclientele.com
		shopknowing.com
		tipsmerchandise.com
		webmarketmystic.com
		spendingbetter.com
		merchandiseclue.com
		condensevendee.com
		adviseorder.com
		doconsumer.com
		purchaserinfo.com
		purchaserenhance.com
		confervendee.com
		clienteleanswer.com
		clientelecontribute.com
68.66.253.253 1
	ns1.undertz.com 32
		vendeecommunicate.com
		wisdompurchaser.com
		saleadvise.com
		purchasescout.com
		newpurchaseguide.com
		apexbarg.com
		purchaserintroduce.com
		tipspromo.com
		stofficial.com
		shoppersgive.com
		helpclientele.com
		worknoesis.com
		tipsorder.com
		facilitateclientele.com
		vendeearticulate.com
		agenttip.com
		draftvendee.com
		advisecatalog.com
		cluepromotions.com
		clienteleassist.com
		spreehelp.com
		saleclue.com
		promotionstips.com
		themarketmystic.com
		marketorphic.com
		whisperpurchase.com
		myshopknowledge.com
		spendingassist.com
		orderclue.com
		merchandiseadvise.com
		shoppersee.com
		consumerio.com
68.66.253.254 1
	ns2.undertz.com 32
		vendeecommunicate.com
		wisdompurchaser.com
		saleadvise.com
		purchasescout.com
		newpurchaseguide.com
		apexbarg.com
		purchaserintroduce.com
		tipspromo.com
		stofficial.com
		shoppersgive.com
		helpclientele.com
		worknoesis.com
		tipsorder.com
		facilitateclientele.com
		vendeearticulate.com
		agenttip.com
		draftvendee.com
		advisecatalog.com
		cluepromotions.com
		clienteleassist.com
		spreehelp.com
		saleclue.com
		promotionstips.com
		themarketmystic.com
		marketorphic.com
		whisperpurchase.com
		myshopknowledge.com
		spendingassist.com
		orderclue.com
		merchandiseadvise.com
		shoppersee.com
		consumerio.com
68.66.254.2 1
	ns1.coperb.com 1
		shopperstipscentral.com
68.66.254.3 1
	ns2.coperb.com 1
		shopperstipscentral.com
68.66.255.2 1
	ns1.decenne.com 32
		purchasermatter.com
		bestpurchaseguide.com
		reviewsst.com
		tutorpurchaser.com
		webshopperstips.com
		peaksaloong.com
		tipsprice.com
		spendingserve.com
		speakpurchase.com
		orderadvise.com
		shopperstip.com
		topbarg.com
		cluereviews.com
		vendeecollaborate.com
		whisperacquire.com
		purrchaseguide.com
		tipssavings.com
		advisesale.com
		shopnoesis.com
		pricestips.com
		shoppershe.com
		purchaserapprove.com
		clientelecooperate.com
		heconsumer.com
		promoclue.com
		stexpert.com
		familiarizeclientele.com
		marketmystical.com
		enlistvendee.com
		shopperpeak.com
		shoppersme.com
		consumerte.com
68.66.255.3 1
	ns2.decenne.com 32
		purchasermatter.com
		bestpurchaseguide.com
		reviewsst.com
		tutorpurchaser.com
		webshopperstips.com
		peaksaloong.com
		tipsprice.com
		spendingserve.com
		speakpurchase.com
		orderadvise.com
		shopperstip.com
		topbarg.com
		cluereviews.com
		vendeecollaborate.com
		whisperacquire.com
		purrchaseguide.com
		tipssavings.com
		advisesale.com
		shopnoesis.com
		pricestips.com
		shoppershe.com
		purchaserapprove.com
		clientelecooperate.com
		heconsumer.com
		promoclue.com
		stexpert.com
		familiarizeclientele.com
		marketmystical.com
		enlistvendee.com
		shopperpeak.com
		shoppersme.com
		consumerte.com
68.232.96.130 1
	ns1.blueine.com 64
		interwhiz.com
		surprisedone.com
		leecomics.com
		placeforthebooks.com
		majorgama.com
		storema.com
		listingsma.com
		starevillage.com
		portentglobal.com
		waybirder.com
		maxportent.com
		pathstimulate.com
		motivatepath.com
		stunnersearch.com
		techgoggle.com
		wayimage.com
		talkeawe.com
		surprisedhost.com
		whizview.com
		gogglestar.com
		routecharm.com
		roadentice.com
		marvave.com
		producway.com
		roompath.com
		roadhigh.com
		passagemouth.com
		sliverpassage.com
		imagestunner.com
		geniusred.com
		sucuriosity.com
		matown.com
		waybalk.com
		marvavecool.com
		portenteye.com
		realsurprised.com
		drivend.com
		networkmiracle.com
		curiositydo.com
		publicmarvel.com
		astoundroute.com
		marvelblvd.com
		marvelavenue.com
		comicsvogue.com
		caboulevard.com
		bigportent.com
		gateforthebooks.com
		dordrive.com
		phenomenonavenue.com
		imphenomenon.com
		amazedblue.com
		passageco.com
		passagecontour.com
		mesurprised.com
		houroad.com
		daparkway.com
		amazeddigital.com
		realphenomenon.com
		pointmiracle.com
		phenomenonta.com
		awemarket.com
		marvelstreets.com
		pathtutor.com
		geniusie.com
68.232.96.131 1
	ns2.blueine.com 64
		interwhiz.com
		surprisedone.com
		leecomics.com
		placeforthebooks.com
		majorgama.com
		storema.com
		listingsma.com
		starevillage.com
		portentglobal.com
		waybirder.com
		maxportent.com
		pathstimulate.com
		motivatepath.com
		stunnersearch.com
		techgoggle.com
		wayimage.com
		talkeawe.com
		surprisedhost.com
		whizview.com
		gogglestar.com
		routecharm.com
		roadentice.com
		marvave.com
		producway.com
		roompath.com
		roadhigh.com
		passagemouth.com
		sliverpassage.com
		imagestunner.com
		geniusred.com
		sucuriosity.com
		matown.com
		waybalk.com
		marvavecool.com
		portenteye.com
		realsurprised.com
		drivend.com
		networkmiracle.com
		curiositydo.com
		publicmarvel.com
		astoundroute.com
		marvelblvd.com
		marvelavenue.com
		comicsvogue.com
		caboulevard.com
		bigportent.com
		gateforthebooks.com
		dordrive.com
		phenomenonavenue.com
		imphenomenon.com
		amazedblue.com
		passageco.com
		passagecontour.com
		mesurprised.com
		houroad.com
		daparkway.com
		amazeddigital.com
		realphenomenon.com
		pointmiracle.com
		phenomenonta.com
		awemarket.com
		marvelstreets.com
		pathtutor.com
		geniusie.com
68.232.102.162 1
	ns1.demukl.com 64
		zoneprodigy.com
		worldcuriosity.com
		prizedroute.com
		femarvelous.com
		wonderavenue.com
		perkroute.com
		townwonder.com
		gogglest.com
		visionboulevard.com
		whizmap.com
		mercourse.com
		tagoggle.com
		speakparkway.com
		greenmarvave.com
		tarpwhiz.com
		stareblog.com
		keyprodigy.com
		stunnerfly.com
		topstunner.com
		prodigygeo.com
		waxroad.com
		prodigycore.com
		marvaveone.com
		togenius.com
		travelamazed.com
		streetawe.com
		visionstare.com
		evapproach.com
		streetgape.com
		funapproach.com
		drycourse.com
		parkwayrefer.com
		driveobserve.com
		comicsmen.com
		miracleadventure.com
		gazedtown.com
		gategenius.com
		boulevardgo.com
		miracleer.com
		boulevardimage.com
		cosensation.com
		betgazed.com
		drivedebate.com
		beststare.com
		approachlive.com
		coursephoto.com
		courselor.com
		coolamazed.com
		thegazed.com
		forthebooksclub.com
		sensationul.com
		approachom.com
		bowonder.com
		wondercircle.com
		ekicomics.com
		gapeavenue.com
		sensationpoint.com
		estatesgape.com
		gazedtravel.com
		parkwayclarify.com
		sensationcity.com
		aweproperty.com
		curiositycar.com
		beunforseen.com
68.232.102.163 1
	ns2.demukl.com 64
		zoneprodigy.com
		worldcuriosity.com
		prizedroute.com
		femarvelous.com
		wonderavenue.com
		perkroute.com
		townwonder.com
		gogglest.com
		visionboulevard.com
		whizmap.com
		mercourse.com
		tagoggle.com
		speakparkway.com
		greenmarvave.com
		tarpwhiz.com
		stareblog.com
		keyprodigy.com
		stunnerfly.com
		topstunner.com
		prodigygeo.com
		waxroad.com
		prodigycore.com
		marvaveone.com
		togenius.com
		travelamazed.com
		streetawe.com
		visionstare.com
		evapproach.com
		streetgape.com
		funapproach.com
		drycourse.com
		parkwayrefer.com
		driveobserve.com
		comicsmen.com
		miracleadventure.com
		gazedtown.com
		gategenius.com
		boulevardgo.com
		miracleer.com
		boulevardimage.com
		cosensation.com
		betgazed.com
		drivedebate.com
		beststare.com
		approachlive.com
		coursephoto.com
		courselor.com
		coolamazed.com
		thegazed.com
		forthebooksclub.com
		sensationul.com
		approachom.com
		bowonder.com
		wondercircle.com
		ekicomics.com
		gapeavenue.com
		sensationpoint.com
		estatesgape.com
		gazedtravel.com
		parkwayclarify.com
		sensationcity.com
		aweproperty.com
		curiositycar.com
		beunforseen.com
68.232.105.253 1
	ns1.pricpl.com 64
		objectsbuild.com
		storehalo.com
		trovesdeal.com
		columnflux.com
		structuremedley.com
		fortressshape.com
		trovesblue.com
		musstore.com
		fallobjects.com
		objectsgrow.com
		dealbuilding.com
		wowserstore.com
		thinkcolumn.com
		toweringmedley.com
		fortressenroll.com
		tumblecastle.com
		storedi.com
		exceedle.com
		mashfortress.com
		websurpass.com
		refortress.com
		drenchcolumn.com
		medleygo.com
		collectionflight.com
		collectiontop.com
		assortmentcastle.com
		bocollection.com
		cocornucopia.com
		arthighrise.com
		assortmenthouse.com
		seaccumulation.com
		medleyapartment.com
		towerstroves.com
		bihighrise.com
		assortmentbuild.com
		cornucopiabiz.com
		anaccumulation.com
		mediaexceed.com
		towerplethora.com
		plethoragreen.com
		amassmetropolis.com
		columncomfort.com
		castleamass.com
		stacktroves.com
		cityamass.com
		brobjects.com
		cityassortment.com
		exceeddiscover.com
		buildingroar.com
		smorgasbordop.com
		plethoracool.com
		collectionhot.com
		implethora.com
		cornucopiati.com
		mediasmorgasbord.com
		buildingan.com
		alsmorgasbord.com
		smorgasbordweb.com
		castlesnare.com
		buildingred.com
		tallcornucopia.com
		accumulationnet.com
		accumulationcool.com
		amassan.com
68.232.105.254 1
	ns2.pricpl.com 64
		objectsbuild.com
		storehalo.com
		trovesdeal.com
		columnflux.com
		structuremedley.com
		fortressshape.com
		trovesblue.com
		musstore.com
		fallobjects.com
		objectsgrow.com
		dealbuilding.com
		wowserstore.com
		thinkcolumn.com
		toweringmedley.com
		fortressenroll.com
		tumblecastle.com
		storedi.com
		exceedle.com
		mashfortress.com
		websurpass.com
		refortress.com
		drenchcolumn.com
		medleygo.com
		collectionflight.com
		collectiontop.com
		assortmentcastle.com
		bocollection.com
		cocornucopia.com
		arthighrise.com
		assortmenthouse.com
		seaccumulation.com
		medleyapartment.com
		towerstroves.com
		bihighrise.com
		assortmentbuild.com
		cornucopiabiz.com
		anaccumulation.com
		mediaexceed.com
		towerplethora.com
		plethoragreen.com
		amassmetropolis.com
		columncomfort.com
		castleamass.com
		stacktroves.com
		cityamass.com
		brobjects.com
		cityassortment.com
		exceeddiscover.com
		buildingroar.com
		smorgasbordop.com
		plethoracool.com
		collectionhot.com
		implethora.com
		cornucopiati.com
		mediasmorgasbord.com
		buildingan.com
		alsmorgasbord.com
		smorgasbordweb.com
		castlesnare.com
		buildingred.com
		tallcornucopia.com
		accumulationnet.com
		accumulationcool.com
		amassan.com
68.232.111.128 2
	ns2.rackliny.com 64
		surmountsago.com
		newsascend.com
		moreloom.com
		loomcenter.com
		monolithsales.com
		findskyscraper.com
		steeplemake.com
		selllookout.com
		steeplecloud.com
		openmonolith.com
		loommulti.com
		hosteeple.com
		indominate.com
		sulookover.com
		warddominate.com
		pillarcity.com
		surmountfeather.com
		surmountdigital.com
		spireguide.com
		turretlist.com
		spirealpha.com
		monolithcare.com
		getpillar.com
		mindbelfry.com
		lookovergroup.com
		lookoutace.com
		hyperlookout.com
		lookoutbrand.com
		highrisenew.com
		dominatery.com
		skyscrapershop.com
		mediaascend.com
		virtualspire.com
		popspire.com
		turrettrade.com
		lookoverum.com
		highrisetop.com
		smartbeabove.com
		goldmonolith.com
		skyscrapergreen.com
		pointpillar.com
		pillarshop.com
		turretus.com
		surmountia.com
		kiturret.com
		gaskyscraper.com
		surpassfusion.com
		belfrybox.com
		hallloom.com
		belfryget.com
		ascendeasy.com
		findbelfry.com
		towerstocks.com
		flyassortment.com
		vasurpass.com
		dividominate.com
		cardsteeple.com
		plethorank.com
		bizlookover.com
		coolbeabove.com
		beaboveblue.com
		beabovetech.com
		ascendlist.com
		surpasset.com
	ns1.rackliny.com 64
		surmountsago.com
		newsascend.com
		moreloom.com
		loomcenter.com
		monolithsales.com
		findskyscraper.com
		steeplemake.com
		selllookout.com
		steeplecloud.com
		openmonolith.com
		loommulti.com
		hosteeple.com
		indominate.com
		sulookover.com
		warddominate.com
		pillarcity.com
		surmountfeather.com
		surmountdigital.com
		spireguide.com
		turretlist.com
		spirealpha.com
		monolithcare.com
		getpillar.com
		mindbelfry.com
		lookovergroup.com
		lookoutace.com
		hyperlookout.com
		lookoutbrand.com
		highrisenew.com
		dominatery.com
		skyscrapershop.com
		mediaascend.com
		virtualspire.com
		popspire.com
		turrettrade.com
		lookoverum.com
		highrisetop.com
		smartbeabove.com
		goldmonolith.com
		skyscrapergreen.com
		pointpillar.com
		pillarshop.com
		turretus.com
		surmountia.com
		kiturret.com
		gaskyscraper.com
		surpassfusion.com
		belfrybox.com
		hallloom.com
		belfryget.com
		ascendeasy.com
		findbelfry.com
		towerstocks.com
		flyassortment.com
		vasurpass.com
		dividominate.com
		cardsteeple.com
		plethorank.com
		bizlookover.com
		coolbeabove.com
		beaboveblue.com
		beabovetech.com
		ascendlist.com
		surpasset.com
70.32.3.2 1
	ns1.candyadvbid.com 16
		essaybounty.com
		marginssave.com
		offergetupdate.com
		fendbig.com
		simplecyto.com
		savingsmemo.com
		broadgains.com
		ewebexpects.com
		savegreatest.com
		tryfindover.com
		choiceswide.com
		choiceezz.com
		properpeers.com
		postfinds.com
		webhomeaccords.com
		tryezzd.com
70.32.3.3 1
	ns2.candyadvbid.com 16
		essaybounty.com
		marginssave.com
		offergetupdate.com
		fendbig.com
		simplecyto.com
		savingsmemo.com
		broadgains.com
		ewebexpects.com
		savegreatest.com
		tryfindover.com
		choiceswide.com
		choiceezz.com
		properpeers.com
		postfinds.com
		webhomeaccords.com
		tryezzd.com
71.5.84.5 1
	ns1.rsndns1.com 75
		312tech.net
		publicsmokingsurveys.com
		directshoppersavings.com
		specialoffercentral.com
		restaurantdiscountsdirect.com
		hotelectronicssavings.com
		discountholidayshoppers.com
		yourparentingresources.com
		designersavingsdirect.com
		incredibleholidaysavings.com
		hotshoppingnetwork.com
		restaurantreviewpanel.com
		theremodelnetwork.com
		ezgamegear.com
		travelguidesavings.com
		consumeropinionrewards.com
		shoppersreviewnetwork.com
		econsumerpanel.com
		destinationsurveys.com
		hdtvsaver.com
		usareviewpanel.com
		consumerreviewnetwork.com
		americanreviewpanel.com
		mygiftcardcentral.com
		chefdiscountcookware.com
		usaresearchpanel.com
		wirelesstechsavings.com
		eresearchpanel.com
		thelaptopsaver.com
		holidaysavingsguide.com
		eshoppersavings.com
		nationalmagazinereview.com
		desktopreviewpanel.com
		cooklikepros.com
		todayshealthyliving.com
		sportsworldsavings.com
		skincaresavingsdirect.com
		tvopinionpolls.com
		parentingneedsdirect.com
		opinionresearchpanel.com
		americansportspolls.com
		gamer-hookups.com
		hotcameratechnology.com
		handbagreviewpanel.com
		hdreviewpanel.com
		rsndns3.com
		yourgiftcardsdirect.com
		egamerworld.com
		shopperdealsdirect.com
		rsndns1.com
		discountshoppercentral.com
		laptopreviewpanel.com
		hdtvdirectsavings.com
		surveyreviewpanel.com
		evacationsonline.com
		esurveypanel.com
		magazinereviewpanel.com
		homeremodelnetwork.com
		todayshottestgadgets.com
		rsndns2.com
		elaptopsaver.com
		yourlaptopsavings.com
		aqclick.com
		gadgetreviewpanel.com
		newelectronicssavings.com
		sportinggoodssavings.com
		retailreviewpanel.com
		thinnest-laptop.com
		greenlivingrewards.com
		camerareviewpanel.com
		topdesignersavings.com
		eshoppingpanel.com
		usaopinionpanel.com
		hdtv-savings.com
		americanopinionpanel.com
71.5.84.218 1
	ns1.shotlity.com 21
		spottedinpublic.com
		topupdateroutine.com
		theoccasionlist.com
		regularfindevents.com
		getoccasiondata.com
		occasionblog.com
		routinegroupevents.com
		inforegular.com
		jobroutinenews.com
		publicprobe.com
		dealregular.com
		constantlyaccess.com
		publiciknow.com
		buyregular.com
		commonbestupdate.com
		routineblue.com
		explorethepublic.com
		constantlyknow.com
		buycommon.com
		contactconstantly.com
		commontopdeals.com
71.5.84.219 1
	ns2.shotlity.com 21
		spottedinpublic.com
		topupdateroutine.com
		theoccasionlist.com
		regularfindevents.com
		getoccasiondata.com
		occasionblog.com
		routinegroupevents.com
		inforegular.com
		jobroutinenews.com
		publicprobe.com
		dealregular.com
		constantlyaccess.com
		publiciknow.com
		buyregular.com
		commonbestupdate.com
		routineblue.com
		explorethepublic.com
		constantlyknow.com
		buycommon.com
		contactconstantly.com
		commontopdeals.com
96.45.48.10 2
	ns2.optimedianews.com 1
		optimedianews.com
	ns1.optimedianews.com 1
		optimedianews.com
96.45.49.2 1
	ns1.cacilot.com 28
		jeaenlighten.com
		flaemphasized.com
		tryilluminate.com
		expressedsocial.com
		clientmy.com
		bakishoppers.com
		mixpatron.com
		opeconsumer.com
		belacquaint.com
		informedag.com
		purchasernama.com
		clienttrain.com
		goobtainer.com
		investorsda.com
		illuminateish.com
		litpurchaser.com
		emphasizedia.com
		favoinformed.com
		familiarizesy.com
		shoppersot.com
		pofamiliarize.com
		inbuyers.com
		seriinvestors.com
		epiacquaint.com
		briefedbeta.com
		enlightenirsh.com
		consumerua.com
		buyerstutor.com
96.45.49.3 1
	ns2.cacilot.com 28
		jeaenlighten.com
		flaemphasized.com
		tryilluminate.com
		expressedsocial.com
		clientmy.com
		bakishoppers.com
		mixpatron.com
		opeconsumer.com
		belacquaint.com
		informedag.com
		purchasernama.com
		clienttrain.com
		goobtainer.com
		investorsda.com
		illuminateish.com
		litpurchaser.com
		emphasizedia.com
		favoinformed.com
		familiarizesy.com
		shoppersot.com
		pofamiliarize.com
		inbuyers.com
		seriinvestors.com
		epiacquaint.com
		briefedbeta.com
		enlightenirsh.com
		consumerua.com
		buyerstutor.com
96.45.50.253 1
	ns1.pigbont.com 30
		consumerbbin.com
		clientneo.com
		illuminatemost.com
		expressedfuse.com
		tenacquaint.com
		ornipurchaser.com
		purchasernity.com
		zetabriefed.com
		shoppersotla.com
		linenlighten.com
		testbuyers.com
		jilinformed.com
		consumerto.com
		expressedloop.com
		acquaintly.com
		patrononag.com
		sadilluminate.com
		greemphasized.com
		flesshoppers.com
		reakpatron.com
		pointbuyers.com
		onafamiliarize.com
		emphasizedotic.com
		enlightenly.com
		informedbtly.com
		investorslage.com
		baconsumers.com
		typinvestors.com
		focusclient.com
		azuacquaint.com
96.45.50.254 1
	ns2.pigbont.com 30
		consumerbbin.com
		clientneo.com
		illuminatemost.com
		expressedfuse.com
		tenacquaint.com
		ornipurchaser.com
		purchasernity.com
		zetabriefed.com
		shoppersotla.com
		linenlighten.com
		testbuyers.com
		jilinformed.com
		consumerto.com
		expressedloop.com
		acquaintly.com
		patrononag.com
		sadilluminate.com
		greemphasized.com
		flesshoppers.com
		reakpatron.com
		pointbuyers.com
		onafamiliarize.com
		emphasizedotic.com
		enlightenly.com
		informedbtly.com
		investorslage.com
		baconsumers.com
		typinvestors.com
		focusclient.com
		azuacquaint.com
96.45.51.2 1
	ns1.scrapba.com 28
		buyersgo.com
		adoracquaint.com
		acquaintrate.com
		businvestors.com
		expresseds.com
		obtainert.com
		consumerinci.com
		lizzinformed.com
		laceemphasized.com
		informedid.com
		lakpurchaser.com
		clientbest.com
		enlightenstlo.com
		circleexpressed.com
		scifamiliarize.com
		rainenlighten.com
		instilbuyers.com
		purchaserbyrn.com
		shoppersrope.com
		deltabriefed.com
		investorspony.com
		illuminateycat.com
		patronassi.com
		celilluminate.com
		vegconsumer.com
		plshoppers.com
		emphasizedsp.com
		dayclient.com
96.45.51.3 1
	ns2.scrapba.com 28
		buyersgo.com
		adoracquaint.com
		acquaintrate.com
		businvestors.com
		expresseds.com
		obtainert.com
		consumerinci.com
		lizzinformed.com
		laceemphasized.com
		informedid.com
		lakpurchaser.com
		clientbest.com
		enlightenstlo.com
		circleexpressed.com
		scifamiliarize.com
		rainenlighten.com
		instilbuyers.com
		purchaserbyrn.com
		shoppersrope.com
		deltabriefed.com
		investorspony.com
		illuminateycat.com
		patronassi.com
		celilluminate.com
		vegconsumer.com
		plshoppers.com
		emphasizedsp.com
		dayclient.com
96.45.52.2 1
	ns1.bourer.com 32
		equalcost.com
		acquireclick.com
		toseacquire.com
		assetublery.com
		matspend.com
		marketpricesy.com
		eratesky.com
		ecloggmoney.com
		dealimage.com
		assetpixel.com
		browsectord.com
		worthtop.com
		paylocktail.com
		pinvalue.com
		procureloan.com
		clotdeal.com
		spendinfo.com
		costbuyip.com
		enteramoney.com
		solutionsinvest.com
		listfinancial.com
		largdeal.com
		hubolderpay.com
		youobtain.com
		spendro.com
		solicaleget.com
		etradeamount.com
		propertysor.com
		topibargain.com
		sellarserom.com
		purchasefair.com
		costbuylo.com
96.45.52.3 1
	ns2.bourer.com 32
		equalcost.com
		acquireclick.com
		toseacquire.com
		assetublery.com
		matspend.com
		marketpricesy.com
		eratesky.com
		ecloggmoney.com
		dealimage.com
		assetpixel.com
		browsectord.com
		worthtop.com
		paylocktail.com
		pinvalue.com
		procureloan.com
		clotdeal.com
		spendinfo.com
		costbuyip.com
		enteramoney.com
		solutionsinvest.com
		listfinancial.com
		largdeal.com
		hubolderpay.com
		youobtain.com
		spendro.com
		solicaleget.com
		etradeamount.com
		propertysor.com
		topibargain.com
		sellarserom.com
		purchasefair.com
		costbuylo.com
96.45.53.253 1
	ns1.bowgaw.com 32
		findbrowse.com
		worthnew.com
		equalcoston.com
		financialte.com
		evaluatsale.com
		eobtainclick.com
		procurender.com
		realiinvest.com
		compareprofit.com
		backprocure.com
		driveinvest.com
		beangetsale.com
		crosbargain.com
		vingbinsale.com
		rateslot.com
		esalefinancial.com
		aimedbrowse.com
		procuretest.com
		ratedron.com
		oncostbuy.com
		obtaingroup.com
		minentudeal.com
		marketpriceer.com
		monoprocure.com
		ereviewsprofit.com
		esourcebargain.com
		worthbuyfi.com
		enetworkbrowse.com
		edealsyou.com
		browsevision.com
		specticsale.com
		soupcatdeal.com
96.45.53.254 1
	ns2.bowgaw.com 32
		findbrowse.com
		worthnew.com
		equalcoston.com
		financialte.com
		evaluatsale.com
		eobtainclick.com
		procurender.com
		realiinvest.com
		compareprofit.com
		backprocure.com
		driveinvest.com
		beangetsale.com
		crosbargain.com
		vingbinsale.com
		rateslot.com
		esalefinancial.com
		aimedbrowse.com
		procuretest.com
		ratedron.com
		oncostbuy.com
		obtaingroup.com
		minentudeal.com
		marketpriceer.com
		monoprocure.com
		ereviewsprofit.com
		esourcebargain.com
		worthbuyfi.com
		enetworkbrowse.com
		edealsyou.com
		browsevision.com
		specticsale.com
		soupcatdeal.com
96.45.54.2 1
	ns1.disju.com 32
		valueli.com
		blogspend.com
		tempbuy.com
		espendstore.com
		valuestrength.com
		buyerse.com
		dealbars.com
		rateci.com
		eshopamount.com
		equalcostbe.com
		alshopworth.com
		visionprices.com
		solutionsprice.com
		shoppingap.com
		buyerme.com
		dealsidea.com
		amountbook.com
		myodeals.com
		pricesfly.com
		pricesdata.com
		epricestrade.com
		acquireally.com
		estorepo.com
		equalth.com
		ratepate.com
		figuval.com
		estoredw.com
		efindspend.com
		solutionsspend.com
		pointprices.com
		zartdeal.com
		emartvalue.com
96.45.54.3 1
	ns2.disju.com 32
		valueli.com
		blogspend.com
		tempbuy.com
		espendstore.com
		valuestrength.com
		buyerse.com
		dealbars.com
		rateci.com
		eshopamount.com
		equalcostbe.com
		alshopworth.com
		visionprices.com
		solutionsprice.com
		shoppingap.com
		buyerme.com
		dealsidea.com
		amountbook.com
		myodeals.com
		pricesfly.com
		pricesdata.com
		epricestrade.com
		acquireally.com
		estorepo.com
		equalth.com
		ratepate.com
		figuval.com
		estoredw.com
		efindspend.com
		solutionsspend.com
		pointprices.com
		zartdeal.com
		emartvalue.com
96.45.55.253 1
	ns1.benzand.com 32
		checkerhome.com
		producttop.com
		reviewth.com
		inspectto.com
		coolobserver.com
		coinquire.com
		overseenew.com
		merchbest.com
		looksgrow.com
		findcreation.com
		examineco.com
		finddig.com
		goodsdata.com
		lookssearch.com
		searchure.com
		grouplooks.com
		marketinspect.com
		inquireeasy.com
		merchnews.com
		exploreye.com
		prospectbuy.com
		probeidea.com
		observerup.com
		merchandisefind.com
		seekva.com
		seekcomputer.com
		mainvention.com
		hooversee.com
		brandshosting.com
		probemy.com
		objecttrade.com
		delvecode.com
96.45.55.254 1
	ns2.benzand.com 32
		checkerhome.com
		producttop.com
		reviewth.com
		inspectto.com
		coolobserver.com
		coinquire.com
		overseenew.com
		merchbest.com
		looksgrow.com
		findcreation.com
		examineco.com
		finddig.com
		goodsdata.com
		lookssearch.com
		searchure.com
		grouplooks.com
		marketinspect.com
		inquireeasy.com
		merchnews.com
		exploreye.com
		prospectbuy.com
		probeidea.com
		observerup.com
		merchandisefind.com
		seekva.com
		seekcomputer.com
		mainvention.com
		hooversee.com
		brandshosting.com
		probemy.com
		objecttrade.com
		delvecode.com
96.45.56.253 1
	ns1.matentof.com 32
		solutionsreviews.com
		propertyproduct.com
		warebusiness.com
		merchantbrand.com
		purpinformed.com
		emphasizeddo.com
		synilluminate.com
		expressedteam.com
		avoemphasized.com
		consumerwa.com
		enlightenhree.com
		ellfamiliarize.com
		obtainerby.com
		clienthigh.com
		briefeds.com
		investorsck.com
		grapurchaser.com
		purchaserba.com
		clientadvise.com
		buyersez.com
		nooinvestors.com
		mirconsumer.com
		illuminateor.com
		shoppersga.com
		coordinatebuyers.com
		ardoinformed.com
		coacquaint.com
		ampushoppers.com
		patronvetz.com
		legitimizeling.com
		bollenlighten.com
		airpatron.com
96.45.56.254 1
	ns2.matentof.com 32
		solutionsreviews.com
		propertyproduct.com
		warebusiness.com
		merchantbrand.com
		purpinformed.com
		emphasizeddo.com
		synilluminate.com
		expressedteam.com
		avoemphasized.com
		consumerwa.com
		enlightenhree.com
		ellfamiliarize.com
		obtainerby.com
		clienthigh.com
		briefeds.com
		investorsck.com
		grapurchaser.com
		purchaserba.com
		clientadvise.com
		buyersez.com
		nooinvestors.com
		mirconsumer.com
		illuminateor.com
		shoppersga.com
		coordinatebuyers.com
		ardoinformed.com
		coacquaint.com
		ampushoppers.com
		patronvetz.com
		legitimizeling.com
		bollenlighten.com
		airpatron.com
96.45.57.253 1
	ns1.produum.com 32
		inquirecar.com
		boxmerchandise.com
		tradeprobe.com
		carpeseek.com
		worklooks.com
		leaddelve.com
		solutionscreation.com
		coolexplore.com
		pointinvention.com
		canvasscar.com
		crecheck.com
		alproduct.com
		lookedtin.com
		inventioner.com
		brandsfind.com
		searchesnew.com
		smartcanvass.com
		overseeri.com
		marketingdig.com
		findchecker.com
		doinspect.com
		goodswin.com
		examinedigital.com
		bizinquire.com
		storeoversee.com
		wareget.com
		marketexamine.com
		wareviews.com
		ecityinspect.com
		diggingsource.com
		observerinfo.com
		creationsea.com
96.45.57.254 1
	ns2.produum.com 32
		inquirecar.com
		boxmerchandise.com
		tradeprobe.com
		carpeseek.com
		worklooks.com
		leaddelve.com
		solutionscreation.com
		coolexplore.com
		pointinvention.com
		canvasscar.com
		crecheck.com
		alproduct.com
		lookedtin.com
		inventioner.com
		brandsfind.com
		searchesnew.com
		smartcanvass.com
		overseeri.com
		marketingdig.com
		findchecker.com
		doinspect.com
		goodswin.com
		examinedigital.com
		bizinquire.com
		storeoversee.com
		wareget.com
		marketexamine.com
		wareviews.com
		ecityinspect.com
		diggingsource.com
		observerinfo.com
		creationsea.com
96.45.58.2 1
	ns1.chedic.com 32
		youobserver.com
		searchespoint.com
		delveface.com
		exploreth.com
		inspectdeal.com
		inventionclick.com
		brandlo.com
		synthiware.com
		homeinquire.com
		topexplore.com
		creationsnews.com
		inspectmarket.com
		goodstrio.com
		examinebest.com
		delvesource.com
		ducketware.com
		prospectnew.com
		storedig.com
		titegoods.com
		ofmerchandise.com
		overseegames.com
		mercheway.com
		listobject.com
		looksbuy.com
		edatalooks.com
		easycanvass.com
		commerch.com
		storeexamine.com
		searchnes.com
		eprobespace.com
		productry.com
		brandne.com
96.45.58.3 1
	ns2.chedic.com 32
		youobserver.com
		searchespoint.com
		delveface.com
		exploreth.com
		inspectdeal.com
		inventionclick.com
		brandlo.com
		synthiware.com
		homeinquire.com
		topexplore.com
		creationsnews.com
		inspectmarket.com
		goodstrio.com
		examinebest.com
		delvesource.com
		ducketware.com
		prospectnew.com
		storedig.com
		titegoods.com
		ofmerchandise.com
		overseegames.com
		mercheway.com
		listobject.com
		looksbuy.com
		edatalooks.com
		easycanvass.com
		commerch.com
		storeexamine.com
		searchnes.com
		eprobespace.com
		productry.com
		brandne.com
96.45.59.253 1
	ns1.lagenala.com 32
		sourcerelease.com
		photoheadline.com
		oflocalnews.com
		aprelease.com
		audlocal.com
		refreshhot.com
		accountfun.com
		toptelecast.com
		bulletinbiz.com
		datacourso.com
		informstore.com
		dotelevise.com
		pureupdate.com
		newstorydata.com
		biztrendsot.com
		castacable.com
		fashionstylic.com
		commvo.com
		wifrontpage.com
		currenties.com
		instapinfo.com
		reportsmedia.com
		headlinenetwork.com
		refreshsource.com
		weatherty.com
		qusports.com
		breakingcity.com
		technotalesap.com
		sitopics.com
		broadcastur.com
		datemboy.com
		dataannounce.com
96.45.59.254 1
	ns2.lagenala.com 32
		sourcerelease.com
		photoheadline.com
		oflocalnews.com
		aprelease.com
		audlocal.com
		refreshhot.com
		accountfun.com
		toptelecast.com
		bulletinbiz.com
		datacourso.com
		informstore.com
		dotelevise.com
		pureupdate.com
		newstorydata.com
		biztrendsot.com
		castacable.com
		fashionstylic.com
		commvo.com
		wifrontpage.com
		currenties.com
		instapinfo.com
		reportsmedia.com
		headlinenetwork.com
		refreshsource.com
		weatherty.com
		qusports.com
		breakingcity.com
		technotalesap.com
		sitopics.com
		broadcastur.com
		datemboy.com
		dataannounce.com
96.45.60.253 1
	ns1.siblacho.com 30
		releaseat.com
		infoheadline.com
		releasespace.com
		currentfind.com
		cityacquire.com
		biztrendsta.com
		edatecreative.com
		rabroadcast.com
		wininformation.com
		bulletinet.com
		blognewstory.com
		televisecity.com
		egroupcable.com
		accountine.com
		accountvideo.com
		namessage.com
		discoveryet.com
		datazzines.com
		breakingclick.com
		weatherto.com
		announcefind.com
		herefresh.com
		updaterpal.com
		satelecast.com
		fashionstylab.com
		sportsge.com
		infovetest.com
		reportsvision.com
		frontpagelife.com
		cahealthtopics.com
96.45.60.254 1
	ns2.siblacho.com 30
		releaseat.com
		infoheadline.com
		releasespace.com
		currentfind.com
		cityacquire.com
		biztrendsta.com
		edatecreative.com
		rabroadcast.com
		wininformation.com
		bulletinet.com
		blognewstory.com
		televisecity.com
		egroupcable.com
		accountine.com
		accountvideo.com
		namessage.com
		discoveryet.com
		datazzines.com
		breakingclick.com
		weatherto.com
		announcefind.com
		herefresh.com
		updaterpal.com
		satelecast.com
		fashionstylab.com
		sportsge.com
		infovetest.com
		reportsvision.com
		frontpagelife.com
		cahealthtopics.com
96.45.61.253 1
	ns1.butmakea.com 30
		informationel.com
		sourcecurrent.com
		lifashionstyl.com
		healthtopicsbe.com
		updatedame.com
		getnewstory.com
		epicreport.com
		getbulletin.com
		breakinglist.com
		blogacquire.com
		bulletinclick.com
		broadcasteasy.com
		telecastbest.com
		sitecable.com
		reportsdata.com
		digitalannounce.com
		ideabroadcast.com
		comrelease.com
		refreshow.com
		weatheray.com
		newsstag.com
		consdate.com
		accountowe.com
		mailcable.com
		headlinebiz.com
		pointdiscovery.com
		sportsnd.com
		sourcemessage.com
		commnew.com
		mediaacquire.com
96.45.61.254 1
	ns2.butmakea.com 30
		informationel.com
		sourcecurrent.com
		lifashionstyl.com
		healthtopicsbe.com
		updatedame.com
		getnewstory.com
		epicreport.com
		getbulletin.com
		breakinglist.com
		blogacquire.com
		bulletinclick.com
		broadcasteasy.com
		telecastbest.com
		sitecable.com
		reportsdata.com
		digitalannounce.com
		ideabroadcast.com
		comrelease.com
		refreshow.com
		weatheray.com
		newsstag.com
		consdate.com
		accountowe.com
		mailcable.com
		headlinebiz.com
		pointdiscovery.com
		sportsnd.com
		sourcemessage.com
		commnew.com
		mediaacquire.com
205.177.88.7 1
	ns1.cbgalrdns.com 14
		anatern.com
		audrific.com
		meristh.com
		pignumb.com
		luregi.com
		pertnik.com
		homeopinide.com
		assespo.com
		bimbora.com
		deflega.com
		voceci.com
		ballered.com
		helmiter.com
		chilator.com
205.177.88.8 1
	ns2.cbgalrdns.com 14
		anatern.com
		audrific.com
		meristh.com
		pignumb.com
		luregi.com
		pertnik.com
		homeopinide.com
		assespo.com
		bimbora.com
		deflega.com
		voceci.com
		ballered.com
		helmiter.com
		chilator.com
205.177.88.29 1
	ns1.cnsbrgalrt.com 7
		interretail.com
		frankybuilding.com
		fruityflowerseat.com
		heavenessencefl.com
		ballooncreativ.com
		purpletradingpost.com
		thebrushartsupp.com
205.177.88.30 1
	ns2.cnsbrgalrt.com 7
		interretail.com
		frankybuilding.com
		fruityflowerseat.com
		heavenessencefl.com
		ballooncreativ.com
		purpletradingpost.com
		thebrushartsupp.com
206.173.133.144 1
	ns1.helpimp.com 21
		spotfreshaffairs.com
		traydailyupdate.com
		sightandnotice.com
		frequentblog.com
		infofrequent.com
		knowcurrentevent.com
		overviewdaily.com
		overviewfresh.com
		navigatedealsdaily.com
		overviewcurrentnews.com
		knownotice.com
		freshknow.com
		coolfrequent.com
		currentsightdeals.com
		circledaily.com
		currentnewsbot.com
		answerfresh.com
		enoticeportal.com
		frequentgreenevents.com
		freshstormer.com
		noticeofcontact.com
206.173.133.145 1
	ns2.helpimp.com 21
		spotfreshaffairs.com
		traydailyupdate.com
		sightandnotice.com
		frequentblog.com
		infofrequent.com
		knowcurrentevent.com
		overviewdaily.com
		overviewfresh.com
		navigatedealsdaily.com
		overviewcurrentnews.com
		knownotice.com
		freshknow.com
		coolfrequent.com
		currentsightdeals.com
		circledaily.com
		currentnewsbot.com
		answerfresh.com
		enoticeportal.com
		frequentgreenevents.com
		freshstormer.com
		noticeofcontact.com
206.173.134.4 1
	ns1.csadns.com 1
		couponsaversalert.com
206.173.134.5 1
	ns2.csadns.com 1
		couponsaversalert.com
206.173.134.6 1
	ns3.csadns.com 1
		couponsaversalert.com


AS1632 domains (snowshoe):
-----------------------------
8.24.115.2 1
	ns1.blaketo.com 56
		updateoffersget.com
		dealsyn.com
		greatvaluessbw.com
		finddailyoffers.com
		dailiessaltwat.com
		announcementsdeal.com
		affildailiesdeal.com
		promosbluesea.com
		oceanpartnershipnews.com
		offersaveeasy.com
		oceansynoffers.com
		topamount.com
		remarkoffers.com
		realdealshighwat.com
		upgradedeepsea.com
		partnershipswat.com
		offersnowcool.com
		topsavingsfind.com
		specialsbest.com
		solutionsspecials.com
		seawaybenefits.com
		seasynupdatedbest.com
		osannoucement.com
		minddaily.com
		ideaspecial.com
		advantagenowfind.com
		greatofferhighseas.com
		syndaily.com
		alliancespecialbest.com
		bestdailyadvantage.com
		valassets.com
		proposalos.com
		specialssource.com
		smartupdateadvantage.com
		currentoceanspec.com
		alliancesblue.com
		synoceanproposal.com
		synintroduce.com
		updatedeal.com
		updatesynocean.com
		antlantgreatestspec.com
		greatwatersbuy.com
		savedealings.com
		bluewaveupdate.com
		advantagesalliance.com
		adealsbest.com
		updateadvantagenew.com
		realossaving.com
		syndicationbest.com
		realdealbysynd.com
		obtainwater.com
		deliverpromosatlant.com
		dailynewssolutions.com
		oceanannouncementslist.com
		maildailynews.com
		announcmentpartner.com
8.24.115.3 1
	ns2.blaketo.com 56
		updateoffersget.com
		dealsyn.com
		greatvaluessbw.com
		finddailyoffers.com
		dailiessaltwat.com
		announcementsdeal.com
		affildailiesdeal.com
		promosbluesea.com
		oceanpartnershipnews.com
		offersaveeasy.com
		oceansynoffers.com
		topamount.com
		remarkoffers.com
		realdealshighwat.com
		upgradedeepsea.com
		partnershipswat.com
		offersnowcool.com
		topsavingsfind.com
		specialsbest.com
		solutionsspecials.com
		seawaybenefits.com
		seasynupdatedbest.com
		osannoucement.com
		minddaily.com
		ideaspecial.com
		advantagenowfind.com
		greatofferhighseas.com
		syndaily.com
		alliancespecialbest.com
		bestdailyadvantage.com
		valassets.com
		proposalos.com
		specialssource.com
		smartupdateadvantage.com
		currentoceanspec.com
		alliancesblue.com
		synoceanproposal.com
		synintroduce.com
		updatedeal.com
		updatesynocean.com
		antlantgreatestspec.com
		greatwatersbuy.com
		savedealings.com
		bluewaveupdate.com
		advantagesalliance.com
		adealsbest.com
		updateadvantagenew.com
		realossaving.com
		syndicationbest.com
		realdealbysynd.com
		obtainwater.com
		deliverpromosatlant.com
		dailynewssolutions.com
		oceanannouncementslist.com
		maildailynews.com
		announcmentpartner.com
8.24.126.253 1
	ns1.turneed.com 56
		synoceanspecials.com
		gainadvantagesosn.com
		announcementssaltypond.com
		synupdatesget.com
		specialsupdate.com
		specialsdealcoalition.com
		offersbestbluecoalition.com
		greatwatersdeal.com
		deepseagive.com
		getnewspecialblue.com
		dailyspecialsbestoc.com
		ocspecialstopsyn.com
		finestnewspacific.com
		coolupdated.com
		blueseaspecials.com
		topoceanblueoffer.com
		oceanlistoffer.com
		syndicationdeal.com
		synoceandeals.com
		offeringocsyn.com
		ocsyndeal.com
		oceanicinfo.com
		ocsynnotification.com
		coolupdateoffers.com
		advantagessup.com
		specdiscounts.com
		promosbay.com
		offerssyn.com
		syndicationlo.com
		oceanicbest.com
		promopacific.com
		findofferings.com
		seaincentive.com
		webnewsave.com
		orewardtop.com
		wondadvantages.com
		takeadvantagebest.com
		savingsso.com
		offersop.com
		newadvantagesblue.com
		marinesworks.com
		fineopportunitydw.com
		deeppondsolid.com
		benefitgains.com
		arcticsmart.com
		topdealos.com
		savingsnew.com
		newspecialinfo.com
		bestofferget.com
		supbenefits.com
		hotofferingblwat.com
		getpromosnow.com
		aofferfind.com
		dealnotices.com
		dealdeepwater.com
		activeaccords.com
8.24.126.254 1
	ns2.turneed.com 56
		synoceanspecials.com
		gainadvantagesosn.com
		announcementssaltypond.com
		synupdatesget.com
		specialsupdate.com
		specialsdealcoalition.com
		offersbestbluecoalition.com
		greatwatersdeal.com
		deepseagive.com
		getnewspecialblue.com
		dailyspecialsbestoc.com
		ocspecialstopsyn.com
		finestnewspacific.com
		coolupdated.com
		blueseaspecials.com
		topoceanblueoffer.com
		oceanlistoffer.com
		syndicationdeal.com
		synoceandeals.com
		offeringocsyn.com
		ocsyndeal.com
		oceanicinfo.com
		ocsynnotification.com
		coolupdateoffers.com
		advantagessup.com
		specdiscounts.com
		promosbay.com
		offerssyn.com
		syndicationlo.com
		oceanicbest.com
		promopacific.com
		findofferings.com
		seaincentive.com
		webnewsave.com
		orewardtop.com
		wondadvantages.com
		takeadvantagebest.com
		savingsso.com
		offersop.com
		newadvantagesblue.com
		marinesworks.com
		fineopportunitydw.com
		deeppondsolid.com
		benefitgains.com
		arcticsmart.com
		topdealos.com
		savingsnew.com
		newspecialinfo.com
		bestofferget.com
		supbenefits.com
		hotofferingblwat.com
		getpromosnow.com
		aofferfind.com
		dealnotices.com
		dealdeepwater.com
		activeaccords.com
96.45.147.253 1
	ns1.rawede.com 15
		insideal.com
		tipsstreet.com
		classbargains.com
		emmdeals.com
		workoutvac.com
		condenderdirect.com
		delightscore.com
		actrect.com
		rankpromo.com
		dealechelon.com
		bothyge.com
		condeal.com
		aelarysa.com
		overelon.com
		directtons.com
96.45.147.254 1
	ns2.rawede.com 15
		insideal.com
		tipsstreet.com
		classbargains.com
		emmdeals.com
		workoutvac.com
		condenderdirect.com
		delightscore.com
		actrect.com
		rankpromo.com
		dealechelon.com
		bothyge.com
		condeal.com
		aelarysa.com
		overelon.com
		directtons.com
96.45.150.2 1
	ns1.kingwde.com 18
		exubere.com
		notemill.com
		distinctstature.com
		alphaalign.com
		typeolif.com
		profusesizeup.com
		downforgrown.com
		pledgerank.com
		putroot.com
		fileteem.com
		castefile.com
		stringtron.com
		linesplaceweb.com
		denseflagrant.com
		seriesstratum.com
		rowtton.com
		instantlush.com
		classsort.com
96.45.150.3 1
	ns2.kingwde.com 18
		exubere.com
		notemill.com
		distinctstature.com
		alphaalign.com
		typeolif.com
		profusesizeup.com
		downforgrown.com
		pledgerank.com
		putroot.com
		fileteem.com
		castefile.com
		stringtron.com
		linesplaceweb.com
		denseflagrant.com
		seriesstratum.com
		rowtton.com
		instantlush.com
		classsort.com
96.45.153.253 1
	ns1.cratshaf.com 19
		freshplenty.com
		localnetter.com
		tabplace.com
		buyrender.com
		apartprolific.com
		bamimart.com
		rankwebwner.com
		opentons.com
		miniesale.com
		cachetrow.com
		firstesteem.com
		webnder.com
		netmartreviews.com
		sorttotal.com
		capitalesteem.com
		buttonput.com
		buyextent.com
		miniaturecool.com
		castedata.com
96.45.153.254 1
	ns2.cratshaf.com 19
		freshplenty.com
		localnetter.com
		tabplace.com
		buyrender.com
		apartprolific.com
		bamimart.com
		rankwebwner.com
		opentons.com
		miniesale.com
		cachetrow.com
		firstesteem.com
		webnder.com
		netmartreviews.com
		sorttotal.com
		capitalesteem.com
		buttonput.com
		buyextent.com
		miniaturecool.com
		castedata.com
96.45.157.38 1
	ns1.moieve.com 17
		exuberentstring.com
		tonsinside.com
		ranksave.com
		prorankweb.com
		lavishpeg.com
		actdelight.com
		glaringorder.com
		flagrantnote.com
		clearstanding.com
		astrobarter.com
		rankwebaret.com
		subbituminous.com
		unzited.com
		goodiesoffer.com
		offerproposed.com
		rwdechelons.com
		netobtain.com
96.45.157.39 1
	ns2.moieve.com 17
		exuberentstring.com
		tonsinside.com
		ranksave.com
		prorankweb.com
		lavishpeg.com
		actdelight.com
		glaringorder.com
		flagrantnote.com
		clearstanding.com
		astrobarter.com
		rankwebaret.com
		subbituminous.com
		unzited.com
		goodiesoffer.com
		offerproposed.com
		rwdechelons.com
		netobtain.com
205.186.210.186 1
	ns1.wheati.com 96
		turncommunity.com
		implyblue.com
		istarllc.com
		ecooperscompany.com
		graygraphicsonline.com
		personalizeshapesco.com
		oceaniqueshop.com
		observeblue.com
		hypoarea.com
		districtreviews.com
		districtidea.com
		wardcity.com
		urgeprecinct.com
		redallude.com
		vicinitydirect.com
		regionhot.com
		loadvert.com
		bucommunity.com
		chadvert.com
		gardenofedenconsulting.com
		hivelocities.com
		sectionbiz.com
		stonewheelproduct.com
		newworldscreation.com
		membersrefer.com
		loopconsider.com
		idoliad.com
		greygraphicdesign.com
		hellovelocity.com
		parishgeo.com
		noticeel.com
		theshakleeproducts.com
		myconceptmade.com
		regionnew.com
		customcirclesinc.com
		thestudiothirtyfour.com
		conceptcreated.com
		precinctpredict.com
		refercommunity.com
		referpublic.com
		teledistrict.com
		storytimepalsonline.com
		originalmirror.com
		stoneroundproducts.com
		thoughtcreated.com
		advelder.com
		areawin.com
		alludeweb.com
		newglobecreative.com
		theoceaniqueboutique.com
		thereadingfriends.com
		themathewsmanor.com
		thefirstimages.com
		pacificiqueboutique.com
		adamandevesolutions.com
		promoteward.com
		freshworldcreative.com
		openupairstudio.com
		workshopthirtyfour.com
		therevealhome.com
		roomyworkplace.com
		freebirdpromotion.com
		customshapeinc.com
		adamneveconsulting.com
		menotice.com
		hiacceleration.com
		discoveryhouseonline.com
		thecoopercoonline.com
		shakleesproduct.com
		implyimage.com
		mygraygraphics.com
		rockroundstuff.com
		mathewsestate.com
		freerobinpromo.com
		sectioncode.com
		vicinityblurt.com
		myopenairstudio.com
		releasebirdpromotions.com
		theinovallc.com
		localehosting.com
		studiothreefour.com
		mycooperco.com
		mystorytimepals.com
		localecool.com
		parishdog.com
		myoriginalimage.com
		mydiscoveryhouses.com
		homeobserve.com
		considergroup.com
		advertgreen.com
		attendsite.com
		attendcrowd.com
		advertle.com
		myshakleegoods.com
		mymattsmanor.com
		myinovallc.com
205.186.210.187 1
	ns2.wheati.com 96
		turncommunity.com
		implyblue.com
		istarllc.com
		ecooperscompany.com
		graygraphicsonline.com
		personalizeshapesco.com
		oceaniqueshop.com
		observeblue.com
		hypoarea.com
		districtreviews.com
		districtidea.com
		wardcity.com
		urgeprecinct.com
		redallude.com
		vicinitydirect.com
		regionhot.com
		loadvert.com
		bucommunity.com
		chadvert.com
		gardenofedenconsulting.com
		hivelocities.com
		sectionbiz.com
		stonewheelproduct.com
		newworldscreation.com
		membersrefer.com
		loopconsider.com
		idoliad.com
		greygraphicdesign.com
		hellovelocity.com
		parishgeo.com
		noticeel.com
		theshakleeproducts.com
		myconceptmade.com
		regionnew.com
		customcirclesinc.com
		thestudiothirtyfour.com
		conceptcreated.com
		precinctpredict.com
		refercommunity.com
		referpublic.com
		teledistrict.com
		storytimepalsonline.com
		originalmirror.com
		stoneroundproducts.com
		thoughtcreated.com
		advelder.com
		areawin.com
		alludeweb.com
		newglobecreative.com
		theoceaniqueboutique.com
		thereadingfriends.com
		themathewsmanor.com
		thefirstimages.com
		pacificiqueboutique.com
		adamandevesolutions.com
		promoteward.com
		freshworldcreative.com
		openupairstudio.com
		workshopthirtyfour.com
		therevealhome.com
		roomyworkplace.com
		freebirdpromotion.com
		customshapeinc.com
		adamneveconsulting.com
		menotice.com
		hiacceleration.com
		discoveryhouseonline.com
		thecoopercoonline.com
		shakleesproduct.com
		implyimage.com
		mygraygraphics.com
		rockroundstuff.com
		mathewsestate.com
		freerobinpromo.com
		sectioncode.com
		vicinityblurt.com
		myopenairstudio.com
		releasebirdpromotions.com
		theinovallc.com
		localehosting.com
		studiothreefour.com
		mycooperco.com
		mystorytimepals.com
		localecool.com
		parishdog.com
		myoriginalimage.com
		mydiscoveryhouses.com
		homeobserve.com
		considergroup.com
		advertgreen.com
		attendsite.com
		attendcrowd.com
		advertle.com
		myshakleegoods.com
		mymattsmanor.com
		myinovallc.com
205.186.214.127 1
	ns1.dogvar.com 96
		bruetonsindustries.com
		protechiesonline.com
		noticebiz.com
		lisaloocreation.com
		mytuesdayforum.com
		precincttip.com
		atyourserviceplanning.com
		communityhot.com
		coolallude.com
		coreparish.com
		starlocale.com
		sourcesection.com
		bluetonindustry.com
		wardblue.com
		sweetdentalconcentrate.com
		structuredynamicpattern.com
		hsrdevelopments.com
		herseniordev.com
		thepurpletrunk.com
		thejetpresses.com
		areaeasy.com
		ginkoprints.com
		formincs.com
		thecognativedesigns.com
		ginkoscopy.com
		candyconsultingonline.com
		culvertintersect.com
		awardmerchandise.com
		myprotechnical.com
		jetpushonline.com
		trippstravelweb.com
		thegrapeelephant.com
		listsection.com
		pointnotice.com
		shapeincs.com
		consideron.com
		businessobserve.com
		culversconnection.com
		myinsidetraders.com
		theprotraining.com
		theforminc.com
		greenlocale.com
		meetattend.com
		cityimply.com
		kathydenimco.com
		theculversconnect.com
		myadvertisingguy.com
		intervicinity.com
		candyteethspecials.com
		worldattend.com
		pointregion.com
		thetriptravel.com
		visionregion.com
		cognativepattern.com
		theginkoprinting.com
		mypurpleelephants.com
		marketimply.com
		etrippstravel.com
		candiesconsultants.com
		cathyjeaninc.com
		forumparish.com
		medalliongoods.com
		buildingactivepatterns.com
		swamiad.com
		myairbornepress.com
		tuesdayforums.com
		clinchward.com
		themainedge.com
		brueweightindustries.com
		observecool.com
		medallionsmerchandise.com
		thenortheastline.com
		thesweettoothspecialties.com
		atyourserviceplans.com
		attentivehelppreparing.com
		linevicinity.com
		firmdistrict.com
		communitytop.com
		courtprecinct.com
		theinteriormarket.com
		theweekdaygroup.com
		mainesedge.com
		thestructualdynamicdesign.com
		sweetadvising.com
		exchangerefer.com
		lisalooscreations.com
		amarketingman.com
		cathydeniminc.com
		lldevelopments.com
		coconsider.com
		alludegroup.com
		theadvertiseguy.com
		hsreddevelopment.com
		minddesignsonline.com
		interiortradeweb.com
		areabota.com
205.186.214.128 1
	ns2.dogvar.com 96
		bruetonsindustries.com
		protechiesonline.com
		noticebiz.com
		lisaloocreation.com
		mytuesdayforum.com
		precincttip.com
		atyourserviceplanning.com
		communityhot.com
		coolallude.com
		coreparish.com
		starlocale.com
		sourcesection.com
		bluetonindustry.com
		wardblue.com
		sweetdentalconcentrate.com
		structuredynamicpattern.com
		hsrdevelopments.com
		herseniordev.com
		thepurpletrunk.com
		thejetpresses.com
		areaeasy.com
		ginkoprints.com
		formincs.com
		thecognativedesigns.com
		ginkoscopy.com
		candyconsultingonline.com
		culvertintersect.com
		awardmerchandise.com
		myprotechnical.com
		jetpushonline.com
		trippstravelweb.com
		thegrapeelephant.com
		listsection.com
		pointnotice.com
		shapeincs.com
		consideron.com
		businessobserve.com
		culversconnection.com
		myinsidetraders.com
		theprotraining.com
		theforminc.com
		greenlocale.com
		meetattend.com
		cityimply.com
		kathydenimco.com
		theculversconnect.com
		myadvertisingguy.com
		intervicinity.com
		candyteethspecials.com
		worldattend.com
		pointregion.com
		thetriptravel.com
		visionregion.com
		cognativepattern.com
		theginkoprinting.com
		mypurpleelephants.com
		marketimply.com
		etrippstravel.com
		candiesconsultants.com
		cathyjeaninc.com
		forumparish.com
		medalliongoods.com
		buildingactivepatterns.com
		swamiad.com
		myairbornepress.com
		tuesdayforums.com
		clinchward.com
		themainedge.com
		brueweightindustries.com
		observecool.com
		medallionsmerchandise.com
		thenortheastline.com
		thesweettoothspecialties.com
		atyourserviceplans.com
		attentivehelppreparing.com
		linevicinity.com
		firmdistrict.com
		communitytop.com
		courtprecinct.com
		theinteriormarket.com
		theweekdaygroup.com
		mainesedge.com
		thestructualdynamicdesign.com
		sweetadvising.com
		exchangerefer.com
		lisalooscreations.com
		amarketingman.com
		cathydeniminc.com
		lldevelopments.com
		coconsider.com
		alludegroup.com
		theadvertiseguy.com
		hsreddevelopment.com
		minddesignsonline.com
		interiortradeweb.com
		areabota.com
205.186.217.159 1
	ns1.ellypa.com 96
		limitrading.com
		stadiumdesigngroup.com
		presscool.com
		morrisonssupply.com
		moresonsstock.com
		fifthaveimporting.com
		broadcastcredit.com
		litbasin.com
		enewsak.com
		talkcontainer.com
		mycrawfortinc.com
		etelindustry.com
		freespiritage.com
		thequicksignsworld.com
		thecircuitbreak.com
		almostcrimson.com
		dominatetoddchange.com
		circuitsbreak.com
		barreltrasport.com
		venuecreationresourcesinc.com
		mynaturalinc.com
		squaredcompanies.com
		crawfordsco.com
		ehotelindustries.com
		justredder.com
		fastsignalinternational.com
		extentexchange.com
		harddrivestock.com
		alphabetlogistic.com
		eprintplusmore.com
		brltransportation.com
		limitraders.com
		goldenlightonline.com
		newspaperadd.com
		hippyyears.com
		giftglam.com
		hippyyear.com
		troughforum.com
		rlogistical.com
		theorganicinc.com
		eventcreatesourcesco.com
		lowlandsite.com
		organicincorporate.com
		fivestreetgoods.com
		etelecompany.com
		presentfancy.com
		canyonspace.com
		hothollow.com
		thecrawfordcomp.com
		theglamgift.com
		channelcool.com
		canyonnetwork.com
		bluecorrespond.com
		dovalley.com
		circlechannel.com
		egulfred.com
		stadlerdesigngroups.com
		gorgesocial.com
		amberglos.com
		containerfilm.com
		blogevm.com
		tobasin.com
		morristownsupply.com
		trackbroken.com
		hawmedia.com
		brainstormspacesinc.com
		thehdstock.com
		damiantoadsinvention.com
		stadlerspatternforum.com
		justaboutred.com
		hollowdigital.com
		theprintplusweb.com
		thoughtplacebiz.com
		bowlscene.com
		blueemedia.com
		correspondlist.com
		hdsuppliers.com
		fifthstreetimports.com
		brlmoving.com
		squaredcorp.com
		damiantoddinnovation.com
		lowlandgroups.com
		bottombiz.com
		foursidedco.com
		amberglows.com
		thinkspaceinc.com
		mystarbelt.com
		bowlza.com
		brudip.com
		valleytop.com
		sunbuckle.com
		troughglobal.com
		venuemaderesourcesinc.com
		thesunbeltweb.com
		rcoordination.com
		fastsignsintl.com
205.186.217.160 1
	ns2.ellypa.com 96
		limitrading.com
		stadiumdesigngroup.com
		presscool.com
		morrisonssupply.com
		moresonsstock.com
		fifthaveimporting.com
		broadcastcredit.com
		litbasin.com
		enewsak.com
		talkcontainer.com
		mycrawfortinc.com
		etelindustry.com
		freespiritage.com
		thequicksignsworld.com
		thecircuitbreak.com
		almostcrimson.com
		dominatetoddchange.com
		circuitsbreak.com
		barreltrasport.com
		venuecreationresourcesinc.com
		mynaturalinc.com
		squaredcompanies.com
		crawfordsco.com
		ehotelindustries.com
		justredder.com
		fastsignalinternational.com
		extentexchange.com
		harddrivestock.com
		alphabetlogistic.com
		eprintplusmore.com
		brltransportation.com
		limitraders.com
		goldenlightonline.com
		newspaperadd.com
		hippyyears.com
		giftglam.com
		hippyyear.com
		troughforum.com
		rlogistical.com
		theorganicinc.com
		eventcreatesourcesco.com
		lowlandsite.com
		organicincorporate.com
		fivestreetgoods.com
		etelecompany.com
		presentfancy.com
		canyonspace.com
		hothollow.com
		thecrawfordcomp.com
		theglamgift.com
		channelcool.com
		canyonnetwork.com
		bluecorrespond.com
		dovalley.com
		circlechannel.com
		egulfred.com
		stadlerdesigngroups.com
		gorgesocial.com
		amberglos.com
		containerfilm.com
		blogevm.com
		tobasin.com
		morristownsupply.com
		trackbroken.com
		hawmedia.com
		brainstormspacesinc.com
		thehdstock.com
		damiantoadsinvention.com
		stadlerspatternforum.com
		justaboutred.com
		hollowdigital.com
		theprintplusweb.com
		thoughtplacebiz.com
		bowlscene.com
		blueemedia.com
		correspondlist.com
		hdsuppliers.com
		fifthstreetimports.com
		brlmoving.com
		squaredcorp.com
		damiantoddinnovation.com
		lowlandgroups.com
		bottombiz.com
		foursidedco.com
		amberglows.com
		thinkspaceinc.com
		mystarbelt.com
		bowlza.com
		brudip.com
		valleytop.com
		sunbuckle.com
		troughglobal.com
		venuemaderesourcesinc.com
		thesunbeltweb.com
		rcoordination.com
		fastsignsintl.com
205.186.223.195 1
	ns1.vasecd.com 96
		terracepattern.com
		torrezdesigns.com
		dipcool.com
		thecompasstrade.com
		livecanyon.com
		designandcreating.com
		ensteiners.com
		alltrough.com
		thefoodhomes.com
		publiclowland.com
		evmnews.com
		mediabottom.com
		worldwidedistribute.com
		besthollow.com
		digitalcorrespond.com
		ramsrocllc.com
		hondopartners.com
		compasstraders.com
		backbalcony.com
		topgambleco.com
		ricerbizllc.com
		electricprocesses.com
		hundredaffiliates.com
		theelectricalsystem.com
		theaandabusiness.com
		containersports.com
		patternandbuild.com
		hugshersupplyinc.com
		hughesupplyinc.com
		exoticmeeting.com
		directionexchange.com
		hollowpro.com
		crashrockco.com
		bestbetsinc.com
		rearporch.com
		worldcanyon.com
		allenalconcompany.com
		cobroadcast.com
		rcrenterprisesinc.com
		chargedsystem.com
		siteenews.com
		hughesstockco.com
		exoticmeets.com
		innersteinman.com
		fairodip.com
		gorgeloop.com
		gavalley.com
		universalvendors.com
		designersbuilds.com
		velocityadviceco.com
		hotevm.com
		egulfmedia.com
		onlinegorge.com
		evmbusiness.com
		enewsgreen.com
		forumgorge.com
		dipsole.com
		emediast.com
		channelpublic.com
		tripspress.com
		emediaclick.com
		pressvacation.com
		pointbroadcast.com
		thehondopartner.com
		universedistributors.com
		bottomdigital.com
		basinsource.com
		nowtrough.com
		knobowl.com
		enewsbiz.com
		basinblue.com
		thebestbetinc.com
		velocityadvisorsinc.com
		volcanobiz.com
		valleyom.com
		ramrocsllc.com
		correspondone.com
		mytorrezdesign.com
		foodestate.com
		allenandalconcompany.com
		businessbottom.com
		eruptionenterprizes.com
		enterstein.com
		medcontainer.com
		volcanoenterprizes.com
		ricerenterprisellc.com
		mygrubhouse.com
		channelso.com
		flyenews.com
		gelpress.com
		speedadvisorsinc.com
		thebackporches.com
		differentgroups.com
		hanbowl.com
		broadcastred.com
		communitylowland.com
205.186.223.196 1
	ns2.vasecd.com 96
		terracepattern.com
		torrezdesigns.com
		dipcool.com
		thecompasstrade.com
		livecanyon.com
		designandcreating.com
		ensteiners.com
		alltrough.com
		thefoodhomes.com
		publiclowland.com
		evmnews.com
		mediabottom.com
		worldwidedistribute.com
		besthollow.com
		digitalcorrespond.com
		ramsrocllc.com
		hondopartners.com
		compasstraders.com
		backbalcony.com
		topgambleco.com
		ricerbizllc.com
		electricprocesses.com
		hundredaffiliates.com
		theelectricalsystem.com
		theaandabusiness.com
		containersports.com
		patternandbuild.com
		hugshersupplyinc.com
		hughesupplyinc.com
		exoticmeeting.com
		directionexchange.com
		hollowpro.com
		crashrockco.com
		bestbetsinc.com
		rearporch.com
		worldcanyon.com
		allenalconcompany.com
		cobroadcast.com
		rcrenterprisesinc.com
		chargedsystem.com
		siteenews.com
		hughesstockco.com
		exoticmeets.com
		innersteinman.com
		fairodip.com
		gorgeloop.com
		gavalley.com
		universalvendors.com
		designersbuilds.com
		velocityadviceco.com
		hotevm.com
		egulfmedia.com
		onlinegorge.com
		evmbusiness.com
		enewsgreen.com
		forumgorge.com
		dipsole.com
		emediast.com
		channelpublic.com
		tripspress.com
		emediaclick.com
		pressvacation.com
		pointbroadcast.com
		thehondopartner.com
		universedistributors.com
		bottomdigital.com
		basinsource.com
		nowtrough.com
		knobowl.com
		enewsbiz.com
		basinblue.com
		thebestbetinc.com
		velocityadvisorsinc.com
		volcanobiz.com
		valleyom.com
		ramrocsllc.com
		correspondone.com
		mytorrezdesign.com
		foodestate.com
		allenandalconcompany.com
		businessbottom.com
		eruptionenterprizes.com
		enterstein.com
		medcontainer.com
		volcanoenterprizes.com
		ricerenterprisellc.com
		mygrubhouse.com
		channelso.com
		flyenews.com
		gelpress.com
		speedadvisorsinc.com
		thebackporches.com
		differentgroups.com
		hanbowl.com
		broadcastred.com
		communitylowland.com
207.226.192.253 1
	ns1.guidexs.com 28
		marketorientations.com
		informationfirsts.com
		guidetobuybest.com
		newguideblog.com
		easybuybest.com
		shopforfuns.com
		infolistgroup.com
		getreleasebiz.com
		ontopdata.com
		anyguidedeal.com
		anyshoppingnews.com
		hotdealrelease.com
		onlygoodthing.com
		findtoprelease.com
		coollistbiz.com
		releaseart.com
		biznewsbook.com
		bestfromcatalog.com
		thinkmarketclick.com
		morerelese.com
		feeshopguide.com
		easyfindcash.com
		creditreleases.com
		buyfromthelist.com
		thenewsbest.com
		shopingtoolstohave.com
		easyguidebox.com
		clicktoreleases.com
207.226.192.254 1
	ns2.guidexs.com 28
		marketorientations.com
		informationfirsts.com
		guidetobuybest.com
		newguideblog.com
		easybuybest.com
		shopforfuns.com
		infolistgroup.com
		getreleasebiz.com
		ontopdata.com
		anyguidedeal.com
		anyshoppingnews.com
		hotdealrelease.com
		onlygoodthing.com
		findtoprelease.com
		coollistbiz.com
		releaseart.com
		biznewsbook.com
		bestfromcatalog.com
		thinkmarketclick.com
		morerelese.com
		feeshopguide.com
		easyfindcash.com
		creditreleases.com
		buyfromthelist.com
		thenewsbest.com
		shopingtoolstohave.com
		easyguidebox.com
		clicktoreleases.com
207.226.193.2 1
	ns1.digestart.com 28
		whatsnewtodays.com
		thinkbuys.com
		catalogbest.com
		toptodaydeal.com
		newonmarkets.com
		releasemagazines.com
		delaramas.com
		dealintheboxs.com
		onreleases.com
		reviewpanelbiz.com
		marketguideblog.com
		clicktoguide.com
		forwardthinkingmarket.com
		buyguidedata.com
		bestdealfinders.com
		marketcompasblog.com
		newnows.com
		marketcompas.com
		bestcreditauto.com
		worldcatalogus.com
		todaysnewsbiz.com
		targeteds.com
		releasefun.com
		dealrelease.com
		hotdealreleases.com
		focusmarkets.com
		anyguidefind.com
		compasbiz.com
207.226.193.3 1
	ns2.digestart.com 28
		whatsnewtodays.com
		thinkbuys.com
		catalogbest.com
		toptodaydeal.com
		newonmarkets.com
		releasemagazines.com
		delaramas.com
		dealintheboxs.com
		onreleases.com
		reviewpanelbiz.com
		marketguideblog.com
		clicktoguide.com
		forwardthinkingmarket.com
		buyguidedata.com
		bestdealfinders.com
		marketcompasblog.com
		newnows.com
		marketcompas.com
		bestcreditauto.com
		worldcatalogus.com
		todaysnewsbiz.com
		targeteds.com
		releasefun.com
		dealrelease.com
		hotdealreleases.com
		focusmarkets.com
		anyguidefind.com
		compasbiz.com
207.226.194.253 1
	ns1.catalogdot.com 30
		newnowidea.com
		dealsfinderbest.com
		targetedblog.com
		digestmoney.com
		thinkbests.com
		smartdealbusiness.com
		digestdata.com
		readytoknows.com
		salesreviewblog.com
		onreleasecode.com
		guideramas.com
		releasemagazinebuy.com
		cataloglove.com
		anounced.com
		newsics.com
		bandnewrelease.com
		ideaslibrarys.com
		sickrelease.com
		thesmarters.com
		marketguidedeal.com
		newtrendreview.com
		bereleaseds.com
		oneclicksmarters.com
		oneclicksmarter.com
		newtrendreviews.com
		newonmarketgames.com
		gotnewsblog.com
		freetobuys.com
		smartguidebook.com
		toptodays.com
207.226.194.254 1
	ns2.catalogdot.com 30
		newnowidea.com
		dealsfinderbest.com
		targetedblog.com
		digestmoney.com
		thinkbests.com
		smartdealbusiness.com
		digestdata.com
		readytoknows.com
		salesreviewblog.com
		onreleasecode.com
		guideramas.com
		releasemagazinebuy.com
		cataloglove.com
		anounced.com
		newsics.com
		bandnewrelease.com
		ideaslibrarys.com
		sickrelease.com
		thesmarters.com
		marketguidedeal.com
		newtrendreview.com
		bereleaseds.com
		oneclicksmarters.com
		oneclicksmarter.com
		newtrendreviews.com
		newonmarketgames.com
		gotnewsblog.com
		freetobuys.com
		smartguidebook.com
		toptodays.com
207.226.195.2 1
	ns1.fairki.com 28
		explorexa.com
		horseshoefind.com
		blessedcool.com
		chasenot.com
		sumlucky.com
		marketrabbit.com
		sourceleaf.com
		cloverfind.com
		boxexplore.com
		examineen.com
		ritualzon.com
		pointace.com
		examinefun.com
		hotgolden.com
		reporlook.com
		advget.com
		huntarcar.com
		solutionslook.com
		pointgolden.com
		questtop.com
		herabbit.com
		fortuneck.com
		favorclick.com
		huntmind.com
		carblessed.com
		pursuecredit.com
		charmmind.com
		proproot.com
207.226.195.3 1
	ns2.fairki.com 28
		explorexa.com
		horseshoefind.com
		blessedcool.com
		chasenot.com
		sumlucky.com
		marketrabbit.com
		sourceleaf.com
		cloverfind.com
		boxexplore.com
		examineen.com
		ritualzon.com
		pointace.com
		examinefun.com
		hotgolden.com
		reporlook.com
		advget.com
		huntarcar.com
		solutionslook.com
		pointgolden.com
		questtop.com
		herabbit.com
		fortuneck.com
		favorclick.com
		huntmind.com
		carblessed.com
		pursuecredit.com
		charmmind.com
		proproot.com
207.226.196.253 1
	ns1.auberf.com 28
		bizgolden.com
		charmyar.com
		redexplore.com
		explorefo.com
		looktaill.com
		propbest.com
		blessedpro.com
		examinetech.com
		favornews.com
		horseshoeblue.com
		acetanto.com
		chasecode.com
		leafgene.com
		merainbow.com
		explorewin.com
		luckyor.com
		onlineclover.com
		questcool.com
		pursuebol.com
		inrabbit.com
		fortunemo.com
		examineart.com
		canritual.com
		hunticall.com
		advsky.com
		ritualblog.com
		dextrhunt.com
		rainbowjob.com
207.226.196.254 1
	ns2.auberf.com 28
		bizgolden.com
		charmyar.com
		redexplore.com
		explorefo.com
		looktaill.com
		propbest.com
		blessedpro.com
		examinetech.com
		favornews.com
		horseshoeblue.com
		acetanto.com
		chasecode.com
		leafgene.com
		merainbow.com
		explorewin.com
		luckyor.com
		onlineclover.com
		questcool.com
		pursuebol.com
		inrabbit.com
		fortunemo.com
		examineart.com
		canritual.com
		hunticall.com
		advsky.com
		ritualblog.com
		dextrhunt.com
		rainbowjob.com
207.226.197.2 1
	ns1.goream.com 32
		favorver.com
		cloverwin.com
		fortunecool.com
		existlook.com
		rainbowar.com
		prexamine.com
		dablessed.com
		thouprop.com
		deafavor.com
		visionrainbow.com
		propblue.com
		findadv.com
		exploreeasy.com
		comleaf.com
		leafclick.com
		saccharm.com
		medalace.com
		bergmadv.com
		worldrabbit.com
		horseshoenew.com
		luckywo.com
		joexamine.com
		charmhandle.com
		thruquest.com
		pursuelink.com
		chasecks.com
		senritual.com
		topchase.com
		vafortune.com
		searchgolden.com
		rabbitor.com
		findblessed.com
207.226.197.3 1
	ns2.goream.com 32
		favorver.com
		cloverwin.com
		fortunecool.com
		existlook.com
		rainbowar.com
		prexamine.com
		dablessed.com
		thouprop.com
		deafavor.com
		visionrainbow.com
		propblue.com
		findadv.com
		exploreeasy.com
		comleaf.com
		leafclick.com
		saccharm.com
		medalace.com
		bergmadv.com
		worldrabbit.com
		horseshoenew.com
		luckywo.com
		joexamine.com
		charmhandle.com
		thruquest.com
		pursuelink.com
		chasecks.com
		senritual.com
		topchase.com
		vafortune.com
		searchgolden.com
		rabbitor.com
		findblessed.com
207.226.198.253 1
	ns1.bruxim.com 32
		favoride.com
		ishorseshoe.com
		fortuneyou.com
		easyrainbow.com
		bestblessed.com
		pointcharm.com
		fortunehot.com
		chaselle.com
		softgolden.com
		examineth.com
		glupursue.com
		advistig.com
		cloverlist.com
		hollucky.com
		gethorseshoe.com
		properan.com
		storeadv.com
		skineace.com
		catfavor.com
		wegolden.com
		mirabbit.com
		solutionshunt.com
		rabbitget.com
		leafget.com
		rainbowry.com
		explorehouse.com
		lookeline.com
		daywoace.com
		cashcharm.com
		siteblessed.com
		newchase.com
		ritualorg.com
207.226.198.254 1
	ns2.bruxim.com 32
		favoride.com
		ishorseshoe.com
		fortuneyou.com
		easyrainbow.com
		bestblessed.com
		pointcharm.com
		fortunehot.com
		chaselle.com
		softgolden.com
		examineth.com
		glupursue.com
		advistig.com
		cloverlist.com
		hollucky.com
		gethorseshoe.com
		properan.com
		storeadv.com
		skineace.com
		catfavor.com
		wegolden.com
		mirabbit.com
		solutionshunt.com
		rabbitget.com
		leafget.com
		rainbowry.com
		explorehouse.com
		lookeline.com
		daywoace.com
		cashcharm.com
		siteblessed.com
		newchase.com
		ritualorg.com
207.226.199.253 1
	ns1.acerer.com 32
		teampassea.com
		crewckerer.com
		clicktoacten.com
		tickcar.com
		venderparatodos.com
		opinionrelease.com
		ecrewpon.com
		credittr.com
		regularbuyerhere.com
		teamdiscounter.com
		increwnews.com
		backtotheshop.com
		storetochoose.com
		snapnew.com
		stealdealcredit.com
		discountaa.com
		clackdigital.com
		marketcrewar.com
		buyeramaha.com
		teamuper.com
		clickandp.com
		dealcreatordesign.com
		tapblue.com
		teamrolla.com
		onlineshoppingassist.com
		onthelistbiz.com
		taprously.com
		storeextansion.com
		groupdealco.com
		crewclickme.com
		buyprodeal.com
		alcrewpon.com
207.226.199.254 1
	ns2.acerer.com 32
		teampassea.com
		crewckerer.com
		clicktoacten.com
		tickcar.com
		venderparatodos.com
		opinionrelease.com
		ecrewpon.com
		credittr.com
		regularbuyerhere.com
		teamdiscounter.com
		increwnews.com
		backtotheshop.com
		storetochoose.com
		snapnew.com
		stealdealcredit.com
		discountaa.com
		clackdigital.com
		marketcrewar.com
		buyeramaha.com
		teamuper.com
		clickandp.com
		dealcreatordesign.com
		tapblue.com
		teamrolla.com
		onlineshoppingassist.com
		onthelistbiz.com
		taprously.com
		storeextansion.com
		groupdealco.com
		crewclickme.com
		buyprodeal.com
		alcrewpon.com
207.226.200.2 1
	ns1.hissida.com 32
		teamerly.com
		toteamdiscount.com
		discountpixel.com
		clicktorunner.com
		bizdiz.com
		crewbizer.com
		groupdealsclick.com
		groupchoise.com
		crewponerbook.com
		troytobuy.com
		clackspan.com
		buyrgo.com
		snapturfe.com
		dealtotake.com
		crewtogoclick.com
		crewponer.com
		clickissy.com
		tickmoney.com
		easybuydeal.com
		allgroupdiscaunter.com
		buysupporter.com
		onlinedealhunter.com
		humadv.com
		teambiztoget.com
		newdealrelease.com
		henriad.com
		hostingtap.com
		teamshoppinger.com
		crewdealer.com
		clackcool.com
		crewclickar.com
		technologyasapse.com
207.226.200.3 1
	ns2.hissida.com 32
		teamerly.com
		toteamdiscount.com
		discountpixel.com
		clicktorunner.com
		bizdiz.com
		crewbizer.com
		groupdealsclick.com
		groupchoise.com
		crewponerbook.com
		troytobuy.com
		clackspan.com
		buyrgo.com
		snapturfe.com
		dealtotake.com
		crewtogoclick.com
		crewponer.com
		clickissy.com
		tickmoney.com
		easybuydeal.com
		allgroupdiscaunter.com
		buysupporter.com
		onlinedealhunter.com
		humadv.com
		teambiztoget.com
		newdealrelease.com
		henriad.com
		hostingtap.com
		teamshoppinger.com
		crewdealer.com
		clackcool.com
		crewclickar.com
		technologyasapse.com
207.226.201.253 1
	ns1.rudenes.com 32
		crewtobuyeasy.com
		crewclickan.com
		bunchofdealsfinder.com
		betterdealla.com
		globobuyersteam.com
		clackerto.com
		adonalle.com
		shoppandhave.com
		payandgodeal.com
		discountti.com
		creditag.com
		crewclickes.com
		minissnap.com
		shoppingcrew.com
		snapchell.com
		onlinetick.com
		listtobuydeal.com
		prcrewnews.com
		aimeclack.com
		crewbizdeal.com
		clickrium.com
		buyprobiz.com
		touchetap.com
		trixpoad.com
		teamtoclick.com
		taphot.com
		totalshoppingnewer.com
		findtick.com
		teampassar.com
		teamuson.com
		buyproclick.com
		aztechnologyasap.com
207.226.201.254 1
	ns2.rudenes.com 32
		crewtobuyeasy.com
		crewclickan.com
		bunchofdealsfinder.com
		betterdealla.com
		globobuyersteam.com
		clackerto.com
		adonalle.com
		shoppandhave.com
		payandgodeal.com
		discountti.com
		creditag.com
		crewclickes.com
		minissnap.com
		shoppingcrew.com
		snapchell.com
		onlinetick.com
		listtobuydeal.com
		prcrewnews.com
		aimeclack.com
		crewbizdeal.com
		clickrium.com
		buyprobiz.com
		touchetap.com
		trixpoad.com
		teamtoclick.com
		taphot.com
		totalshoppingnewer.com
		findtick.com
		teampassar.com
		teamuson.com
		buyproclick.com
		aztechnologyasap.com
207.226.202.2 1
	ns1.salingam.com 32
		prosubject.com
		agencurrent.com
		admirablecool.com
		ringranteen.com
		noblewin.com
		northmatter.com
		athandjob.com
		buzznew.com
		themered.com
		reportget.com
		gurglerfizz.com
		reviewacase.com
		thebuzzworthy.com
		issuelife.com
		duobest.com
		hootrotnews.com
		celebrityet.com
		easymerit.com
		contentcar.com
		vegmaterial.com
		topicop.com
		eventibbler.com
		occuranceweb.com
		worldgrapevine.com
		deservend.com
		extendotalk.com
		commentpo.com
		popularbell.com
		virtuedigital.com
		worthyauto.com
		savifashion.com
		cohonest.com
207.226.202.3 1
	ns2.salingam.com 32
		prosubject.com
		agencurrent.com
		admirablecool.com
		ringranteen.com
		noblewin.com
		northmatter.com
		athandjob.com
		buzznew.com
		themered.com
		reportget.com
		gurglerfizz.com
		reviewacase.com
		thebuzzworthy.com
		issuelife.com
		duobest.com
		hootrotnews.com
		celebrityet.com
		easymerit.com
		contentcar.com
		vegmaterial.com
		topicop.com
		eventibbler.com
		occuranceweb.com
		worldgrapevine.com
		deservend.com
		extendotalk.com
		commentpo.com
		popularbell.com
		virtuedigital.com
		worthyauto.com
		savifashion.com
		cohonest.com
207.226.203.253 1
	ns1.factomm.com 30
		lifepopular.com
		casebrighte.com
		deservebiz.com
		redbuzzworthy.com
		solutionsbuzz.com
		honestop.com
		worthygame.com
		ringnew.com
		healthnoble.com
		beststee.com
		commenthome.com
		currentille.com
		admirablelink.com
		gussystnews.com
		eventrealestate.com
		contentello.com
		tetopic.com
		redmerit.com
		ingrapevine.com
		issuegame.com
		fashionnear.com
		grapevinebox.com
		athandtravel.com
		mindcelebrity.com
		fizzascollo.com
		sumatter.com
		subjectmarket.com
		virtuecar.com
		bohearstalk.com
		reportsky.com
207.226.203.254 1
	ns2.factomm.com 30
		lifepopular.com
		casebrighte.com
		deservebiz.com
		redbuzzworthy.com
		solutionsbuzz.com
		honestop.com
		worthygame.com
		ringnew.com
		healthnoble.com
		beststee.com
		commenthome.com
		currentille.com
		admirablelink.com
		gussystnews.com
		eventrealestate.com
		contentello.com
		tetopic.com
		redmerit.com
		ingrapevine.com
		issuegame.com
		fashionnear.com
		grapevinebox.com
		athandtravel.com
		mindcelebrity.com
		fizzascollo.com
		sumatter.com
		subjectmarket.com
		virtuecar.com
		bohearstalk.com
		reportsky.com
207.226.204.253 1
	ns1.tianeous.com 32
		starcurrent.com
		eventnew.com
		brickercase.com
		reporttravel.com
		pernoble.com
		boxhonest.com
		winmatter.com
		trimaterial.com
		themerating.com
		starpopular.com
		materialmel.com
		athandauto.com
		themedata.com
		airlistnews.com
		topicblue.com
		smibest.com
		meritdigital.com
		blueworthy.com
		groupissue.com
		propertyfashion.com
		bookdeserve.com
		admirablenews.com
		commentget.com
		busypontalk.com
		virtueky.com
		occurancecity.com
		saysadiring.com
		storecelebrity.com
		buzzecti.com
		grapevinehot.com
		subjectbest.com
		regucontent.com
207.226.204.254 1
	ns2.tianeous.com 32
		starcurrent.com
		eventnew.com
		brickercase.com
		reporttravel.com
		pernoble.com
		boxhonest.com
		winmatter.com
		trimaterial.com
		themerating.com
		starpopular.com
		materialmel.com
		athandauto.com
		themedata.com
		airlistnews.com
		topicblue.com
		smibest.com
		meritdigital.com
		blueworthy.com
		groupissue.com
		propertyfashion.com
		bookdeserve.com
		admirablenews.com
		commentget.com
		busypontalk.com
		virtueky.com
		occurancecity.com
		saysadiring.com
		storecelebrity.com
		buzzecti.com
		grapevinehot.com
		subjectbest.com
		regucontent.com
207.226.205.2 1
	ns1.collerma.com 32
		spacenoble.com
		bluepopular.com
		episeetheme.com
		buzznomy.com
		hoplinevent.com
		athanddeal.com
		petmaterial.com
		therdefnews.com
		rivirtue.com
		creativetopic.com
		funcomment.com
		fizzimage.com
		kindcontent.com
		mattermobile.com
		admirablebest.com
		videomerit.com
		mobileworthy.com
		imparticase.com
		cariosering.com
		reportred.com
		waxbest.com
		pointfizz.com
		currentred.com
		breakathand.com
		creativesubject.com
		fashionsblue.com
		dealcelebrity.com
		codehonest.com
		occurancebiz.com
		talkroomanc.com
		issuecity.com
		deserveshop.com
207.226.205.3 1
	ns2.collerma.com 32
		spacenoble.com
		bluepopular.com
		episeetheme.com
		buzznomy.com
		hoplinevent.com
		athanddeal.com
		petmaterial.com
		therdefnews.com
		rivirtue.com
		creativetopic.com
		funcomment.com
		fizzimage.com
		kindcontent.com
		mattermobile.com
		admirablebest.com
		videomerit.com
		mobileworthy.com
		imparticase.com
		cariosering.com
		reportred.com
		waxbest.com
		pointfizz.com
		currentred.com
		breakathand.com
		creativesubject.com
		fashionsblue.com
		dealcelebrity.com
		codehonest.com
		occurancebiz.com
		talkroomanc.com
		issuecity.com
		deserveshop.com


From jcurran at arin.net  Fri Nov  5 08:46:03 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 5 Nov 2010 08:46:03 -0400
Subject: [arin-ppml] Low Utilization.
In-Reply-To: <40820.1288949683@tristatelogic.com>
References: <40820.1288949683@tristatelogic.com>
Message-ID: <92568641-795E-47D6-BC67-5EAC01BB124F@arin.net>

On Nov 5, 2010, at 5:34 AM, Ronald F. Guilmette wrote:

> In message <0F135456-F298-40D4-95BB-5C4087637B67 at arin.net>, 
> John Curran <jcurran at arin.net> wrote:
> 
>>> {... big buch of non-responsive platitudes snipped... }
>> 
>> Actually, I was providing clarity regarding the state of the registry infor
>> mation on legacy resources and what constitutes number resource fraud.  I t
>> hought that was what you were asking about, but easily could have been wron
>> g.
> 
> No, John, I wasn't asking about any registry information.  And I think you
> knew that.  I was asking the same question that I have asked you repeatedly
> in private e-mail over several weeks, without any response from you whatsoever.
> 
> Again, just to repeat what I have already asked you in private e-mail (without
> any reply), I, and also others I know would very much like to know exactly
> how much unmitigated and unambiguous waste and fraud some entity holding
> ARIN number resources can get away with before ARIN will see fit to do
> anything about it.  I mean how much does the waste/fraud have to be?  What
> is the "action" threshold?  25% ? 50% ? 75% ?

Ron - 
 
  Low utilization does not create number resource fraud, per se, i.e. 
  there is no "threshold".  I've already explained what constitutes
  number resource fraud in an earlier reply, so I will not repeat it 
  for sake of brevity. 
 
  It is quite possible that low utilization will prevent someone from 
  getting additional resources or from transferring all of the number
  resources based on current M&A transfer policy.  It is also possible
  that I'll have a discussion with a party about their resource   
  utilization as a result of the resource review policy. None of 
  these circumstances constitutes number resource fraud.

> And as I also asked you in private e-mail (also without any reply) does
> ARIN care about and/or will ARIN _do_ anything about deliberately fradulent
> sub-allocation WHOIS records?
> 
> I have already a record of several dozens of these... all being used by
> a handful of crooked ISPs to give cover to their pet snowshoe spammers
> (to whom, as I have told you, they typically give a /24 for each single
> actual host).
> 
> So, if I report them all, will ARIN even bother to investigate any of these
> bogus/fradulent WHOIS records?  Or should I not even waste my time, e.g.
> because ARIN doesn't give a flying fig about SUB-allocation WHOIS records?
> (Or should I not waste my time because as long as any given ARIN member stays
> below, e.g., 15% fraud, ARIN will consider that inconsequential, in the
> Grand Scheme of Things.)
> 
> I really would like to know, you know, before I waste all that time typing
> into your fraud form, just to be told, e.g. that ARIN doesn't ``police''
> fraud in SUB-allocation records.

If a party requests address space based on fraudulent data, we are very 
interested.  Please report such.

>> Ron - I believe I've extended you every courtesy, even in absence of same.
> 
> Well, ya know, answering, rather than just ignoring my private e-mails would
> have been nice, even if only to tell me to buzz off.  (After all, you _did_
> previously suggest to me that you'd be willing to answer my questions off
> list, but then, in practice, apparently not so much.)  But we'll let that
> go for now.

At present, I have two private emails from you that I have not yet replied to;
this is not an indication that I don't intend to reply at all, only that I get 
a bit of email as one might imagine and therefore have to prioritize when the
entry rate exceeds the processing rate.  It appears that I've sent you more 
than a dozen private replies in the month of October, so it is disingenuous to
say you've been ignored.

/John

John Curran
President and CEO
ARIN

From rfg at tristatelogic.com  Fri Nov  5 08:56:56 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Fri, 05 Nov 2010 05:56:56 -0700
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <76036B6C-C69D-451D-B2C8-0BBA036428CC@arin.net> 
Message-ID: <46738.1288961816@tristatelogic.com>


In message <76036B6C-C69D-451D-B2C8-0BBA036428CC at arin.net>, 
John Curran <jcurran at arin.net> wrote:

>Ron -
>
>  ARIN would be happy to study and learn from any/all of your tools and
>  techniques in this area, and would be happy to receive any information
>  that you'd like to send in this area.

I already sent you (in private e-mail) my opinion that it should be fairly
easy to prove, to a preponderance of the evidence, that certain folks who
have been assigned certain /24s (or larger) may only have, say, one or two
hosts per /24 (because they are using the /24 for snowshoe spamming, which
requires LOTS of IPs, but relatively little CPU horsepower or bandwidth.

These snowshoe spammer infestations are the ultimate examples of crappy IP
space utilization, and I know that I can send you a list of hundreds, and
perhaps even thousands of such blocks.

You _might_ be able to verify cases like these (as being clear instances
of ultra-crappy utilization) via such existing tools as nmap.  But if not,
I think that I could whip something together that would do the job for you.
But why would I foolishly invest the time and effort to do that when, for
all I know, you guys may already have (and may already be using) exactly
such software tools.

So this is a good example of how secrecy in your audit process is actually
counterproductive.  You're never going to get any good ideas or any help
from anybody on the outside as long as you cling to this silly notion
that you can make your auditing process unbeatable (or less beatable)
via secrecy.

Maybe you've heard this one before:  Security through obscurity is no
security at all.

If your audit process is so lame that it could be beaten just by being made
public... well then you've ALREADY got a major problem.

Personally, I don't give a flying fig about the paperwork aspect of your
audits.  If it pleases you, then by all means, keep that part of the process
on double-secret probation.  I am only interested in what can be done over
the wire, and I do believe that most if not all of the current crop of
snowshoe frauds can be outted via purely automated ``over the wire'' means.

>  I'll note that some techniques
>  in use by the anti-spam community may not meet the fairness and process
>  requirements that ARIN operates under,

I seriously have no idea what you are talking about.

All of the software that _I_ have ever written is inherently ``fair''... it
operates exactly the same way, no matter who I am using it to investigate.
Human biases don't enter into it.

Do you know about the software tool called "nmap"?  Is that tool "fair"
or "unfair" in your view?

>  and I recognize that this may be
>  annoying to you, but reflects the reality of our legal system.

To reiterate, I have no idea what you are talking about.

The only thing annoying me is that I have no idea what your current audit
process is, and thus I can't figure out _either_ (a) how so many spammers 
already seem to be beating it _or_ (b) how it might be improved so as to
prevent this.

>  If you'd prefer to supply information on your tools and techniques under
>  NDA, please send that to my attention or let me know and I'll send ARIN's
>  NDA out for your review.

No, thank you.  That's getting ahead of ourselves.

In the first instance, I'd just like to know if ARIN is currently employing
_any_ automated ``over the wire'' means to verify or validate claims about
existing network equipment.

Or is your audit process all just based on paperwork, e.g. like reciepts
for network equipment purchases, lists of customers, and so forth.

If the latter, then that would explain, I think, how so many of these spammers
are managing to slip through and aquire so much IPv4 space (which in turn
might also come to explain... in a few years time... how they will have
managed to aquire so much IPv6 address space).


Regards,
rfg


From jcurran at arin.net  Fri Nov  5 09:03:17 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 5 Nov 2010 09:03:17 -0400
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <46738.1288961816@tristatelogic.com>
References: <46738.1288961816@tristatelogic.com>
Message-ID: <F34108F3-1D71-4B46-8099-B8C000A6095A@arin.net>

On Nov 5, 2010, at 8:56 AM, Ronald F. Guilmette wrote:

> But why would I foolishly invest the time and effort to do that when, for
> all I know, you guys may already have (and may already be using) exactly
> such software tools.

Ron - 
 
 You expressed the interest here; I presumed that meant you were were willing to invest time and effort.

 If that is not the case, I understand.

/John

John Curran
President and CEO
ARIN




From rfg at tristatelogic.com  Fri Nov  5 09:16:18 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Fri, 05 Nov 2010 06:16:18 -0700
Subject: [arin-ppml] Low Utilization.
In-Reply-To: <92568641-795E-47D6-BC67-5EAC01BB124F@arin.net> 
Message-ID: <47142.1288962978@tristatelogic.com>


In message <92568641-795E-47D6-BC67-5EAC01BB124F at arin.net>, 
John Curran <jcurran at arin.net> wrote:

>  Low utilization does not create number resource fraud, per se,

I understand that.  Yes, low utilization doesn't create fraud per se, however
if somebody came to you and obtained X (e.g. a /19) by making representation
Y to you (e.g. we're gonna have 300 more customers and 10 additional routers
within six months) and if it turns out that representation Y was just bullcrap,
told to you to get you to part with resource X, well, then, that is pretty
much the dictionary definition of fraud.

You can call it whatever you like, but it is still fraud.

>> And as I also asked you in private e-mail (also without any reply) does
>> ARIN care about and/or will ARIN _do_ anything about deliberately fradulent
>> sub-allocation WHOIS records?
>>...
>If a party requests address space based on fraudulent data, we are very
>interested.  Please report such.

Sorry, but I have to ask... Does what you just said answer the question I
asked?  If so, how?  (Help me out here.  I guess that I'm a little slow on
the uptake, because I actually can't quite decypher how your answer relates
to the question I asked.)


Regards,
rfg


From john.sweeting at twcable.com  Fri Nov  5 09:19:34 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Fri, 5 Nov 2010 09:19:34 -0400
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <46738.1288961816@tristatelogic.com>
Message-ID: <C8F97CA6.17F89%john.sweeting@twcable.com>

Gentlemen,

Would it be too much to ask that we keep the non-policy proposal noise to a minimum?

Ronald,

ARIN has a very workable suggestion program that is tailored made for what you are trying to accomplish:

https://www.arin.net/participate/acsp/index.html

Thanks,
John


+++


On 11/5/10 8:56 AM, "Ronald F. Guilmette" <rfg at tristatelogic.com> wrote:



In message <76036B6C-C69D-451D-B2C8-0BBA036428CC at arin.net>,
John Curran <jcurran at arin.net> wrote:

>Ron -
>
>  ARIN would be happy to study and learn from any/all of your tools and
>  techniques in this area, and would be happy to receive any information
>  that you'd like to send in this area.

I already sent you (in private e-mail) my opinion that it should be fairly
easy to prove, to a preponderance of the evidence, that certain folks who
have been assigned certain /24s (or larger) may only have, say, one or two
hosts per /24 (because they are using the /24 for snowshoe spamming, which
requires LOTS of IPs, but relatively little CPU horsepower or bandwidth.

These snowshoe spammer infestations are the ultimate examples of crappy IP
space utilization, and I know that I can send you a list of hundreds, and
perhaps even thousands of such blocks.

You _might_ be able to verify cases like these (as being clear instances
of ultra-crappy utilization) via such existing tools as nmap.  But if not,
I think that I could whip something together that would do the job for you.
But why would I foolishly invest the time and effort to do that when, for
all I know, you guys may already have (and may already be using) exactly
such software tools.

So this is a good example of how secrecy in your audit process is actually
counterproductive.  You're never going to get any good ideas or any help
from anybody on the outside as long as you cling to this silly notion
that you can make your auditing process unbeatable (or less beatable)
via secrecy.

Maybe you've heard this one before:  Security through obscurity is no
security at all.

If your audit process is so lame that it could be beaten just by being made
public... well then you've ALREADY got a major problem.

Personally, I don't give a flying fig about the paperwork aspect of your
audits.  If it pleases you, then by all means, keep that part of the process
on double-secret probation.  I am only interested in what can be done over
the wire, and I do believe that most if not all of the current crop of
snowshoe frauds can be outted via purely automated ``over the wire'' means.

>  I'll note that some techniques
>  in use by the anti-spam community may not meet the fairness and process
>  requirements that ARIN operates under,

I seriously have no idea what you are talking about.

All of the software that _I_ have ever written is inherently ``fair''... it
operates exactly the same way, no matter who I am using it to investigate.
Human biases don't enter into it.

Do you know about the software tool called "nmap"?  Is that tool "fair"
or "unfair" in your view?

>  and I recognize that this may be
>  annoying to you, but reflects the reality of our legal system.

To reiterate, I have no idea what you are talking about.

The only thing annoying me is that I have no idea what your current audit
process is, and thus I can't figure out _either_ (a) how so many spammers
already seem to be beating it _or_ (b) how it might be improved so as to
prevent this.

>  If you'd prefer to supply information on your tools and techniques under
>  NDA, please send that to my attention or let me know and I'll send ARIN's
>  NDA out for your review.

No, thank you.  That's getting ahead of ourselves.

In the first instance, I'd just like to know if ARIN is currently employing
_any_ automated ``over the wire'' means to verify or validate claims about
existing network equipment.

Or is your audit process all just based on paperwork, e.g. like reciepts
for network equipment purchases, lists of customers, and so forth.

If the latter, then that would explain, I think, how so many of these spammers
are managing to slip through and aquire so much IPv4 space (which in turn
might also come to explain... in a few years time... how they will have
managed to aquire so much IPv6 address space).


Regards,
rfg
_______________________________________________
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.


________________________________
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 jcurran at arin.net  Fri Nov  5 09:42:22 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 5 Nov 2010 09:42:22 -0400
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <C8F97CA6.17F89%john.sweeting@twcable.com>
References: <C8F97CA6.17F89%john.sweeting@twcable.com>
Message-ID: <3594769B-DB35-49AE-B897-F89DD61C006A@arin.net>

On Nov 5, 2010, at 9:19 AM, Sweeting, John wrote:

> Gentlemen,
> 
> Would it be too much to ask that we keep the non-policy proposal noise to a minimum?
> 
> Ronald,
> 
> ARIN has a very workable suggestion program that is tailored made for what you are trying to accomplish:
> 
> https://www.arin.net/participate/acsp/index.html

Ron - 
 
 Mr. Sweeting is correct on this point: PPML is for discussing issues related to ARIN policies, and in particular discussion of policy proposals and draft policies.

 If you wish to submit a policy change, instructions are here: <https://www.arin.net/policy/pdp_appendix_b.html>

 Suggestions to ARIN's operational policies can be made here: <https://www.arin.net/participate/acsp/index.html>

 You already know how to submit fraud reports (and we've investigated and pulled more than a dozen allocations as a result) but here's the link for completeness:  <https://www.arin.net/resources/fraud/index.html>

 If you have additional questions about our audit practices, please feel free to write me and I will respond.

Best,
/John

John Curran
President and CEO
ARIN



From stephen at sprunk.org  Fri Nov  5 12:25:56 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 05 Nov 2010 11:25:56 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net> <4CD382AB.1030107@sprunk.org>
	<C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
Message-ID: <4CD43014.9050606@sprunk.org>

On 05 Nov 2010 01:56, Owen DeLong wrote:
> On Nov 4, 2010, at 9:06 PM, Stephen Sprunk wrote:
>> On 02 Nov 2010 22:30, Ted Mittelstaedt wrote:
>>> I think that this is because ultimately the goal isn't to take
>>> legacy resources away that are IN USE.
>> IMHO, that depends on the degree of non-compliance.  I've worked with dozens of orgs with legacy space, and not a single one of them could even come close to justifying their space _that was in use_.
>>
>> However, I don't see any point in targeting orgs using their space inefficiently until we've dealt with all the ones (and I really do mean every last one that can be found) not using their space _at all_.
> IMHO, targeting legacy holders for non-compliance with today's ARIN policies is dubious at best.

I understand there are differences of opinion here; more on that below.

> I agree we should seek to actively reclaim abandoned resources (resources where the ORG no longer exists). I think we should possibly reach out and request that ORGs no longer using their legacy resources voluntarily return them.

I think we all agree on this much, which is why it seems a rather
obvious first step.  Once this is underway, we can debate what (if
anything) can/should be done about the other group.

>>> Ultimately the goal should be to take legacy resources away that are either being hoarded, or are abandoned.
>> "Hoarded" is a loaded term, and it's difficult to prove someone's doing it.  "Justified" is easily determined, though, since we _already_ have dozens of pages of policy describing exactly what that means.
> What we don't have is any form of agreement by the legacy holders that the ARIN definition of justified applies to them.

OTOH, absent an LRSA, there is no formal agreement that it doesn't.

> Non-signatories to the LRSA are, thus, in an uncertain area. Signatories of the LRSA are clearly protected from current and future ARIN policies in this regard.

Yes, that's an excellent carrot for folks to sign the LRSA.  We disagree
only about the stick.

I don't like using sticks, but eventually we're going to run out of
folks that are interested in the carrot.

>>> Rubbish. If ARIN takes over an abandoned Legacy resource then since
>>> it is abandoned, the original org that had it cannot suffer damages,
>>> and since it hasn't suffered damages, it has no standing to sue in
>>> court.
>>>
>>> The problem is that since the original Legacy holder did NOT ever
>>> sign an agreement with ARIN then ARIN has no contractual
>>> justification to take over an abandoned Legacy assignment even if
>>> they know it's unused,
>> AFAICT, if the registrant does not have a contract (i.e. RSA or LRSA) with ARIN for registry services, ARIN has no obligation to continue providing them, especially for free.  There are many who feel ARIN has a _moral_ obligation to do so, but that's not a matter for the courts.
> I agree that ARIN has a moral obligation to legacy holders.

I agree ARIN has some sort of moral obligation to provide services, but
that is in direct conflict with ARIN's charter to act as steward for the
entire community.

I was willing to accept granting special privileges to _all_ legacy
holders prior to the LRSA being made available; now that it is, though,
I'm reluctant to accept continuing to grant those same special
privileges to those who do not sign.

> I am uncertain about what legal obligations ARIN has to legacy holders.

We've been told in the past we should make policy we think is "right"
for the community and let ARIN's counsel inform us if there are legal
problems with our proposals.

Counsel rarely participates in policy discussions prior to a formal
proposal being on the table, so a bit of armchair lawyering is probably
unavoidable, but it shouldn't dominate the discussion.

> I think that involuntary reclamation of legacy resources or "termination of services" to legacy holders is contrary to ARIN's best interests.

I disagree.

> I think that going beyond "termination of services" to the step of placing resources back into the free pool and issuing them to other organizations would be outright counter-productive for all concerned (except in the case of clear abandonment).

It depends on the legal explanation of exactly what it is ARIN does.  At
the end of the day, the "resources" that ARIN "issues" to registrants
are merely entries in WHOIS and rDNS.  ARIN cannot actually issue
numbers to (or take them away from) registrants because numbers
themselves cannot be owned, leased, etc.

I do not see a significant difference between removing a non-paying
registrant's entries from WHOIS/rDNS and replacing them with a paying
registrant's entries that happen to have the same or similar numbers. 
And, frankly, if we don't do the latter, what's the point in the
former?  Marking a bunch of space as "permanently unavailable"
accomplishes little.

>>> because so far the community has not given ARIN permission to do this via policy in the NRPM.
>> That all depends on how one interprets NRPM 12.8.
>>
>> IMHO, ARIN _already_ had the power to apply policy to legacy space or revoke it entirely, and therefore NRPM 12 actually _limits_ how ARIN may do so, as it does for non-legacy resources.
> Where did this power come from? For non-legacy holders, it comes from
> the RSA which is a binding contract between the resource holder and ARIN
> which entitles ARIN to revoke resources according to the NRPM.
>
> There is no document anywhere that I know of which gives ARIN any such authority to revoke legacy resources based on current ARIN policy where it differs from the policies in effect under which the legacy resources were issued.

I forget the original Latin, but there's a famous legal principle that
"what is not illegal must be legal".

ARIN can add or remove any WHOIS/rDNS entry it wishes unless restricted
by policy or by a contract, i.e. an RSA or LRSA.  IOW, since non-LRSA
legacy holders have no contract restricting what ARIN does, they have no
(legal) standing to complain if ARIN decides to stop providing them
unpaid, uncontracted registry services--just like a homeless person has
no (legal) standing to complain if a shelter decides to stop giving them
free meals.  That's purely a moral issue.

>> Wrong. ARIN would need to follow the procedure in NRPM 12, which
>> governs _all_ reclamation activities.
>>
>> However, if all the POCs are unresponsive, then presumably they will
>> not respond with justification as required in 12.1, they will not
>> voluntarily return the resource(s) as required in 12.4, and
>> eventually ARIN can revoke the resource(s) under 12.5.
> Presumably the later stages of POC validation would include the notices
> required under 12.1 such that by the time the POCs were marked invalid,
> we would have at least completed the 12.4 waiting period as well, thus
> making 12.5 effective pretty much as described above.

That would be convenient.

>> One can address most of those by having other processes that add to the same list of resources to be reviewed.  For instance, one might consider a resource not appearing in the DFZ to be a sign of probable non-compliance which triggers a review.  Or resources which have not been updated in the last N years.  Or not having valid rDNS servers.  If the review concludes they're valid, the registrant has 24 months before they have to worry about being hassled again.
> There are specific policies allowing for non-connected networks and always have been. Why would the fact that a resource does not appear in one particular view (or even several views) of the DFZ be considered a sign of probable non-compliance? As to update cycle, some organizations
> are actually extremely stable. ... When did maintaining valid rDNS become a requirement even for a non-legacy holder? I can't find that requirement anywhere in the NRPM.

Those are merely possible reasons to put someone into the review queue. 
If it turns out their use is justified (or close to it), no action will
be taken against them and they're exempt from another without-cause
review for 24 months.

This is _precisely_ why I put that clause in 2007-14: to clarify that
ARIN could review resources that _appeared_ to be unjustified without
needing a priori proof of such.  The remainder of 2007-14 is there to
make sure that, when ARIN makes use of this power, the registrant is
protected.  I believe that ARIN has _always_ had this power, but the
response to an ACSP suggestion of mine indicated that ARIN was
uncomfortable wielding that power without explicit policy supporting it.

> What value of N would you propose? 5? 10? 15?

I would propose N=15 to start with, reducing over time as this
particular method ran out of folks to review.  I don't think it'd be
wise to go below N=5.

>> Yes, a sufficiently cagey registrant may be able to avoid all of our heuristics, but most won't even try to.  It's reasonable to lose a battle to a skilled and dedicated opponent; it's absolutely indefensible to surrender a battle when your opponent doesn't even show up, which is where we are right now.  Let's fix the latter problem before we worry about the former.
> When did this shift from stewardship to seeking battles with legacy
> holders? That certainly was not my intent in NRPM 12.

It's a metaphor.

>> I don't think that "mining" IPv4 blocks for reclamation will have any
>> meaningful effect on runout, but I still think it's worthwhile for
>> several other reasons.
> I understand the "other reasons" for reclamation of abandoned resources.
> They're a good target for abuse.

Agreed, and IMHO that's a good enough reason by itself.

> What reasons do you have for actively seeking to reclaim legacy resources that are not abandoned ... ?

Primarily, it is the moral obligation we have to the _entire community_
to act as stewards in an impartial manner, and IMHO that overrides any
moral obligation we have to individual registrants--particularly ones
that refuse to participate in the community or take advantage of the
(exceedingly generous, IMHO) terms that the LRSA offers.

Also, I am concerned about the complaints (and potential legal action)
ARIN will face if we start actively reclaiming non-legacy resources but
do not attempt to reclaim (non-LRSA) legacy resources.  Worse, showing
irresponsibility here may justify attempts by others to impose
governmental (i.e. ITU) interference or end community-based governance
entirely.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101105/84f0518c/attachment.p7s>

From bill at herrin.us  Fri Nov  5 12:53:42 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Nov 2010 12:53:42 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
Message-ID: <AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>

On Thu, Nov 4, 2010 at 9:58 AM, John Curran <jcurran at arin.net> wrote:
> Actually, I was providing clarity regarding the
> state of the registry information on legacy resources
> and what constitutes number resource fraud. ?I thought
> that was what you were asking about, but easily could
> have been wrong.

Hi John,

I'm still missing some clarity on this issue. I wonder if policy in
this area could be improved? Would you mind answering a couple of
questions for me?

>From what I observed, Ron offered a list of more than 30 ARIN-managed
IPv4 allocations which were (to a moderate degree of confidence)
abandoned and (to a lesser degree of confidence) associated with
defunct organizations.

1. Did ARIN make any assessment as to whether any of the allocations
were abandoned by their registrant? Why or why not?

2. Did ARIN make any assessment as to whether any of the associated
resource holders were defunct? Why or why not?

3. Based on any assessments made, did ARIN initiate any audit or
recovery actions? Why or why not?

Thanks,
Bill Herrin



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


From stephen at sprunk.org  Fri Nov  5 13:07:42 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 05 Nov 2010 12:07:42 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <45933.1288959601@tristatelogic.com>
References: <45933.1288959601@tristatelogic.com>
Message-ID: <4CD439DE.3060205@sprunk.org>

On 05 Nov 2010 07:20, Ronald F. Guilmette wrote:
> In message <E44E6428-C3AA-48A6-82A2-9FA24E98E018 at delong.com>, 
> Owen DeLong <owen at delong.com> wrote:
>> On Nov 5, 2010, at 12:53 AM, Ronald F. Guilmette wrote:
>>> In message <DDE139AF-24A9-4F9A-B524-2CB78272E735 at delong.com>,
>>> Owen DeLong <owen at delong.com> wrote:
>>>> Why? There are very good reasons for ARIN not to publicly disclose the techniques and methods they use for conducting these audits.
>>> I'm listening.  What are those?  Do they outweigh the many obvious good reasons to have a clear and transparent statement of the process that all members know they may be held to, without
>>> prejudice or favor?
>> The process is documented in NRPM12 and is pretty clear.
> I think not.  NRPM Section 12 describes in great detail _who_ may be audited and _when_ they may be audited.  It doesn't say a damn thing about the ``how'' of auditing.

That's partly because doing so would make the system easier to game, but
mainly because different organizations have different types of records
available and we want to make the process as painless as possible for
legitimate applicants.  The review process imports the same goal and
documentation requirements.

> In this country, at least, we tend to favor the transparent, and the
> public, over the secret and hidden. In the words of late Supreme Court
> Justice Louis Brandeis, ``Sunlight is the best disinfectant''.

I agree, but we're dealing with information that may be considered trade
secrets and, in the case of some registrants, matters of national security.

> Secrecy breeds suspicion.  And when I and others see some of the stuff that's been going on... like the stuff attached to the end of this message...  we _do_ start to wonder what _really_ goes on inside of ARIN.

IMHO, your problem is not secrecy but rather ARIN's bias toward making
things as easy as possible for registrants and the presumption that any
reasonable-looking documentation is legitimate unless proven otherwise. 
Notice the direct parallel to "innocent until proven guilty".

The "how" is not really secret anyway:

1. Give ARIN your documentation.
2. If it is sufficient to support the conclusion the space is justified,
go to step 5.
3. ARIN asks for more documentation.
4. Go to step 1.
5. Get/keep space.

If this isn't written down anywhere, I suspect that's because those
involved in writing policy find it too obvious to bother.

> I could go on and on.  The problem isn't finding this stuff.  The problem is finding anybody in the ARIN community or in ARIN management who gives a damn.

They do care, but they cannot _act_ on your accusations without
following the process, nor can they tell you what they discover during
the process due to NDAs.

Note that it's entirely possible that the folks you've accused _have_
presented ARIN with sufficient documentation to demonstrate policy
compliance, which precludes revocation.

>> As I see it, even if you consider "rampant and profligate waste", you 
>> might expect
>> ARIN to reclaim, what, maybe 10 /8s worth of space over the next 5 
>> years? The
>> internet is consuming 2 /8s per month. 2 per year isn't even a drop in 
>> the bucket.
> And who exactly is giving out those two /8s per month?

The RIRs.

> And what, if anything, are those folks doing to encourage the wider use of NAT and/or to educate the space-consuming community about its proper use and potential?

NAT is evil, and therefore current policy does not require its use.  If
you'd like to see that changed, please submit a policy proposal.  I'm
sure someone from the AC would be happy to help if needed.  I'm not
optimistic about the community accepting such a proposal, though.

>> Like it or not, reclamation is a slow, deliberate, careful process that takes significant time.
> Someone else here was just suggested a few ideas to speed that all up.
> And those sounded pretty reasonable to me.

It's still a deliberate, careful process.  With the alleged amount of
fraud out there and ARIN's current staffing, it will take a long, long
time to sift through it all.

>> ... please present evidence.
> See below.  As I have said, there's plenty more where this came from.
> And I really would like to know how non-existant entities managed to get
> so much space allocated to them from ARIN.  It is truly stunning.
>
> Yea yea yea.  I know what you are going to say... ``We can't tell you because it is all confidential and all under NDA.''  Yea.  Right.  Bullcrap.  Please explain gto me how ARIN has _any_ binding contractual commitments to totally fradulent/fabricated entities which themselves have no legal existance?
>
> This I gotta hear.
>
> Take your time.

ARIN is bound by the contracts it signs until proven otherwise.  Proving
a contract is invalid takes time and money for lawyers to sort things
out.  If you're an ARIN member, you can speak up at the next members'
meeting and ask that ARIN increase your fees to pay for more lawyers. 
Again, I'm not optimistic about the community accepting that.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101105/4904ab91/attachment.p7s>

From jcurran at arin.net  Fri Nov  5 13:55:44 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 5 Nov 2010 13:55:44 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
Message-ID: <71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>

On Nov 5, 2010, at 12:53 PM, William Herrin wrote:
> From what I observed, Ron offered a list of more than 30 ARIN-managed
> IPv4 allocations which were (to a moderate degree of confidence)
> abandoned and (to a lesser degree of confidence) associated with
> defunct organizations.
> 
> 1. Did ARIN make any assessment as to whether any of the allocations
> were abandoned by their registrant? Why or why not?

Bill - 
 
  We investigate all Internet number resource fraud reports that are 
  submitted to <https://www.arin.net/resources/fraud/index.html>  We 
  do not investigate allegations made on the mailing lists, and for 
  the sake of the mailing list subscribers do not intend to change 
  that practice.

> 2. Did ARIN make any assessment as to whether any of the associated
> resource holders were defunct? Why or why not?
> 
> 3. Based on any assessments made, did ARIN initiate any audit or
> recovery actions? Why or why not?


  Findings of Internet number resource fraud reports are posted on 
  online also at <https://www.arin.net/resources/fraud/index.html>. 
  We've also increased the level of detail in the findings reports
  in recent quarters per community request.

  (As I have noted already, Ron has submitted several number resource 
  fraud reports recently which have resulted in more than a dozen 
  address blocks being reclaimed as a result...)

/John

John Curran 
President and CEO
ARIN



From bicknell at ufp.org  Fri Nov  5 14:19:27 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 5 Nov 2010 11:19:27 -0700
Subject: [arin-ppml] Audits
In-Reply-To: <71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
Message-ID: <20101105181927.GA56626@ussenterprise.ufp.org>

In a message written on Fri, Nov 05, 2010 at 01:55:44PM -0400, John Curran wrote:
>   We investigate all Internet number resource fraud reports that are 
>   submitted to <https://www.arin.net/resources/fraud/index.html>  We 
>   do not investigate allegations made on the mailing lists, and for 
>   the sake of the mailing list subscribers do not intend to change 
>   that practice.

_I_ would like to see ARIN be much more proactive in looking for
fraud, abuse, defunct companies, and any other odd situations that
might exist.

I think it is great that ARIN has the fraud reporting page and
responds to the community's reports.  However I also strongly believe
that ARIN is in posession of a lot of information that cannot be
made public, but could be used to track down fraud and abuse.  For
instance were someone to lie on their form to ARIN, the community
will never see the form, and never be able to report the fraud.

I understand and support that ARIN needs to be conservative in any
proactive approch.  However being conservative is not an excuse to
do nothing.  It is my personal feeling that the ARIN community has
been screaming via policy and the ASCP for years for ARIN staff to
proactively do more, and yet the tone of your reponses to the mailing
list suggest to me that ARIN is waiting for some clearer sign.

Let me ask the $64,000 question point blank:

  What would the community have to get the ARIN staff to go proactively
  looking for fraud, abuse, defunct companies and other non-compliant
  uses of the address space?

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101105/ceec29dc/attachment.sig>

From jcurran at arin.net  Fri Nov  5 14:49:13 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 5 Nov 2010 14:49:13 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <20101105181927.GA56626@ussenterprise.ufp.org>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
Message-ID: <8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>

On Nov 5, 2010, at 2:19 PM, Leo Bicknell wrote:
>  What would the community have to get the ARIN staff to go proactively
>  looking for fraud, abuse, defunct companies and other non-compliant
>  uses of the address space?

As usual: have the community develop an appropriate policy and ensure that 
there is an adequate level of support for the increased ARIN costs (which 
will appear back as overall service fees) once we get to implementation.

/John

John Curran
President and CEO
ARIN



From tedm at ipinc.net  Fri Nov  5 16:06:36 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Nov 2010 13:06:36 -0700
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <F34108F3-1D71-4B46-8099-B8C000A6095A@arin.net>
References: <46738.1288961816@tristatelogic.com>
	<F34108F3-1D71-4B46-8099-B8C000A6095A@arin.net>
Message-ID: <4CD463CC.3090107@ipinc.net>

On 11/5/2010 6:03 AM, John Curran wrote:
> On Nov 5, 2010, at 8:56 AM, Ronald F. Guilmette wrote:
>
>> But why would I foolishly invest the time and effort to do that when, for
>> all I know, you guys may already have (and may already be using) exactly
>> such software tools.
>
> Ron -
>
>   You expressed the interest here; I presumed that meant you were were willing to invest time and effort.
>
>   If that is not the case, I understand.
>
>

John and Ron,

   I will remind you both that Section 3.6.1 states:

"...ARIN will maintain, and make readily available to the community, a 
current list of number resources with no valid POC; this data will be 
subject to the current bulk Whois policy...."

   I would recommend that any "auditing" be concentrated on this list FIRST.

   John, please provide the URL for this list and Ron can do his
auditing on that.

Ted



From tedm at ipinc.net  Fri Nov  5 16:18:22 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Nov 2010 13:18:22 -0700
Subject: [arin-ppml] Low Utilization.
In-Reply-To: <47142.1288962978@tristatelogic.com>
References: <47142.1288962978@tristatelogic.com>
Message-ID: <4CD4668E.9050108@ipinc.net>

On 11/5/2010 6:16 AM, Ronald F. Guilmette wrote:
>
> In message<92568641-795E-47D6-BC67-5EAC01BB124F at arin.net>,
> John Curran<jcurran at arin.net>  wrote:
>
>>   Low utilization does not create number resource fraud, per se,
>
> I understand that.  Yes, low utilization doesn't create fraud per se, however
> if somebody came to you and obtained X (e.g. a /19) by making representation
> Y to you (e.g. we're gonna have 300 more customers and 10 additional routers
> within six months) and if it turns out that representation Y was just bullcrap,
> told to you to get you to part with resource X, well, then, that is pretty
> much the dictionary definition of fraud.
>
> You can call it whatever you like, but it is still fraud.
>
>>> And as I also asked you in private e-mail (also without any reply) does
>>> ARIN care about and/or will ARIN _do_ anything about deliberately fradulent
>>> sub-allocation WHOIS records?
>>> ...
>> If a party requests address space based on fraudulent data, we are very
>> interested.  Please report such.
>
> Sorry, but I have to ask... Does what you just said answer the question I
> asked?  If so, how?  (Help me out here.  I guess that I'm a little slow on
> the uptake, because I actually can't quite decypher how your answer relates
> to the question I asked.)
>
>

The problem here is that fraud requires intent.

If "PetSockPuppet Company" has this really great business plan, lots of
money from investors and gets a /8 from ARIN based on that - then a year
later is bankrupt, and then the bankruptcy holding company sets on the
/8 for the next decade, that does NOT meet the legal definition of 
fraud.  But, the resources are tied up just the same as if a current 
concern lied to get the /8 to spam with.

True story, Southern Pacific Funding, their bankruptcy is public record, 
they are STILL PAYING for a website.

Their bankruptcy was a decade ago.

This kind of thing is far, far more common than you would think.

Ted


From jcurran at arin.net  Fri Nov  5 16:23:06 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 5 Nov 2010 16:23:06 -0400
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <4CD463CC.3090107@ipinc.net>
References: <46738.1288961816@tristatelogic.com>
	<F34108F3-1D71-4B46-8099-B8C000A6095A@arin.net>
	<4CD463CC.3090107@ipinc.net>
Message-ID: <6ADA4C3D-8615-4F3E-8E0A-90A4F330274C@arin.net>

On Nov 5, 2010, at 4:06 PM, Ted Mittelstaedt wrote:
> 
> "...ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy...."
> 
>  I would recommend that any "auditing" be concentrated on this list FIRST.
> 
>  John, please provide the URL for this list and Ron can do his
> auditing on that.

Ted - 
   We're actively working on the automation to generate this list.  I'll provide an ETA shortly.
/John

John Curran
President and CEO
ARIN



From tedm at ipinc.net  Fri Nov  5 16:30:58 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Nov 2010 13:30:58 -0700
Subject: [arin-ppml] Fraud reporting and self-incrimination
Message-ID: <4CD46982.5070505@ipinc.net>


It occurs to me that if a network manager at an org that fraudulently
obtained IP addressing from ARIN were to be, lets say, fired, and if
in revenge he were to contact ARIN and be willing to provide testimony
under deposition that he knowingly fraudulently obtained said resources,
that any decent attorney would tell him before he opened his mouth
to ARIN that he secure a guarantee from ARIN that he would NOT be
prosecuted for breaking the law. (ie: a whistle-blower clause)  Said
attorney might also advise that the org might obtain his name through
legal discovery and proceed to file a civil lawsuit for NDA or trade
secret violations, would they not?

If such a guarantee does not currently exist, it would seem to be to
be a very large deterrent to such ex-employees blowing the whistle.

Perhaps ARIN might find their fraud reporting greatly enhanced if they
were to publish that they offer whistle blower protection?

I don't see that ARIN can really do much with anonymous reporting of
fraud cases.  If ARIN gets an anonymous report from an ex-employee of
fraud, and they pull resources from an org, and that org sues ARIN for
breech of contract, then what evidence does ARIN have?  An anonymous 
report is not going to be usable to ARIN to defend itself in a court.

Comments?

Ted




From mloftis at wgops.com  Fri Nov  5 17:08:19 2010
From: mloftis at wgops.com (Michael Loftis)
Date: Fri, 5 Nov 2010 15:08:19 -0600
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <4CD46982.5070505@ipinc.net>
References: <4CD46982.5070505@ipinc.net>
Message-ID: <AANLkTikgrV5CbEv1ex7oj36D-fS9dL4WNaB6-Kw0u8Yh@mail.gmail.com>

On Fri, Nov 5, 2010 at 2:30 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>
> It occurs to me that if a network manager at an org that fraudulently
> obtained IP addressing from ARIN were to be, lets say, fired, and if
> in revenge he were to contact ARIN and be willing to provide testimony
> under deposition that he knowingly fraudulently obtained said resources,
> that any decent attorney would tell him before he opened his mouth
> to ARIN that he secure a guarantee from ARIN that he would NOT be
> prosecuted for breaking the law. (ie: a whistle-blower clause) ?Said
> attorney might also advise that the org might obtain his name through
> legal discovery and proceed to file a civil lawsuit for NDA or trade
> secret violations, would they not?

IANAL but *my* understanding is that  whistle-blower laws are
specifically there to protect in cases such as this.  NDAs/etc should
NOT be usable against (atleast americans) someone reporting a crime.
ARIN need not offer any extra protection/liability if there is indeed
a crime.  It doesn't mean that a company can't *try* a case against a
whistle-blower unfortunately.  However, IANAL, but it seems that this
is contract or civil law, not criminal law (IE breach of contract) so
the whistle-blower laws may not apply at all.

>
> If such a guarantee does not currently exist, it would seem to be to
> be a very large deterrent to such ex-employees blowing the whistle.
>
> Perhaps ARIN might find their fraud reporting greatly enhanced if they
> were to publish that they offer whistle blower protection?
>
> I don't see that ARIN can really do much with anonymous reporting of
> fraud cases. ?If ARIN gets an anonymous report from an ex-employee of
> fraud, and they pull resources from an org, and that org sues ARIN for
> breech of contract, then what evidence does ARIN have? ?An anonymous report
> is not going to be usable to ARIN to defend itself in a court.
>
> Comments?
>
> 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 bill at herrin.us  Fri Nov  5 17:16:13 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Nov 2010 17:16:13 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
Message-ID: <AANLkTi=663+exYjzM88bAhQGUcaUd7b8-MTZf_o8MYeC@mail.gmail.com>

On Fri, Nov 5, 2010 at 1:55 PM, John Curran <jcurran at arin.net> wrote:
> ?We investigate all Internet number resource fraud reports that are
> ?submitted to <https://www.arin.net/resources/fraud/index.html> ?We
> ?do not investigate allegations made on the mailing lists, and for
> ?the sake of the mailing list subscribers do not intend to change
> ?that practice.

Thanks John,

I just want to be clear: under current policy, ARIN considers itself
empowered (metaphorically speaking) to act on calls to 911. If the
officer on the corner observes a mugging, he will not give chase until
someone calls 911 to report the crime.

IF we want ARIN to proactively monitor forums where reports of number
resource misappropriation tend to first surface and initiate action
based on information gained there, we would need to draft policy to
that effect.

Do I correctly understand?


> ?Findings of Internet number resource fraud reports are posted on
> ?online also at <https://www.arin.net/resources/fraud/index.html>.
> ?We've also increased the level of detail in the findings reports
> ?in recent quarters per community request.
>
> ?(As I have noted already, Ron has submitted several number resource
> ?fraud reports recently which have resulted in more than a dozen
> ?address blocks being reclaimed as a result...)

Thanks John. As always, I appreciate the great work you guys do.

Regards,
Bill Herrin




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


From tedm at ipinc.net  Fri Nov  5 17:28:06 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Nov 2010 14:28:06 -0700
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTi=663+exYjzM88bAhQGUcaUd7b8-MTZf_o8MYeC@mail.gmail.com>
References: <27141.1288874999@tristatelogic.com>	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<AANLkTi=663+exYjzM88bAhQGUcaUd7b8-MTZf_o8MYeC@mail.gmail.com>
Message-ID: <4CD476E6.5070600@ipinc.net>

On 11/5/2010 2:16 PM, William Herrin wrote:
> On Fri, Nov 5, 2010 at 1:55 PM, John Curran<jcurran at arin.net>  wrote:
>>   We investigate all Internet number resource fraud reports that are
>>   submitted to<https://www.arin.net/resources/fraud/index.html>    We
>>   do not investigate allegations made on the mailing lists, and for
>>   the sake of the mailing list subscribers do not intend to change
>>   that practice.
>
> Thanks John,
>
> I just want to be clear: under current policy, ARIN considers itself
> empowered (metaphorically speaking) to act on calls to 911. If the
> officer on the corner observes a mugging, he will not give chase until
> someone calls 911 to report the crime.
>
> IF we want ARIN to proactively monitor forums where reports of number
> resource misappropriation tend to first surface and initiate action
> based on information gained there, we would need to draft policy to
> that effect.
>
> Do I correctly understand?
>

I would oppose such proactive monitoring.  The mailing list's usefulness
would be curtailed if people were looking over their shoulders.  I
personally do not believe that hypothetical examples are anywhere near
as effective as real examples.

Witness my recent example of Leatherman Tools.  I do not believe they
are involved in fraud which is why I would not report them as fraud
to ARIN.  I do not want to have to worry about some young eager intern
at ARIN who is scanning the mailing list and comes across their name
and does not take the time to read the example or history, and then goes
and causes trouble for them.

However, clearly the fact that I used a real life example and named
names, pretty much blew the "we don't have a problem" ship right out
of the water.  I consider that a benefit to discussion that would
have not been achieved with another hypothetical example.

I would also point out that in the past people have mentioned examples
of large cable providers (you can dig the names out of the list archives
if you want) using /29's on point-to-point links as padded assignments
intended to reserve IPv4 within the rules.  Once more, very useful for
discussion, pretty useless for the torches and pichfork crowd.

Ted

>
>>   Findings of Internet number resource fraud reports are posted on
>>   online also at<https://www.arin.net/resources/fraud/index.html>.
>>   We've also increased the level of detail in the findings reports
>>   in recent quarters per community request.
>>
>>   (As I have noted already, Ron has submitted several number resource
>>   fraud reports recently which have resulted in more than a dozen
>>   address blocks being reclaimed as a result...)
>
> Thanks John. As always, I appreciate the great work you guys do.
>
> Regards,
> Bill Herrin
>
>
>
>



From stephen at sprunk.org  Fri Nov  5 17:31:34 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 05 Nov 2010 16:31:34 -0500
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <4CD46982.5070505@ipinc.net>
References: <4CD46982.5070505@ipinc.net>
Message-ID: <4CD477B6.1070007@sprunk.org>

On 05 Nov 2010 15:30, Ted Mittelstaedt wrote:
> It occurs to me that if a network manager at an org that fraudulently
> obtained IP addressing from ARIN were to be, lets say, fired, and if
> in revenge he were to contact ARIN and be willing to provide testimony
> under deposition that he knowingly fraudulently obtained said
> resources, that any decent attorney would tell him before he opened
> his mouth to ARIN that he secure a guarantee from ARIN that he would
> NOT be prosecuted for breaking the law. (ie: a whistle-blower clause) 
> Said attorney might also advise that the org might obtain his name
> through legal discovery and proceed to file a civil lawsuit for NDA or
> trade secret violations, would they not?

My understanding is that only the relevant District or US Attorney can
offer immunity against criminal prosecution.  ARIN could promise not to
press charges (has it _ever_ done so?), but they cannot stop a
prosecutor who chooses to prosecute said fraud cases of their own volition.

In theory, ARIN could indemnify a whistle-blower against a civil suit by
the blowee, but that'd expose ARIN to all sorts of legal liability that
it is not currently exposed to today, which means higher fees for
everyone.  I couldn't support that.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101105/b0d9675b/attachment.p7s>

From mpetach at netflight.com  Fri Nov  5 18:54:49 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 5 Nov 2010 15:54:49 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <4CCAF8EA.7080109@arin.net>
References: <4CCAF8EA.7080109@arin.net>
Message-ID: <AANLkTinPL_Qs7KACppc+XaFf3P1Kd7Utt1yUdJ2Su-G=@mail.gmail.com>

I actually just have one question that's really about the subject
matter at hand; apologies in advance for drifting off topic back
to the original post.  :(

On Fri, Oct 29, 2010 at 9:40 AM, ARIN <info at arin.net> wrote:
...
> 6. No Transfer Rights
> Address space assigned from the Reclamation Pool may be transferred if
> there is either an ICANN Board ratified global policy or globally
> coordinated RIR policy specifically written to deal with transfers
> whether inter-RIR or from one entity to another. Transfers must meet the
> requirements of such a policy. In the absence of such a policy, no
> transfers of any kind related to address space allocated or assigned
> from the reclamation pool is allowed.

ARIN has a specified transfer listing service, and currently allows
for transfers within its region.  Is there a particular reason we need to
split address space into two categories, that which can be transferred
and that which cannot?  Why does the date on which address space
is allocated or assigned determine whether or not the space can ever
be transferred, in perpetuity?

We already have mechanisms in place to prevent abuse within the
transfer policy; I see no reason to artificially create two different
categories of address space like this.

I would support this policy, with the adjustment of section 6 to allow
for RIR-based transfer policies, like the one currently present in the
ARIN region; trying to develop a coordinated transfer policy across
all regions, all RIRs I consider to be an unnecessary burden on
this proposal.

And now, you may return to your current rant-filled thread.  ^_^;

Matt


From cgrundemann at gmail.com  Fri Nov  5 19:25:28 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 5 Nov 2010 17:25:28 -0600
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal): Global
 Policy for IPv4 Allocations by the IANA Post Exhaustion - Last Call (text
 revised)
In-Reply-To: <AANLkTinPL_Qs7KACppc+XaFf3P1Kd7Utt1yUdJ2Su-G=@mail.gmail.com>
References: <4CCAF8EA.7080109@arin.net>
	<AANLkTinPL_Qs7KACppc+XaFf3P1Kd7Utt1yUdJ2Su-G=@mail.gmail.com>
Message-ID: <AANLkTimo8-KeJWtgBXwwH=qYT=UjyndHU9PEvNk+LbXg@mail.gmail.com>

On Fri, Nov 5, 2010 at 16:54, Matthew Petach <mpetach at netflight.com> wrote:
> I actually just have one question that's really about the subject
> matter at hand; apologies in advance for drifting off topic back
> to the original post. ?:(
>
> On Fri, Oct 29, 2010 at 9:40 AM, ARIN <info at arin.net> wrote:
> ...
>> 6. No Transfer Rights
>> Address space assigned from the Reclamation Pool may be transferred if
>> there is either an ICANN Board ratified global policy or globally
>> coordinated RIR policy specifically written to deal with transfers
>> whether inter-RIR or from one entity to another. Transfers must meet the
>> requirements of such a policy. In the absence of such a policy, no
>> transfers of any kind related to address space allocated or assigned
>> from the reclamation pool is allowed.
>
> ARIN has a specified transfer listing service, and currently allows
> for transfers within its region. ?Is there a particular reason we need to
> split address space into two categories, that which can be transferred
> and that which cannot? ?Why does the date on which address space
> is allocated or assigned determine whether or not the space can ever
> be transferred, in perpetuity?
>
> We already have mechanisms in place to prevent abuse within the
> transfer policy; I see no reason to artificially create two different
> categories of address space like this.

We (in the ARIN region) do have mechanisms in place. This may not be
true in all regions. If it is true today, it may not remain true in
the future. If one RIR (or worse several) fails to have such
mechanisms in place (or removes them after the fact), that region
could become something of a black hole for IPv4 space returned to the
IANA.

If we allow this possibility, then it is very unlikely that the other
regions (including ARIN) would ever return any space (for fear that it
will be sucked away), thus negating the purpose of this policy. Hence
the restriction - to create a level playing field in order to
facilitate returns to the IANA whenever possible.

> I would support this policy, with the adjustment of section 6 to allow
> for RIR-based transfer policies, like the one currently present in the
> ARIN region; trying to develop a coordinated transfer policy across
> all regions, all RIRs I consider to be an unnecessary burden on
> this proposal.

There is currently a proposal in the ARIN region for a globally
coordinated transfer policy (pp119) which is extremely light-weight.
The need for two policies is driven by the distinction between a
global policy (like 2010-10) and a globally coordinated policy (like
pp119). Global policy is basically instructions to IANA from the
communities of all five RIRs. Globally coordinated policy, on the
other hand, is simply agreement between the five communities (no need
to instruct IANA).

> And now, you may return to your current rant-filled thread. ?^_^;

Thanks for the interruption. :)
~Chris

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


-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From marty at akamai.com  Fri Nov  5 21:58:28 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 5 Nov 2010 21:58:28 -0400
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <4CD46982.5070505@ipinc.net>
Message-ID: <C8FA2E84.167F4%marty@akamai.com>




On 11/5/10 4:30 PM, "Ted Mittelstaedt" <tedm at ipinc.net> wrote:

> 
> It occurs to me that if a network manager at an org that fraudulently
> obtained IP addressing from ARIN were to be, lets say, fired, and if
> in revenge he were to contact ARIN and be willing to provide testimony
> under deposition that he knowingly fraudulently obtained said resources,
> that any decent attorney would tell him before he opened his mouth
> to ARIN that he secure a guarantee from ARIN that he would NOT be
> prosecuted for breaking the law. (ie: a whistle-blower clause)  Said
> attorney might also advise that the org might obtain his name through
> legal discovery and proceed to file a civil lawsuit for NDA or trade
> secret violations, would they not?


Do you think we could get another year or two our of v4 if we are able to
recover any addresses that are being utilized fraudulently?

Ron? Ted? Leo?


Best,

-M<



From marty at akamai.com  Fri Nov  5 22:10:07 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 5 Nov 2010 22:10:07 -0400
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <4CD477B6.1070007@sprunk.org>
Message-ID: <C8FA313F.167FA%marty@akamai.com>




On 11/5/10 5:31 PM, "Stephen Sprunk" <stephen at sprunk.org> wrote:

> On 05 Nov 2010 15:30, Ted Mittelstaedt wrote:
>> It occurs to me that if a network manager at an org that fraudulently
>> obtained IP addressing from ARIN were to be, lets say, fired, and if
>> in revenge he were to contact ARIN and be willing to provide testimony
>> under deposition that he knowingly fraudulently obtained said
>> resources, that any decent attorney would tell him before he opened
>> his mouth to ARIN that he secure a guarantee from ARIN that he would
>> NOT be prosecuted for breaking the law. (ie: a whistle-blower clause)
>> Said attorney might also advise that the org might obtain his name
>> through legal discovery and proceed to file a civil lawsuit for NDA or
>> trade secret violations, would they not?
> 
> My understanding is that only the relevant District or US Attorney can
> offer immunity against criminal prosecution.



I don't see the word "criminal" anywhere on the Fraud Reporting Page:

    https://www.arin.net/resources/fraud/index.html

I'd be interested to know what constitutes criminal fraud with respect to
utilization or application misstatements.

-M<



From bicknell at ufp.org  Fri Nov  5 22:13:09 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 5 Nov 2010 19:13:09 -0700
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <C8FA2E84.167F4%marty@akamai.com>
References: <4CD46982.5070505@ipinc.net> <C8FA2E84.167F4%marty@akamai.com>
Message-ID: <20101106021309.GA83394@ussenterprise.ufp.org>

In a message written on Fri, Nov 05, 2010 at 09:58:28PM -0400, Hannigan, Martin wrote:
> Do you think we could get another year or two our of v4 if we are able to
> recover any addresses that are being utilized fraudulently?
> 
> Ron? Ted? Leo?

I don't think looking for abandoned for fraudulent resources is a
method to extend the useful life of IPv4 by any significant measure.

While I think some of the best reasons to expend resources on this
problem have nothing to do with IPv4 exhaustion, there is one way
in which I think it has a significant impact on the end-game.  When
there is no more IPv4 and folks are in a situation where they are
having to buy space it will be very hard for ARIN to explain why
they should pay $1000, $10000, or $100000 for number resources on
an open market when their are resources still allocated to defunct
companies.

You can't offer a defunct company money, so unlike many under-utilized
resources the transfer process may flesh out with the lure of cash
these resources will be permanently stranded unless ARIN acts.  I
believe ARIN, and ARIN alone can solve this problem, it's not one
community action or a market can fix.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101105/13a5805d/attachment.sig>

From gbonser at seven.com  Fri Nov  5 22:57:57 2010
From: gbonser at seven.com (George Bonser)
Date: Fri, 5 Nov 2010 19:57:57 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global
	Proposal):GlobalPolicyfor IPv4 Allocations by the IANA Post
	Exhaustion- LastCall	(textrevised)
In-Reply-To: <C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu><4CD0D768.3060905@ipinc.net>
	<4CD382AB.1030107@sprunk.org>
	<C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C7C4@RWC-EX1.corp.seven.com>

Owen said:

> IMHO, targeting legacy holders for non-compliance with today's
> ARIN policies is dubious at best. I agree we should seek to actively
> reclaim abandoned resources (resources where the ORG no
> longer exists). I think we should possibly reach out and request that
> ORGs no longer using their legacy resources voluntarily return
> them.
> 
> Legacy holders received their resources under very different
> requirements with very different expectations. While ARIN is the
> successor registry of record, legacy holders (other than LRSA
> signatories) have no agreement with ARIN and never agreed
> to be bound by the ARIN policy process. I think attempting to
> take such resources is an almost certain path to very costly
> litigation with a very uncertain outcome. There are better things
> for ARIN to do with their legal budget, IMHO.

In the case where the original legacy holder is still the owner of that
space, I would agree.  If the space involved has been "sold" or
otherwise transferred to someone else since ARIN came about, I would
argue that the only expectation the current holder has is being out of
reach of ARIN policy just because the space was originally issued to
someone else under a different policy.

I would support the original entity's right to use (or not use) those
addresses for whatever purpose they wanted.  The problem comes in with
legacy space that is no longer under the control of the original holder
of it.  It would seem to me that once those resources leave the control
of the original holder, that policy expectation should no longer apply.



> What we don't have is any form of agreement by the legacy holders
> that the ARIN definition of justified applies to them. Non-signatories
> to the LRSA are, thus, in an uncertain area. Signatories of the LRSA
> are clearly protected from current and future ARIN policies in this
> regard.

But what about people who aren't the original legacy holder that have
obtained those resources since ARIN has come about?  Why are they exempt
from current policy?  Why does holding certain IP address space place
you into a "wayback" machine to decades ago in policy?

> I agree that ARIN has a moral obligation to legacy holders.

Agreed.

> I am uncertain about what legal obligations ARIN has to legacy
holders.

What about non-legacy holders of legacy space?

 
> I think that involuntary reclamation of legacy resources or
> "termination of
> services" to legacy holders is contrary to ARIN's best interests. I
> think that
> going beyond "termination of services" to the step of placing
resources
> back into the free pool and issuing them to other organizations would
> be outright counter-productive for all concerned (except in the case
of
> clear abandonment).

It should have been the policy of ARIN that resources transferred out of
the control of the original holder of them revert to community control
via ARIN.  That horse left the barn long ago but it might not be too
late to implement such a policy.  Legacy space no longer under the
control of the original holder would immediately come under the same
policy as any other space and would require the same transfer
requirements as any other space from now going forward.  In other words,
the current holder would be ok to use them but if they wish to transfer
that space or if they go defunct, it comes under the current ARIN
policy.

While there is a strong argument that as the original holder of the
space did not have any transfer restrictions and so it was fine for them
to transfer the space to someone else, continuing that practice today
for entities that might be several times removed from that legacy holder
seems odd.  The only thing connecting a current recipient of that space
with the legacy agreement is the numbers in the block itself.  I say
that numbers cannot be held to this or that agreement and have no
expectations, they are just numbers.  People and entities of people can
have expectations but once that legacy holder no longer owns those
resources, the only expectation a current owner has is "I can do
whatever I want with these because these numbers are above the rules".
I don't think that expectation is healthy for the community.




From stephen at sprunk.org  Fri Nov  5 23:18:38 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 05 Nov 2010 22:18:38 -0500
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <C8FA313F.167FA%marty@akamai.com>
References: <C8FA313F.167FA%marty@akamai.com>
Message-ID: <4CD4C90E.1040308@sprunk.org>

On 05 Nov 2010 21:10, Hannigan, Martin wrote:
> On 11/5/10 5:31 PM, "Stephen Sprunk" <stephen at sprunk.org> wrote:
>> On 05 Nov 2010 15:30, Ted Mittelstaedt wrote:
>>> ... secure a guarantee from ARIN that he would NOT be prosecuted for breaking the law. ...
>> My understanding is that only the relevant District or US Attorney can offer immunity against criminal prosecution.
> I don't see the word "criminal" anywhere on the Fraud Reporting Page:
>
>     https://www.arin.net/resources/fraud/index.html
>
> I'd be interested to know what constitutes criminal fraud with respect to
> utilization or application misstatements.

The wording I was responding to, shown in the quote above (reduced for
clarity), was specifically about being "prosecuted for breaking the
law", i.e. a criminal case.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101105/0817598f/attachment.p7s>

From tedm at ipinc.net  Fri Nov  5 23:21:25 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Nov 2010 20:21:25 -0700
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <C8FA2E84.167F4%marty@akamai.com>
References: <C8FA2E84.167F4%marty@akamai.com>
Message-ID: <4CD4C9B5.60400@ipinc.net>

On 11/5/2010 6:58 PM, Hannigan, Martin wrote:
>
>
>
> On 11/5/10 4:30 PM, "Ted Mittelstaedt"<tedm at ipinc.net>  wrote:
>
>>
>> It occurs to me that if a network manager at an org that fraudulently
>> obtained IP addressing from ARIN were to be, lets say, fired, and if
>> in revenge he were to contact ARIN and be willing to provide testimony
>> under deposition that he knowingly fraudulently obtained said resources,
>> that any decent attorney would tell him before he opened his mouth
>> to ARIN that he secure a guarantee from ARIN that he would NOT be
>> prosecuted for breaking the law. (ie: a whistle-blower clause)  Said
>> attorney might also advise that the org might obtain his name through
>> legal discovery and proceed to file a civil lawsuit for NDA or trade
>> secret violations, would they not?
>
>
> Do you think we could get another year or two our of v4 if we are able to
> recover any addresses that are being utilized fraudulently?
>
> Ron? Ted? Leo?
>

I don't see this as a "find lots of IPv4 fraudulently used" issue.

I see this as something more important.  We have those people out there
who feel they are entitled to obtain a public resource without following
the rules, and the rules state that any IPv4 OR IPv6 obtained must be
publically identified as to who has it.

Orgs that submit fraudulent names and contact info for their IPv6 so 
they can spam the world or attack the world and allow their upstreams to 
suffer the consequences of dealing with the complaints are the problem. 
  Orgs that submit real names then immediately change them to
bogus names once they get the resources are also the problem.  And orgs
that submit dozens of different names under paper companies to get
dozens of different IPv6 blocks so they can burp out their spams like
a wack-a-mole game without the public realizing it is the same spammer 
are also a problem.

All we have is a bunch of RIR's who are overly cautious of dropping the 
boom on misusers of IP addressing, and overly relying on the notion that 
the users must be legitimate if they are coughing the yearly
registration renewals.  And I mean all RIR's all over the world.  I'll 
leave you to argue if this is good or not, but the fact is that this 
means the only way we can protect ourselves is to build our own defenses 
and those won't be worth a poop if the bad guys are allowed to use fake 
names to hide behind.

I feel that the minimum that ARIN and the other RIR's should be doing is
insuring the legitimacy of the data in the global WHOIS databases.  I
don't feel this is too much to be asking.  Registering addressing with
multiple fake names is a contractual breech of the RSA and it boggles my
mind that there are people on this list who would argue what is plain
contract language right in the RSA.

Whether your doing it to gain IPv4 or IPv6 it is fraud, and if a network 
admin can document an instance of this to the RIR I don't think it's too 
much to ask the RIR to protect their informants and to come down on the 
bad guys and pull allocations.

Ted


From tedm at ipinc.net  Fri Nov  5 23:26:46 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Nov 2010 20:26:46 -0700
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <4CD4C90E.1040308@sprunk.org>
References: <C8FA313F.167FA%marty@akamai.com> <4CD4C90E.1040308@sprunk.org>
Message-ID: <4CD4CAF6.4010308@ipinc.net>

On 11/5/2010 8:18 PM, Stephen Sprunk wrote:
> On 05 Nov 2010 21:10, Hannigan, Martin wrote:
>> On 11/5/10 5:31 PM, "Stephen Sprunk"<stephen at sprunk.org>  wrote:
>>> On 05 Nov 2010 15:30, Ted Mittelstaedt wrote:
>>>> ... secure a guarantee from ARIN that he would NOT be prosecuted for breaking the law. ...
>>> My understanding is that only the relevant District or US Attorney can offer immunity against criminal prosecution.
>> I don't see the word "criminal" anywhere on the Fraud Reporting Page:
>>
>>      https://www.arin.net/resources/fraud/index.html
>>
>> I'd be interested to know what constitutes criminal fraud with respect to
>> utilization or application misstatements.
>
> The wording I was responding to, shown in the quote above (reduced for
> clarity), was specifically about being "prosecuted for breaking the
> law", i.e. a criminal case.
>
> S
>
>

I really think there is too much reliance on whether or not it is
criminal.  Fraud is one of those crimes that the DA has wide leeway
to prosecute and we all know this.  DA's tell corporations all of the
time that they aren't going to go after people who break contracts
with the corporation, and it's up to the corp. to sue them in civil
court - even when the corp can produce obvious evidence that there
was fraudulent intent to break the contract.

Ted


From rfg at tristatelogic.com  Sat Nov  6 04:52:36 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Sat, 06 Nov 2010 01:52:36 -0700
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <C8FA2E84.167F4%marty@akamai.com> 
Message-ID: <61093.1289033556@tristatelogic.com>


In message <C8FA2E84.167F4%marty at akamai.com>, 
"Hannigan, Martin" <marty at akamai.com> wrote:

>Do you think we could get another year or two our of v4 if we are able to
>recover any addresses that are being utilized fraudulently?
>
>Ron? Ted? Leo?

Does it matter?

I think you are asking the wrong question.

Let me explain why I say that.

Quite simply, I'm looking at this v4->v6 transtion and I frankly think
its going to be a debacle of historic proportions, not because people
of good will haven't been working their butts off to try to make it all
go smoothly... many many surely have... but rather because they are all
struggling, vainly, I think, against one of the most fundamental aspects
of human nature, inertia.  And against that, they are nearly powerless.

We have, I think, a model for how a mass technology transition like this
can be pulled off with a reasonable level of success and without too
awfully much confusion and pain, i.e. the transition, in North America,
from analog to digital TV.  In that transition also, we had producers
and consumers and a massive chicken & egg problem, but somehow it all
worked.  I think it worked for one simple reason... somebody, and I'm
not even sure who (the government?) put their foot down at some point
and said ``OK, after this date certain, EVERYBODY is going to get onto
the new standard, and to make sure that we get even the lazy, and the
stupid, and the die-hards to do that, we are going to actually pull
the plug on the old system and SHUT THE DAMN THING DOWN ENTIRELY as of
date X.''

For whatever reasons... and I don't even know the reasons because I
wansn't in the room at the time... the decision was made that this
would NOT be the way the v4->v6 transition would be handled... no
big brother coming in and pointing a gun at all our heads, no date
certain for the ``universal'' changeover, and most importantly, no
committment by anybody, as far as I know, to turn down and turn off
IPv4.

To be clear, I am not criticizing the decision to try to operate the old
and the new, v4 and v6, in parallel for an extended period of time, nor
would I, because I am almost completely ignorant of the reasoning or argu-
uments that went into that decision.  I am only offering my observations
on what seems likely to unfold, based on that decision.

And what seems most likely to me is that v4 will be around and will be
in active use for another 5, 10, and possibly even 20 years.  As long as
you can be v4 and yet still have v6 on the side, some people and organi-
zations will continue to cling to v4 like a life preserver.  And they
will be right to do so as long as there are _other_ people they want to
communicate with who are v4 only.  (And there will be.)

I see a big potential downside here for future innovation.

I think that most of us would agree that the Internet is a wonderful thing.
Take eBay, for example, which took a massive set of localized disorganized
flea markets and yard sales and made the whole mess both rational and global.
And then there is the Huffington Post, which so far seems to be able to
make a go of it, by preserving something that looks sort of like journalism,
in a world where that particular art form is rapidly dying out.  Innovation
made the Internet what it is and vise versa.

So what's going to happen to the next generation of Internet innovations
and innovators?  Are they going to be hamstrung in their quests for success
because they can't get any IPv4 and because they have the misfortune of
comming online at a time when 50% of the planet still speaks only that?
How will tomorrow's New Upstarts compete against the Old Guard, when the
latter has access to 100% market share while the former only has access
to 50% of that?

I don't know what the next great and indispensible Internet site or service
is going to be.  I wish I did.  All I know is that there _is_ going to be
one... or rather many.  Do _you_ want to be the one to tell the next great
Internet innovators that they are SOL as far as IPv4 connectivity simply
because a bunch of crooks got there ahead of them and stole what remained
of the IPv4 space (and because nobody even took the time to clean that mess
up)?  I don't.

So who would you rather see get the last remaining bits of the IPv4 space...
the next eBay or Google or Huffington Post or Facebook, or a bunch of
fraudsters?

In short, I don't think it is a question of how long we can keep on giving
_everybody_ (and every toaster) more IPv4 space.  To me the question comes
back to stewardship.... as long as IPv4 lives it should have good stewardship
and somebody should make sure that deserving and needy entities get preference
for WHATEVER amounts remain... including whatever amounts can be recovered...
in preference over both (a) crooks and also (b) toasters & refrigerators.


From owen at delong.com  Sat Nov  6 05:08:13 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 6 Nov 2010 02:08:13 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last
	Call	(textrevised)
In-Reply-To: <4CD43014.9050606@sprunk.org>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net> <4CD382AB.1030107@sprunk.org>
	<C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
	<4CD43014.9050606@sprunk.org>
Message-ID: <4F0FC5AB-8640-427F-A57F-53677C74480E@delong.com>


On Nov 5, 2010, at 9:25 AM, Stephen Sprunk wrote:

> On 05 Nov 2010 01:56, Owen DeLong wrote:
>> On Nov 4, 2010, at 9:06 PM, Stephen Sprunk wrote:
>>> On 02 Nov 2010 22:30, Ted Mittelstaedt wrote:
>>>> I think that this is because ultimately the goal isn't to take
>>>> legacy resources away that are IN USE.
>>> IMHO, that depends on the degree of non-compliance.  I've worked with dozens of orgs with legacy space, and not a single one of them could even come close to justifying their space _that was in use_.
>>> 
>>> However, I don't see any point in targeting orgs using their space inefficiently until we've dealt with all the ones (and I really do mean every last one that can be found) not using their space _at all_.
>> IMHO, targeting legacy holders for non-compliance with today's ARIN policies is dubious at best.
> 
> I understand there are differences of opinion here; more on that below.
> 
>> I agree we should seek to actively reclaim abandoned resources (resources where the ORG no longer exists). I think we should possibly reach out and request that ORGs no longer using their legacy resources voluntarily return them.
> 
> I think we all agree on this much, which is why it seems a rather
> obvious first step.  Once this is underway, we can debate what (if
> anything) can/should be done about the other group.
> 
>>>> Ultimately the goal should be to take legacy resources away that are either being hoarded, or are abandoned.
>>> "Hoarded" is a loaded term, and it's difficult to prove someone's doing it.  "Justified" is easily determined, though, since we _already_ have dozens of pages of policy describing exactly what that means.
>> What we don't have is any form of agreement by the legacy holders that the ARIN definition of justified applies to them.
> 
> OTOH, absent an LRSA, there is no formal agreement that it doesn't.
> 
Uh, generally it's pretty hard to claim that a contract is binding on an opt-out basis.

I can't just make up a contract and then say you are subject to it's terms just
because you don't have a contract that says otherwise.

>> Non-signatories to the LRSA are, thus, in an uncertain area. Signatories of the LRSA are clearly protected from current and future ARIN policies in this regard.
> 
> Yes, that's an excellent carrot for folks to sign the LRSA.  We disagree
> only about the stick.
> 
> I don't like using sticks, but eventually we're going to run out of
> folks that are interested in the carrot.
> 
So? I really don't see the problem with leaving them alone to do their
own thing. I'd rather see them join the community, but, I simply don't
see any valid argument for attempting to do so by force.

>>>> Rubbish. If ARIN takes over an abandoned Legacy resource then since
>>>> it is abandoned, the original org that had it cannot suffer damages,
>>>> and since it hasn't suffered damages, it has no standing to sue in
>>>> court.
>>>> 
>>>> The problem is that since the original Legacy holder did NOT ever
>>>> sign an agreement with ARIN then ARIN has no contractual
>>>> justification to take over an abandoned Legacy assignment even if
>>>> they know it's unused,
>>> AFAICT, if the registrant does not have a contract (i.e. RSA or LRSA) with ARIN for registry services, ARIN has no obligation to continue providing them, especially for free.  There are many who feel ARIN has a _moral_ obligation to do so, but that's not a matter for the courts.
>> I agree that ARIN has a moral obligation to legacy holders.
> 
> I agree ARIN has some sort of moral obligation to provide services, but
> that is in direct conflict with ARIN's charter to act as steward for the
> entire community.
> 
Not really.

> I was willing to accept granting special privileges to _all_ legacy
> holders prior to the LRSA being made available; now that it is, though,
> I'm reluctant to accept continuing to grant those same special
> privileges to those who do not sign.
> 
First, I don't agree with your use of the term "special privileges".

Second, I really don't think legacy holders are a major problem and
I don't see the point in pursuing them with pitchforks and torches
just because they choose not to join the ARIN community.


>> I am uncertain about what legal obligations ARIN has to legacy holders.
> 
> We've been told in the past we should make policy we think is "right"
> for the community and let ARIN's counsel inform us if there are legal
> problems with our proposals.
> 
> Counsel rarely participates in policy discussions prior to a formal
> proposal being on the table, so a bit of armchair lawyering is probably
> unavoidable, but it shouldn't dominate the discussion.
> 
I hardly think a single sentence dominates a discussion.

>> I think that involuntary reclamation of legacy resources or "termination of services" to legacy holders is contrary to ARIN's best interests.
> 
> I disagree.
> 
And you are free to do so.

Care to back that up with what ARIN possibly gains by doing so other than
litigation expenses?

>> I think that going beyond "termination of services" to the step of placing resources back into the free pool and issuing them to other organizations would be outright counter-productive for all concerned (except in the case of clear abandonment).
> 
> It depends on the legal explanation of exactly what it is ARIN does.  At
> the end of the day, the "resources" that ARIN "issues" to registrants
> are merely entries in WHOIS and rDNS.  ARIN cannot actually issue
> numbers to (or take them away from) registrants because numbers
> themselves cannot be owned, leased, etc.
> 
Yep.

> I do not see a significant difference between removing a non-paying
> registrant's entries from WHOIS/rDNS and replacing them with a paying
> registrant's entries that happen to have the same or similar numbers. 
> And, frankly, if we don't do the latter, what's the point in the
> former?  Marking a bunch of space as "permanently unavailable"
> accomplishes little.
> 
It makes it easy to filter it out so it doesn't get hijacked.

Besides who said anything about permanently unavailable. The
space is either held by an organization or it isn't. If we can't find
the organization, we record that fact and make it visible. Eventually,
either we find out for sure that the organization is defunct, or, we
find out that they do still exist. In the former case, resources can
be reclaimed. In the latter case, they cannot.

I'm just saying we shouldn't reclaim resources until we are certain
that the organization no longer exists.

>>>> because so far the community has not given ARIN permission to do this via policy in the NRPM.
>>> That all depends on how one interprets NRPM 12.8.
>>> 
>>> IMHO, ARIN _already_ had the power to apply policy to legacy space or revoke it entirely, and therefore NRPM 12 actually _limits_ how ARIN may do so, as it does for non-legacy resources.
>> Where did this power come from? For non-legacy holders, it comes from
>> the RSA which is a binding contract between the resource holder and ARIN
>> which entitles ARIN to revoke resources according to the NRPM.
>> 
>> There is no document anywhere that I know of which gives ARIN any such authority to revoke legacy resources based on current ARIN policy where it differs from the policies in effect under which the legacy resources were issued.
> 
> I forget the original Latin, but there's a famous legal principle that
> "what is not illegal must be legal".
> 
It is illegal to enforce terms of a contract against a non-signatory.

> ARIN can add or remove any WHOIS/rDNS entry it wishes unless restricted
> by policy or by a contract, i.e. an RSA or LRSA.  IOW, since non-LRSA
> legacy holders have no contract restricting what ARIN does, they have no
> (legal) standing to complain if ARIN decides to stop providing them
> unpaid, uncontracted registry services--just like a homeless person has
> no (legal) standing to complain if a shelter decides to stop giving them
> free meals.  That's purely a moral issue.
> 
That's an interesting theory, but, I doubt that as the successor registry to
registries that granted the registrations to organizations on very different
terms with no contract stating that the terms could be subsequently changed
without agreement, ARIN would actually have as good a standing as you
claim in that situation.

>>> Wrong. ARIN would need to follow the procedure in NRPM 12, which
>>> governs _all_ reclamation activities.
>>> 
>>> However, if all the POCs are unresponsive, then presumably they will
>>> not respond with justification as required in 12.1, they will not
>>> voluntarily return the resource(s) as required in 12.4, and
>>> eventually ARIN can revoke the resource(s) under 12.5.
>> Presumably the later stages of POC validation would include the notices
>> required under 12.1 such that by the time the POCs were marked invalid,
>> we would have at least completed the 12.4 waiting period as well, thus
>> making 12.5 effective pretty much as described above.
> 
> That would be convenient.
> 
I like to presume that staff is reasonably intelligent and generally tries to
be efficient. So far, that does seem to be the case.

>>> One can address most of those by having other processes that add to the same list of resources to be reviewed.  For instance, one might consider a resource not appearing in the DFZ to be a sign of probable non-compliance which triggers a review.  Or resources which have not been updated in the last N years.  Or not having valid rDNS servers.  If the review concludes they're valid, the registrant has 24 months before they have to worry about being hassled again.
>> There are specific policies allowing for non-connected networks and always have been. Why would the fact that a resource does not appear in one particular view (or even several views) of the DFZ be considered a sign of probable non-compliance? As to update cycle, some organizations
>> are actually extremely stable. ... When did maintaining valid rDNS become a requirement even for a non-legacy holder? I can't find that requirement anywhere in the NRPM.
> 
> Those are merely possible reasons to put someone into the review queue. 
> If it turns out their use is justified (or close to it), no action will
> be taken against them and they're exempt from another without-cause
> review for 24 months.
> 
> This is _precisely_ why I put that clause in 2007-14: to clarify that
> ARIN could review resources that _appeared_ to be unjustified without
> needing a priori proof of such.  The remainder of 2007-14 is there to
> make sure that, when ARIN makes use of this power, the registrant is
> protected.  I believe that ARIN has _always_ had this power, but the
> response to an ACSP suggestion of mine indicated that ARIN was
> uncomfortable wielding that power without explicit policy supporting it.
> 
I'm saying that going after all or even some random number of
resources on that basis is a dubious set of selection criteria at
best and seems rather arbitrary to me.

>> What value of N would you propose? 5? 10? 15?
> 
> I would propose N=15 to start with, reducing over time as this
> particular method ran out of folks to review.  I don't think it'd be
> wise to go below N=5.
> 
>>> Yes, a sufficiently cagey registrant may be able to avoid all of our heuristics, but most won't even try to.  It's reasonable to lose a battle to a skilled and dedicated opponent; it's absolutely indefensible to surrender a battle when your opponent doesn't even show up, which is where we are right now.  Let's fix the latter problem before we worry about the former.
>> When did this shift from stewardship to seeking battles with legacy
>> holders? That certainly was not my intent in NRPM 12.
> 
> It's a metaphor.
> 
It doesn't sound like one. It sounds like an attempt to go after legacy
holders just because they didn't sign the LRSA. I don't think that's
right.

>>> I don't think that "mining" IPv4 blocks for reclamation will have any
>>> meaningful effect on runout, but I still think it's worthwhile for
>>> several other reasons.
>> I understand the "other reasons" for reclamation of abandoned resources.
>> They're a good target for abuse.
> 
> Agreed, and IMHO that's a good enough reason by itself.
> 
I agree... in the case of abandoned resources. I don't agree if there
is any indication that the resources are not abandoned.

>> What reasons do you have for actively seeking to reclaim legacy resources that are not abandoned ... ?
> 
> Primarily, it is the moral obligation we have to the _entire community_
> to act as stewards in an impartial manner, and IMHO that overrides any
> moral obligation we have to individual registrants--particularly ones
> that refuse to participate in the community or take advantage of the
> (exceedingly generous, IMHO) terms that the LRSA offers.
> 
I think that mis-characterizes the situation. Legacy holders received
their resources under a different set of terms from predecessor registries.
ARIN, if it doesn't want to be the successor registry and wants to
terminate its services to legacy holders is welcome to do so. In that
case, ARIN should identify a successor registry to transfer the stewardship
of those resources to.

If ARIN wants to be the successor registry (which I think is generally
good for the community), then, ARIN should live up to the terms under
which the legacy resources were granted and should continue to provide
the services as agreed by the predecessor registry.

This theory that ARIN is somehow entitled as the successor registry
to retroactively change the terms under which legacy resources
were issued without the consent of the recipients really strikes me
as being quite odd.

> Also, I am concerned about the complaints (and potential legal action)
> ARIN will face if we start actively reclaiming non-legacy resources but
> do not attempt to reclaim (non-LRSA) legacy resources.  Worse, showing
> irresponsibility here may justify attempts by others to impose
> governmental (i.e. ITU) interference or end community-based governance
> entirely.
> 
I think it's pretty easy to show that those resources were issued by
predecessor registries under different terms and conditions.

Owen

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

From owen at delong.com  Sat Nov  6 05:19:45 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 6 Nov 2010 02:19:45 -0700
Subject: [arin-ppml] Audits
In-Reply-To: <8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
Message-ID: <FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>


On Nov 5, 2010, at 11:49 AM, John Curran wrote:

> On Nov 5, 2010, at 2:19 PM, Leo Bicknell wrote:
>> What would the community have to get the ARIN staff to go proactively
>> looking for fraud, abuse, defunct companies and other non-compliant
>> uses of the address space?
> 
> As usual: have the community develop an appropriate policy and ensure that 
> there is an adequate level of support for the increased ARIN costs (which 
> will appear back as overall service fees) once we get to implementation.
> 
John,
	We tried this with 2010-11 and the community abandoned it primarily
because staff said it wasn't necessary and they got the message that we
wanted them to be more active and report more on anti-fraud activities.

	From your message above, it appears only the report more portion
of the message actually got through.


Owen



From owen at delong.com  Sat Nov  6 05:34:21 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 6 Nov 2010 02:34:21 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global
	Proposal):GlobalPolicyfor IPv4 Allocations by the IANA Post
	Exhaustion- LastCall	(textrevised)
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C7C4@RWC-EX1.corp.seven.com>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu><4CD0D768.3060905@ipinc.net>
	<4CD382AB.1030107@sprunk.org>
	<C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
	<5A6D953473350C4B9995546AFE9939EE0B14C7C4@RWC-EX1.corp.seven.com>
Message-ID: <3E4B583C-54FE-491F-866F-6ABA015E70C1@delong.com>


On Nov 5, 2010, at 7:57 PM, George Bonser wrote:

> Owen said:
> 
>> IMHO, targeting legacy holders for non-compliance with today's
>> ARIN policies is dubious at best. I agree we should seek to actively
>> reclaim abandoned resources (resources where the ORG no
>> longer exists). I think we should possibly reach out and request that
>> ORGs no longer using their legacy resources voluntarily return
>> them.
>> 
>> Legacy holders received their resources under very different
>> requirements with very different expectations. While ARIN is the
>> successor registry of record, legacy holders (other than LRSA
>> signatories) have no agreement with ARIN and never agreed
>> to be bound by the ARIN policy process. I think attempting to
>> take such resources is an almost certain path to very costly
>> litigation with a very uncertain outcome. There are better things
>> for ARIN to do with their legal budget, IMHO.
> 
> In the case where the original legacy holder is still the owner of that
> space, I would agree.  If the space involved has been "sold" or
> otherwise transferred to someone else since ARIN came about, I would
> argue that the only expectation the current holder has is being out of
> reach of ARIN policy just because the space was originally issued to
> someone else under a different policy.
> 
Resources cannot be sold or transferred outside of the ARIN process
and I agree with you that would void the original holders rights.

> I would support the original entity's right to use (or not use) those
> addresses for whatever purpose they wanted.  The problem comes in with
> legacy space that is no longer under the control of the original holder
> of it.  It would seem to me that once those resources leave the control
> of the original holder, that policy expectation should no longer apply.
> 
That space is either abandoned or has been transferred outside of
ARIN policy. In either case, yes, reclamation is justified.

> 
> 
>> What we don't have is any form of agreement by the legacy holders
>> that the ARIN definition of justified applies to them. Non-signatories
>> to the LRSA are, thus, in an uncertain area. Signatories of the LRSA
>> are clearly protected from current and future ARIN policies in this
>> regard.
> 
> But what about people who aren't the original legacy holder that have
> obtained those resources since ARIN has come about?  Why are they exempt
> from current policy?  Why does holding certain IP address space place
> you into a "wayback" machine to decades ago in policy?
> 
I don't think that's what anyone was talking about here.

>> I agree that ARIN has a moral obligation to legacy holders.
> 
> Agreed.
> 
>> I am uncertain about what legal obligations ARIN has to legacy
> holders.
> 
> What about non-legacy holders of legacy space?
> 
To the best of my knowledge, No such thing as far as ARIN is
concerned. If the original holder of the space isn't holding it any more,
then, it is abandoned.

> 
>> I think that involuntary reclamation of legacy resources or
>> "termination of
>> services" to legacy holders is contrary to ARIN's best interests. I
>> think that
>> going beyond "termination of services" to the step of placing
> resources
>> back into the free pool and issuing them to other organizations would
>> be outright counter-productive for all concerned (except in the case
> of
>> clear abandonment).
> 
> It should have been the policy of ARIN that resources transferred out of
> the control of the original holder of them revert to community control
> via ARIN.  That horse left the barn long ago but it might not be too
> late to implement such a policy.  Legacy space no longer under the
> control of the original holder would immediately come under the same
> policy as any other space and would require the same transfer
> requirements as any other space from now going forward.  In other words,
> the current holder would be ok to use them but if they wish to transfer
> that space or if they go defunct, it comes under the current ARIN
> policy.
> 
That has always been the policy of ARIN other than under section 8
which allowed for transfers in light of merger and acquisition (now
section 8.2) and the recent (2009-1) addition of section 8.3 to allow
certain other forms of transfers.

There is no provision and has never been any provision for a transfer
to occur without subjecting the recipient of the transferred resources
to an RSA for those resources.

> While there is a strong argument that as the original holder of the
> space did not have any transfer restrictions and so it was fine for them
> to transfer the space to someone else, continuing that practice today
> for entities that might be several times removed from that legacy holder
> seems odd.  The only thing connecting a current recipient of that space
> with the legacy agreement is the numbers in the block itself.  I say
> that numbers cannot be held to this or that agreement and have no
> expectations, they are just numbers.  People and entities of people can
> have expectations but once that legacy holder no longer owns those
> resources, the only expectation a current owner has is "I can do
> whatever I want with these because these numbers are above the rules".
> I don't think that expectation is healthy for the community.
> 
I believe the original terms and conditions did restrict transfer.

Therefore, I think the rest of the paragraph is even further off the rails.

Owen




From jcurran at arin.net  Sat Nov  6 09:29:30 2010
From: jcurran at arin.net (John Curran)
Date: Sat, 6 Nov 2010 09:29:30 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
Message-ID: <390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>

On Nov 6, 2010, at 5:19 AM, Owen DeLong wrote:

> On Nov 5, 2010, at 11:49 AM, John Curran wrote:
> 
>> On Nov 5, 2010, at 2:19 PM, Leo Bicknell wrote:
>>> What would the community have to get the ARIN staff to go proactively
>>> looking for fraud, abuse, defunct companies and other non-compliant
>>> uses of the address space?
>> 
>> As usual: have the community develop an appropriate policy and ensure that 
>> there is an adequate level of support for the increased ARIN costs (which 
>> will appear back as overall service fees) once we get to implementation.
>> 
> 
> John,
>    We tried this with 2010-11 and the community abandoned it primarily
> because staff said it wasn't necessary and they got the message that we
> wanted them to be more active and report more on anti-fraud activities.

Anti-fraud activities: Yes.  We are actively reviewing reports, reclaiming
resources, and trying to improve our reporting of these activities.  We've
got a clear definition of Internet number resource fraud, and the staff can
attest that we're putting much more attention here. 

Note, however, that scope of Leo's request is *much* larger than 2010-11, 
as 2010-11 was predominantly how ARIN handles various events in a reactive
basis, where as Leo's question about staff going "proactively looking" for 
violations, and that could be require enormous resources depending on the 
actual policy scope.

Leo's message also includes both "abuse" & "defunct companies" which 
definitely require better definition via policy before ARIN knows how to 
ramp up these activities.  If abuse means anything other than the fraud
definition we're using, then we need to be very clear about what you all
believe constitutes abuse.  

We have similar issues with resources held by "defunct" organizations, 
since it can be very difficult to find the appropriate original legal 
entity that was assigned a legacy resource, and then even more challenging
to determine if they're actually defunct when there's no declaration of
same, given the chain of mergers, acquisitions, and divestitures that 
occurred in this the early days of this industry. 

Tracing these legally is just manageable when dealing with someone inside
the successor firm, who has access to their legal records, and is willing 
to be responsive to our requests for documentation (as occurs with transfers 
due to merger and acquisition.)  Attempting to prove the same decades later 
entirely from external legal records would to be a real adventure...

>    From your message above, it appears only the report more portion
> of the message actually got through.

Incorrect. We're more active in pursuing and reporting anti-fraud 
activities, but the scope of Leo's request is far far greater.

/John

John Curran
President and CEO
ARIN



From info at arin.net  Sat Nov  6 09:43:15 2010
From: info at arin.net (ARIN)
Date: Sat, 06 Nov 2010 09:43:15 -0400
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
Message-ID: <4CD55B73.9030104@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

The ARIN Advisory Council (AC) will review the proposal at their next
regularly scheduled meeting (if the period before the next regularly
scheduled meeting is less than 10 days, then the period may be extended
to the subsequent regularly scheduled meeting). The AC will decide how
to utilize the proposal and announce the decision to the PPML.

The AC invites everyone to comment on the 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.

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 120: Protecting Number Resources

Proposal Originator: Leo Bicknell

Proposal Version: 1.0

Date: 5 November 2010

Proposal type: new

Policy term: permanent

Policy statement:

ARIN shall use any reasonable and practical methods to proactively
look for fraudulently obtained or abandoned number resources and
seek the return of those resources to ARIN.

A report of activities under this policy shall be delivered at each
ARIN meeting.

Rationale:

ARIN has generally only reactively looked for fraudulently obtained
or abandoned number resources, generally via reports to
https://www.arin.net/resources/fraud/.

While it is great for ARIN to take these community reports, ARIN
can be in a far better position to know which resources were
fraudulently obtained or abandoned due to the additional paperwork
that ARIN holds which is not available to the public, and the record
of interactions (or lack thereof) with the resource holder.

] From: John Curran <jcurran at arin.net>
] To: Leo Bicknell <bicknell at ufp.org>
] CC: "arin-ppml at arin.net" <arin-ppml at arin.net>
] Subject: Re: [arin-ppml] Audits
]
] On Nov 5, 2010, at 2:19 PM, Leo Bicknell wrote:
] >  What would the community have to get the ARIN staff to go proactively
] >  looking for fraud, abuse, defunct companies and other non-compliant
] >  uses of the address space?
]
] As usual: have the community develop an appropriate policy and ensure that
] there is an adequate level of support for the increased ARIN costs (which
] will appear back as overall service fees) once we get to implementation.
]
] /John

I expect the board/executive management will interpret reasonable
and practical to be some amount of staff time that is not zero, but
will also not "break the bank".

I also expect that ARIN will report on the number resources (in the
aggregate) that were returned due to this proactive activity, as
well as the cost to the members of this activity (again, in the
aggregate) so as to obtain feedback if more, or less resources
should be used in this area.

Timetable for implementation: immediate






From bill at herrin.us  Sat Nov  6 10:43:07 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 6 Nov 2010 10:43:07 -0400
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <4CD55B73.9030104@arin.net>
References: <4CD55B73.9030104@arin.net>
Message-ID: <AANLkTinSie39u8ex25U9vqNsP4ne4KQxNvGonwj0Sm4J@mail.gmail.com>

On Sat, Nov 6, 2010 at 9:43 AM, ARIN <info at arin.net> wrote:
> Policy Proposal 120: Protecting Number Resources
> Proposal Originator: Leo Bicknell
>
> ARIN shall use any reasonable and practical methods to proactively
> look for fraudulently obtained or abandoned number resources and
> seek the return of those resources to ARIN.

Hi Leo,

Two thoughts I'd like to share...

This is too open ended for the nature of the topic. How shall ARIN
look? Spend staff time keeping up with forums where abuse-related
reports tend to surface? Increase random audits and generally make a
nuisance of themselves? Something else? For something actionable, and
something that's not going to create an extra hassle for all of us,
this should be more specific.

How big an effort? Should ARIN dedicate 1 individual to proactively
looking for abuse? 20? 100? As many as it takes until some diminishing
returns formula kicks in? In a strictly technical sense, there's no
limit to the amount of manpower that can be spent searching for
something that might or might not be found. Thus a policy that calls
for such proactive investigations should specify that upper limit.

Regards,
Bill Herrin



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


From stephen at sprunk.org  Sat Nov  6 11:00:56 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Sat, 06 Nov 2010 10:00:56 -0500
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <4CD4CAF6.4010308@ipinc.net>
References: <C8FA313F.167FA%marty@akamai.com> <4CD4C90E.1040308@sprunk.org>
	<4CD4CAF6.4010308@ipinc.net>
Message-ID: <4CD56DA8.4090507@sprunk.org>

On 05 Nov 2010 22:26, Ted Mittelstaedt wrote:
> On 11/5/2010 8:18 PM, Stephen Sprunk wrote:
>> On 05 Nov 2010 21:10, Hannigan, Martin wrote:
>>> On 11/5/10 5:31 PM, "Stephen Sprunk"<stephen at sprunk.org>  wrote:
>>>> On 05 Nov 2010 15:30, Ted Mittelstaedt wrote:
>>>>> ... secure a guarantee from ARIN that he would NOT be prosecuted
>>>>> for breaking the law. ...
>>>>
>>>> My understanding is that only the relevant District or US Attorney
>>>> can offer immunity against criminal prosecution.
>>>
>>> I don't see the word "criminal" anywhere on the Fraud Reporting Page:
>>>
>>>      https://www.arin.net/resources/fraud/index.html
>>>
>>> I'd be interested to know what constitutes criminal fraud with
>>> respect to
>>> utilization or application misstatements.
>>
>> The wording I was responding to, shown in the quote above (reduced for
>> clarity), was specifically about being "prosecuted for breaking the
>> law", i.e. a criminal case.
>
> I really think there is too much reliance on whether or not it is
> criminal.  Fraud is one of those crimes that the DA has wide leeway to
> prosecute and we all know this.  DA's tell corporations all of the
> time that they aren't going to go after people who break contracts
> with the corporation, and it's up to the corp. to sue them in civil
> court - even when the corp can produce obvious evidence that there was
> fraudulent intent to break the contract.

Whether or not that is true, ARIN cannot _guarantee_ a whistle-blower
that they will not be prosecuted.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101106/e7d93855/attachment.p7s>

From bicknell at ufp.org  Sat Nov  6 11:12:55 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Sat, 6 Nov 2010 08:12:55 -0700
Subject: [arin-ppml] Audits
In-Reply-To: <390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
Message-ID: <20101106151255.GA29852@ussenterprise.ufp.org>

In a message written on Sat, Nov 06, 2010 at 09:29:30AM -0400, John Curran wrote:
> We have similar issues with resources held by "defunct" organizations, 
> since it can be very difficult to find the appropriate original legal 
> entity that was assigned a legacy resource, and then even more challenging
> to determine if they're actually defunct when there's no declaration of
> same, given the chain of mergers, acquisitions, and divestitures that 
> occurred in this the early days of this industry. 

While I agree it can be hard, in other cases it can be quite easy.

I can imagine a process like:

Check for netblocks in whois and were in route-views or the ris
database but haven't been seen for at least 5 years.

Look up the POC's on the whois record in LinkedIn.  Verify they
have that company name in their history.

Send them e-mail, asking them if the company is still around.

You might just get back an e-mail saying "Bob was the owner, shut
it down in 2001,  you can contact him at 1-234-555-1212."  You call
up Bob, he's willing to attest he was the owner and it is no longer
around, and you reclaim.

I cannot express how frustrated I am that ARIN seems totally unwilling
to go after the low hanging fruit, or even fruit already dropped
on the ground using the argument that they don't have a ladder to
reach the fruit at the top of the tree.

Sometimes being a good steward takes effort.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101106/933caaba/attachment.sig>

From jcurran at arin.net  Sat Nov  6 12:18:52 2010
From: jcurran at arin.net (John Curran)
Date: Sat, 6 Nov 2010 12:18:52 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <20101106151255.GA29852@ussenterprise.ufp.org>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
Message-ID: <9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>

On Nov 6, 2010, at 11:12 AM, Leo Bicknell wrote:

> In a message written on Sat, Nov 06, 2010 at 09:29:30AM -0400, John Curran wrote:
>> We have similar issues with resources held by "defunct" organizations, 
>> since it can be very difficult to find the appropriate original legal 
>> entity that was assigned a legacy resource, and then even more challenging
>> to determine if they're actually defunct when there's no declaration of
>> same, given the chain of mergers, acquisitions, and divestitures that 
>> occurred in this the early days of this industry. 
> 
> While I agree it can be hard, in other cases it can be quite easy.
> 
> I can imagine a process like:
> 
> Check for netblocks in whois and were in route-views or the ris
> database but haven't been seen for at least 5 years.
> 
> Look up the POC's on the whois record in LinkedIn.  Verify they
> have that company name in their history.

I'm sorry: You are advocating that we use LinkedIn as a verification
step? A very high number of contacts will not have LinkedIN accounts, 
are we to then exclude them from consideration by this step? These 
may be the only useful contacts for the resource; how do we then 
proceed?

Given that anyone can put anything they want into their profile 
(check: http://www.linkedin.com/in/jcurran, you'll now see the entry 
that says I was your Boss at ufp.org till recently..), this won't 
stop anyone who actively is attempting to subvert the process, so 
I'm trying to understand its purpose. I agree it is an easy process, 
but it doesn't appear to be tied to any actually verifiable facts 
so far.

> Send them e-mail, asking them if the company is still around.
> 
> You might just get back an e-mail saying "Bob was the owner, shut
> it down in 2001,  you can contact him at 1-234-555-1212."  You call
> up Bob, he's willing to attest he was the owner and it is no longer
> around, and you reclaim.

Send listed contact Mr. John Smith an email, and Mr. Smith writes 
back and says: "Yep, the Company ABC is deceased (which I did list
in my LinkedIN profile and am a contact for); you should contact Bob 
who I think was the owner at 1-234-555-1212"... We call this supplied
number and then accept whatever the person claiming to be Bob then
tells us?  

Example:  Bob says: "No, it's still around.  We are actually using  
those numbers internally.  Please update the records to say "BobNet" 
which is our DBA name for Company ABC & here's my new email address"
Or do we only accept what Bob says if he claims the resources should
be returned?  

Note the liability to ARIN in either of the above cases in acting 
without clear legal documentation (not just attestation from "Bob")
is likely unacceptable, and doesn't improve the database integrity
but actually weakens it (not to mention the resource hijacking or 
potentially wrongful reclamation from an otherwise unreachable 
company which Mr. Smith or "Bob" are now seeking revenge against...)

> I cannot express how frustrated I am that ARIN seems totally unwilling
> to go after the low hanging fruit, or even fruit already dropped
> on the ground using the argument that they don't have a ladder to
> reach the fruit at the top of the tree.
> 
> Sometimes being a good steward takes effort.

We put a lot of effort into being a good steward, but that means 
actually trying to get the data correct and not just updated for 
the sake of updates. Please develop specific policies if you want 
us to relax our practices so that ARIN can know that we are indeed 
acting with clear community direction.

/John

John Curran
President and CEO
ARIN



From bicknell at ufp.org  Sat Nov  6 13:23:29 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Sat, 6 Nov 2010 10:23:29 -0700
Subject: [arin-ppml] Audits
In-Reply-To: <9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
Message-ID: <20101106172329.GA39605@ussenterprise.ufp.org>

In a message written on Sat, Nov 06, 2010 at 12:18:52PM -0400, John Curran wrote:
> I'm sorry: You are advocating that we use LinkedIn as a verification
> step? A very high number of contacts will not have LinkedIN accounts, 
> are we to then exclude them from consideration by this step? These 
> may be the only useful contacts for the resource; how do we then 
> proceed?

I have a hard time having a serious conversation with someone who
simply tries to deflect from the issue at hand.

You know quite well I was not suggesting ARIN rely solely on LinkedIn,
and in fact go on to suggest ARIN get a signed attestation from the
owner of the company that he is no longer the owner.  I was suggesting
ARIN use all resources at it's disposal, and treat them with an
appropriate degree of skepticism.

> We put a lot of effort into being a good steward, but that means 
> actually trying to get the data correct and not just updated for 
> the sake of updates. Please develop specific policies if you want 
> us to relax our practices so that ARIN can know that we are indeed 
> acting with clear community direction.

What I hear is that you're not putting a lot of effort into it, in
fact that you're not even trying because it is hard.  Every time
this issue comes up I see you in particular, and ARIN in general
expend a ton of time on the mailing lists trying to find every
possible reason to ignore what the community wants.

It's really sad.  I thought you were there to help us, not make
fun of us.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101106/2c94963b/attachment.sig>

From jbates at brightok.net  Sat Nov  6 14:04:56 2010
From: jbates at brightok.net (Jack Bates)
Date: Sat, 06 Nov 2010 13:04:56 -0500
Subject: [arin-ppml] Audits
In-Reply-To: <20101106172329.GA39605@ussenterprise.ufp.org>
References: <27141.1288874999@tristatelogic.com>	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>	<20101105181927.GA56626@ussenterprise.ufp.org>	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>	<20101106151255.GA29852@ussenterprise.ufp.org>	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
	<20101106172329.GA39605@ussenterprise.ufp.org>
Message-ID: <4CD598C8.5040102@brightok.net>

On 11/6/2010 12:23 PM, Leo Bicknell wrote:
>
> What I hear is that you're not putting a lot of effort into it, in
> fact that you're not even trying because it is hard.  Every time
> this issue comes up I see you in particular, and ARIN in general
> expend a ton of time on the mailing lists trying to find every
> possible reason to ignore what the community wants.
>

I think it comes down to 2 aspects for ARIN.

1) policy. There must be a clear and precise policy dictating what 
resources and processes ARIN should use. Honestly, ARIN should have 
things written out clear enough that it falls in the same spectrum of 
ISO 9001 (though I'm not sure they actually have a product, so an actual 
certification would seem silly, but they should have the processes 
documented to that level).

2) interpretation. Policy often isn't precise and this has left ARIN 
dealing with interpretation. They must balance the manpower they can 
afford with the tasks set in policy for them to do. Most of their 
policies have wiggle room, and they will make their own determinations 
within that wiggle room based on historical practice and manpower.

What John is asking is that a policy be drawn up to give the appropriate 
direction, that policy be discussed and modified appropriately by the 
community, and then ratified so it can be used until such time that a 
new policy overrides or changes it. The process to do this is also a policy.

1) is something we as the community do.

2) is failure of the community in it's performance of 1, and often times 
can lead to serious disagreements between community and ARIN. It is 
subject to change, though it is a drawn out process and ARIN is loathe 
to change their interpretations as it effects the community as a whole 
(and those who were subject to the first interpretation unknowingly 
become subject to the new interpretation). Generally, interpretations 
widen in scope and do not contract. This prohibits being lenient with 
part of the community and then being stricter with the rest of the 
community. This is why most interpretations are extremely conservative 
and can often be more restrictive than the community desired.


Jack


From stephen at sprunk.org  Sat Nov  6 14:20:58 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Sat, 06 Nov 2010 13:20:58 -0500
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <4F0FC5AB-8640-427F-A57F-53677C74480E@delong.com>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net> <4CD382AB.1030107@sprunk.org>
	<C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
	<4CD43014.9050606@sprunk.org>
	<4F0FC5AB-8640-427F-A57F-53677C74480E@delong.com>
Message-ID: <4CD59C8A.3080407@sprunk.org>

On 06 Nov 2010 04:08, Owen DeLong wrote:
> On Nov 5, 2010, at 9:25 AM, Stephen Sprunk wrote:
>> On 05 Nov 2010 01:56, Owen DeLong wrote:
>>> On Nov 4, 2010, at 9:06 PM, Stephen Sprunk wrote:
>>>> On 02 Nov 2010 22:30, Ted Mittelstaedt wrote:
>>>>> Ultimately the goal should be to take legacy resources away that
>>>>> are either being hoarded, or are abandoned.
>>>> "Hoarded" is a loaded term, and it's difficult to prove someone's
>>>> doing it.  "Justified" is easily determined, though, since we
>>>> _already_ have dozens of pages of policy describing exactly what
>>>> that means.
>>> What we don't have is any form of agreement by the legacy holders
>>> that the ARIN definition of justified applies to them.
>>
>> OTOH, absent an LRSA, there is no formal agreement that it doesn't.
>>
>
> Uh, generally it's pretty hard to claim that a contract is binding on
> an opt-out basis.
>
> I can't just make up a contract and then say you are subject to it's
> terms just because you don't have a contract that says otherwise.

A homeless shelter is quite certainly free to dictate people wear shoes
in order to get a free meal.

>>> Non-signatories to the LRSA are, thus, in an uncertain area.
>>> Signatories of the LRSA are clearly protected from current and
>>> future ARIN policies in this regard.
>>
>> Yes, that's an excellent carrot for folks to sign the LRSA.  We
>> disagree only about the stick.
>>
>> I don't like using sticks, but eventually we're going to run out of
>> folks that are interested in the carrot.
>>
>
> So? I really don't see the problem with leaving them alone to do their
> own thing. I'd rather see them join the community, but, I simply don't
> see any valid argument for attempting to do so by force.

There are several problems.  The most relevant to this discussion is
that, without regular contact (e.g. via annual dues), it is difficult to
keep information in WHOIS current and it's much easier for fraudsters to
steal resources.

>> I was willing to accept granting special privileges to _all_ legacy
>> holders prior to the LRSA being made available; now that it is,
>> though, I'm reluctant to accept continuing to grant those same
>> special privileges to those who do not sign.
>>
> First, I don't agree with your use of the term "special privileges".

You don't think that being exempt from revocation or having limits on
fee increases (or no fees at all, if one doesn't sign an LRSA) qualify
as "special privileges"?  How does someone with an RSA get those terms?

> Second, I really don't think legacy holders are a major problem and I
> don't see the point in pursuing them with pitchforks and torches just
> because they choose not to join the ARIN community.

I don't think pitchforks and torches are necessary, but I do think _at
minimum_ ARIN owes the community some due diligence to make sure WHOIS
is correct.

>>> I think that involuntary reclamation of legacy resources or
>>> "termination of services" to legacy holders is contrary to ARIN's
>>> best interests.
>>
>> I disagree.
>>
>
> And you are free to do so.
>
> Care to back that up with what ARIN possibly gains by doing so other
> than litigation expenses?

First, a stick would get more legacy holders to sign the LRSA--or
perhaps even an RSA.  Second, I believe a significant amount of
abandoned or unused resources would be discovered and reclaimed.  Both
outcomes benefit the community.

>>> I think that going beyond "termination of services" to the step of
>>> placing resources back into the free pool and issuing them to other
>>> organizations would be outright counter-productive for all concerned
>>> (except in the case of clear abandonment).
>>
>> It depends on the legal explanation of exactly what it is ARIN does.
>>  At the end of the day, the "resources" that ARIN "issues" to
>> registrants are merely entries in WHOIS and rDNS.  ARIN cannot
>> actually issue numbers to (or take them away from) registrants
>> because numbers themselves cannot be owned, leased, etc.
>>
>
> Yep.

If you can agree to that explanation, I don't see how you can continue
to hold the position that you do.

>> I do not see a significant difference between removing a non-paying
>> registrant's entries from WHOIS/rDNS and replacing them with a paying
>> registrant's entries that happen to have the same or similar
>> numbers.  And, frankly, if we don't do the latter, what's the point
>> in the former?  Marking a bunch of space as "permanently unavailable"
>> accomplishes little.
>>
>
> It makes it easy to filter it out so it doesn't get hijacked.

Okay, that's of benefit.

> Besides who said anything about permanently unavailable. The space is
> either held by an organization or it isn't.  If we can't findthe
> organization, we record that fact and make it visible. Eventually,
> either we find out for sure that the organization is defunct, or, we
> find out that they do still exist. In the former case, resources can
> be reclaimed. In the latter case, they cannot.

Based on John Curran's recent messages, it is very difficult and
time-consuming to reliably determine that a company is defunct.  Given
ARIN's demonstrated unwillingness to take on work that policy doesn't
explicitly require them to take, the likely result is that space would
forever be "temporarily" unavailable.

> I'm just saying we shouldn't reclaim resources until we are certain
> that the organization no longer exists.

In contrast, I think we should reclaim resources if we cannot, after a
reasonable amount of effort, determine the registrant still exists _and_
either is still using those resources or is willing to sign an LRSA.

>>> There is no document anywhere that I know of which gives ARIN any
>>> such authority to revoke legacy resources based on current ARIN
>>> policy where it differs from the policies in effect under which the
>>> legacy resources were issued.
>>
>> I forget the original Latin, but there's a famous legal principle
>> that "what is not illegal must be legal".
>
> It is illegal to enforce terms of a contract against a non-signatory.

Yes, but I don't see the relevance of that statement.

>> ARIN can add or remove any WHOIS/rDNS entry it wishes unless
>> restricted by policy or by a contract, i.e. an RSA or LRSA.  IOW,
>> since non-LRSA legacy holders have no contract restricting what ARIN
>> does, they have no (legal) standing to complain if ARIN decides to
>> stop providing them unpaid, uncontracted registry services--just like
>> a homeless person has no (legal) standing to complain if a shelter
>> decides to stop giving them free meals.  That's purely a moral issue.
>>
>
> That's an interesting theory, but, I doubt that as the successor
> registry to registries that granted the registrations to organizations
> on very different terms with no contract stating that the terms could
> be subsequently changed without agreement, ARIN would actually have as
> good a standing as you
> claim in that situation.

ARIN only inherited an obligation to provide services gratis and in
perpetuity if its predecessors actually contracted with registrants to
do so _and_ ARIN is their legal successor in interest.  I'm fairly sure
the latter is true, but I'm almost certain the former is not.

A contract is only valid if there is an exchange of "consideration"
(usually goods or services in one direction and money in the other).  If
I promise you a free meal tomorrow but fail to provide one, you _cannot_
sue me for breach of contract because you paid no "consideration" for my
promise and therefore it was not a valid contract.

>>>> One can address most of those by having other processes that add to
>>>> the same list of resources to be reviewed.  For instance, one might
>>>> consider a resource not appearing in the DFZ to be a sign of
>>>> probable non-compliance which triggers a review.  Or resources
>>>> which have not been updated in the last N years.  Or not having
>>>> valid rDNS servers.  If the review concludes they're valid, the
>>>> registrant has 24 months before they have to worry about being
>>>> hassled again.
>>> There are specific policies allowing for non-connected networks and
>>> always have been. Why would the fact that a resource does not appear
>>> in one particular view (or even several views) of the DFZ be
>>> considered a sign of probable non-compliance? As to update cycle,
>>> some organizations are actually extremely stable. ... When did
>>> maintaining valid rDNS become a requirement even for a non-legacy
>>> holder? I can't find that requirement anywhere in the NRPM.
>>
>> Those are merely possible reasons to put someone into the review
>> queue.  If it turns out their use is justified (or close to it), no
>> action will be taken against them and they're exempt from another
>> without-cause review for 24 months.
>>
>> This is _precisely_ why I put that clause in 2007-14: to clarify that
>> ARIN could review resources that _appeared_ to be unjustified without
>> needing a priori proof of such.  The remainder of 2007-14 is there to
>> make sure that, when ARIN makes use of this power, the registrant is
>> protected.  I believe that ARIN has _always_ had this power, but the
>> response to an ACSP suggestion of mine indicated that ARIN was
>> uncomfortable wielding that power without explicit policy supporting it.
>>
>
> I'm saying that going after all or even some random number of
> resources on that basis is a dubious set of selection criteria at best
> and seems rather arbitrary to me.

If I see an elderly lady down the street from me tending her garden
every day for years, but then a few days go by without any sign of her
and there's an awful smell coming from her house, it's not unreasonable
for the police to enter and check to make sure she's still alive.  If it
turns out she's fine, no harm was done.

>>>> Yes, a sufficiently cagey registrant may be able to avoid all of
>>>> our heuristics, but most won't even try to.  It's reasonable to
>>>> lose a battle to a skilled and dedicated opponent; it's absolutely
>>>> indefensible to surrender a battle when your opponent doesn't even
>>>> show up, which is where we are right now.  Let's fix the latter
>>>> problem before we worry about the former.
>>> When did this shift from stewardship to seeking battles with legacy
>>> holders? That certainly was not my intent in NRPM 12.
>>
>> It's a metaphor.
>
> It doesn't sound like one. It sounds like an attempt to go after
> legacy holders just because they didn't sign the LRSA. I don't think
> that's right.

Regardless of how you may have interpreted, it was a metaphor.

And, for the record, I'd like to see LRSA signatories reviewed as well. 
We can't revoke their space, but it's useful for the community to
understand exactly what it is we're sanctioning so that we can decide if
it's a good idea to continue offering the LRSA.

>>> What reasons do you have for actively seeking to reclaim legacy
>>> resources that are not abandoned ... ?
>>
>> Primarily, it is the moral obligation we have to the _entire
>> community_ to act as stewards in an impartial manner, and IMHO that
>> overrides any moral obligation we have to individual
>> registrants--particularly ones that refuse to participate in the
>> community or take advantage of the (exceedingly generous, IMHO) terms
>> that the LRSA offers.
>
> I think that mis-characterizes the situation. Legacy holders received
> their resources under a different set of terms from predecessor
> registries. ARIN, if it doesn't want to be the successor registry and
> wants to terminate its services to legacy holders is welcome to do so.
> In that case, ARIN should identify a successor registry to transfer
> the stewardship of those resources to.

I'd be happy for ARIN to be rid of the legacy mess if anyone were
willing to operate a viable successor registry.  However, who is going
to do that when none of its registrants will be paying for the services
they receive?

> This theory that ARIN is somehow entitled as the successor registry to
> retroactively change the terms under which legacy resources were
> issued without the consent of the recipients really strikes me as
> being quite odd.

That's exactly what happened with domain names and with the other RIRs
that inherited legacy numbers.  ARIN has been far more generous to
legacy registrants, but IMHO now that we have the LRSA, it's time for
the honeymoon to end.

>> Also, I am concerned about the complaints (and potential legal
>> action) ARIN will face if we start actively reclaiming non-legacy
>> resources but do not attempt to reclaim (non-LRSA) legacy resources.
>>  Worse, showing irresponsibility here may justify attempts by others
>> to impose governmental (i.e. ITU) interference or end community-based
>> governance entirely.
>>
>
> I think it's pretty easy to show that those resources were issued by
> predecessor registries under different terms and conditions.

IMHO, that is irrelevant.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101106/b9fdc57c/attachment.p7s>

From gbonser at seven.com  Sat Nov  6 14:41:39 2010
From: gbonser at seven.com (George Bonser)
Date: Sat, 6 Nov 2010 11:41:39 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global
	Proposal):GlobalPolicyfor IPv4 Allocations by the IANA Post
	Exhaustion- LastCall	(textrevised)
In-Reply-To: <3E4B583C-54FE-491F-866F-6ABA015E70C1@delong.com>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu><4CD0D768.3060905@ipinc.net>
	<4CD382AB.1030107@sprunk.org>
	<C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
	<5A6D953473350C4B9995546AFE9939EE0B14C7C4@RWC-EX1.corp.seven.com>
	<3E4B583C-54FE-491F-866F-6ABA015E70C1@delong.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C7CD@RWC-EX1.corp.seven.com>

> >
> I don't think that's what anyone was talking about here.
> 

Right, but the thought occurred to me while reading.  I think there
needs to be a distinction made between "legacy space" and "legacy
holders".  The implied agreement (or lack thereof) was with the holder,
not with the space.  Once the address space leaves the legacy holder,
that legacy agreement should (in my opinion) no longer hold beyond one
transfer ... the transfer from the original legacy holder.  After that,
any transfer of that space should meet current community policy.  Maybe
I am confused by the language being used by people but I see a lot of
references to "legacy space" when I believe the space itself isn't
relevant.


> To the best of my knowledge, No such thing as far as ARIN is
> concerned. If the original holder of the space isn't holding it any
> more,
> then, it is abandoned.

Ok, that is what was confusing me by the language being used.  I have
seen people throw out an address range and someone says "that is legacy
space, there isn't anything we can do".  I just want to make sure there
IS something we can do if it isn't the legacy HOLDER using the space.

 
> There is no provision and has never been any provision for a transfer
> to occur without subjecting the recipient of the transferred resources
> to an RSA for those resources.

Ok, I was confused by the language people have been using.  My
apologies.





From jcurran at arin.net  Sat Nov  6 14:44:44 2010
From: jcurran at arin.net (John Curran)
Date: Sat, 6 Nov 2010 14:44:44 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <4CD598C8.5040102@brightok.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
	<20101106172329.GA39605@ussenterprise.ufp.org>
	<4CD598C8.5040102@brightok.net>
Message-ID: <50C91A02-E968-4E21-A591-7CC167F3AD3B@arin.net>

Jack - 
 
Thank you - you've very articulately summarized the situation that ARIN faces at present in performing number resource reviews.

ARIN will exercise any degree of review & investigation that the community specifies in policy, but absent such we must be conservative in our actions in changing resource entries less we endorse incorrect data, harm innocent parties, and create undue risk for the organization and the very resources we administer.

/John

John Curran
President and CEO
ARIN

  
On Nov 6, 2010, at 2:04 PM, Jack Bates wrote:
> ...
> I think it comes down to 2 aspects for ARIN.
> 
> 1) policy. There must be a clear and precise policy dictating what resources and processes ARIN should use. Honestly, ARIN should have things written out clear enough that it falls in the same spectrum of ISO 9001 (though I'm not sure they actually have a product, so an actual certification would seem silly, but they should have the processes documented to that level).
> 
> 2) interpretation. Policy often isn't precise and this has left ARIN dealing with interpretation. They must balance the manpower they can afford with the tasks set in policy for them to do. Most of their policies have wiggle room, and they will make their own determinations within that wiggle room based on historical practice and manpower.
> 
> What John is asking is that a policy be drawn up to give the appropriate direction, that policy be discussed and modified appropriately by the community, and then ratified so it can be used until such time that a new policy overrides or changes it. The process to do this is also a policy.
> 
> 1) is something we as the community do.
> 
> 2) is failure of the community in it's performance of 1, and often times can lead to serious disagreements between community and ARIN. It is subject to change, though it is a drawn out process and ARIN is loathe to change their interpretations as it effects the community as a whole (and those who were subject to the first interpretation unknowingly become subject to the new interpretation). Generally, interpretations widen in scope and do not contract. This prohibits being lenient with part of the community and then being stricter with the rest of the community. This is why most interpretations are extremely conservative and can often be more restrictive than the community desired.
> 
> Jack
> _______________________________________________
> PPML


From bill at herrin.us  Sat Nov  6 16:03:02 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 6 Nov 2010 16:03:02 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
Message-ID: <AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>

On Sat, Nov 6, 2010 at 12:18 PM, John Curran <jcurran at arin.net> wrote:
> Send listed contact Mr. John Smith an email, and Mr. Smith writes
> back and says: "Yep, the Company ABC is deceased (which I did list
> in my LinkedIN profile and am a contact for); you should contact Bob
> who I think was the owner at 1-234-555-1212"... We call this supplied
> number and then accept whatever the person claiming to be Bob then
> tells us?
>
> Example: ?Bob says: "No, it's still around. ?We are actually using
> those numbers internally. ?Please update the records to say "BobNet"
> which is our DBA name for Company ABC & here's my new email address"
> Or do we only accept what Bob says if he claims the resources should
> be returned?
>
> Note the liability to ARIN in either of the above cases in acting
> without clear legal documentation (not just attestation from "Bob")
> is likely unacceptable, and doesn't improve the database integrity
> but actually weakens it (not to mention the resource hijacking or
> potentially wrongful reclamation from an otherwise unreachable
> company which Mr. Smith or "Bob" are now seeking revenge against...)

John,

At some point within the next 24 months I think it very likely that
this community will ask ARIN to aggressively recover unused space.
This will likely include some sort of mechanism for recovering space
whose registrants can't be contacted or won't confirm the resources'
continued use.  I think it would be very helpful to have some legal
guidance from ARIN counsel as to the least risky approaches to doing
so before that policy gets drafted.

Regards.
Bill Herrin




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


From rfg at tristatelogic.com  Sat Nov  6 21:30:33 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Sat, 06 Nov 2010 18:30:33 -0700
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com> 
Message-ID: <40102.1289093433@tristatelogic.com>


In message <AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE at mail.gmail.com>,  
William Herrin <bill at herrin.us> wrote:

>John,
>
>At some point within the next 24 months I think it very likely that
>this community will ask ARIN to aggressively recover unused space.
>This will likely include some sort of mechanism for recovering space
>whose registrants can't be contacted or won't confirm the resources'
>continued use.  I think it would be very helpful to have some legal
>guidance from ARIN counsel as to the least risky approaches to doing
>so before that policy gets drafted.

I want to do two things, and I'll try to do them as briefly as I can.

First, strange as it may sound, I want to come to the defense of John
Curran just a bit.

I just want to say that I also dislike that idea that was floated of
using LinkedIn as a research tool, e.g. for helping to find bits of
defunctness.  And I also am somewhat incredulous that it was even
suggested.  Let me explain...

In the first instance, I loath _any_ proprietary solution to anything.
I would dislike the notion of ARIN using LinkedIn for the exact same
reasons I would dislike the U.S. General Services Administration
"standardizing" on Microsoft Word.  Not only is it in some sense improper,
but it's also dangerous.  What if the proprietary solution and/or the
company behind it either evaporates or decides to treble its prices
someday?

But more to the point, it is just a technically impactical suggestion
from the get go.

I have had some successes of late finding hijacked IP blocks, but in
general, everything... every tool and process I have used to do that
is automated, and it has to be, because its a big world out there.

ARIN can't buy enough humans to sit and tap-tap-tap at www.linkedin.com
all day, looking for several hundred thousand POCs.  It's just not a
viable way to approach a problem at this scale.

OK, so now that I got that out of the way...

The second thing I wanted to do was to float a few trial balloons of my
own for possible approaches to this overall problem.

First, as I've said, anything that people ask ARIN to do has to be scalable
to (at least) a couple of hundred thousand instances.  Manual approaches
just won't do.

So anyway, there are four possible ways of contacing any POC, e-mail, phone
(voice), FAX, and snail-mail.

Although I don't know for sure... and John C. can fill in the blanks here...
I suspect that ARIN right now is trying to contact POCs only via e-mail...
in a mostly or entirely automated fashion.

In a nutshell, I believe that all four methods of contact can be both (a)
automated and also (b) outsourced, where appropriate.

I also believe that all four methods should be tried, in an automated
fashion, repeatedly, over a period of time, until such time as evidence
of life is obtained for some given POC.  Evidence of life would be
be obtained by including a magic cookie of some kind and asking the
recipient to type it into www.arin.net if he/she is in fact the contact
we're looking for.  (I also believe that all of this need not be and
should not be prohibitively expensive, especially if parts of it are
outsourced to companies that specialize in these sorts of things.)

I also believe that if in fact all four contact methods are tried (in
an automated fashion, as per the above) repeatedly, three times over
a 90 day period, spacing the attempt at 30 day intervals, and if no
sign of life is received, then the POC should thereafter be marked as
defunct, and that any number resource allocations for which all POCs
are currently marked defunct should be yanked from the data base
forthwith and returned to the (ARIN) free pool.

I also believe that some of these contact messages wll undoubtedly end
up being wrongly directed (e.g. due to changes of address) into the
hands of frivolous people who have nothing better to do and who will
type in the magic cookie, even though they have no connection to the
actual POC.  To eliminate this possibility effectively, I believe that
the proof of life should be mandated to include a fully refundable
$10 charge, payable via check, money order, or credit card... said
charge to be fully refunded by ARIN promptly upon reciept (again,
hopefully in a totally automated fashion).

This trivial refundable one-time charge scheme should effectively shake
out all instances of non-POCs who are just playing pranks, and also,
importantly, should shake out all instances of actual dead companies
that just happen to still have living POCs, but ones that themselves
are not really entitled to claim the dead organization's old number
resources.  (There's a big difference between merely SAYING that you
are the successor in interest of Acme Widgets, Inc., i.e. when you
actually aren't, and putting that on your credit card.  Even dimwits
who would not normally think of the former as being serious ``fraud''
will, I think, be given pause when they consider perpetrating unambiguous
criminal wire fraud which involves money changing hands, even if only
a small amount.)

In my opinion, any bellyaches or complaints about this trivially small,
fully refundable charge would be, at best disingenuous.  Can anyone
seriously complain about something that only costs them a bit of time
and maybe, at worst (if they have no access to a computer?) a postage
stamp?

And its not like I'm the first one to think of a "refundable charge"
scheme like this.  Many online businesses have been using exactly such
a scheme for years now, with great success and few complaints.  It has
come time, I believe, for ARIN to adopt proven, industry-tested technical
solutions for well understood problems, e.g. separating the real from
the pranksters (and/or from the dead).

Lastly, and probably most controversially, it is my personal feeling that
that all of the above should be applied even-handedly, across the board,
for both non-legacy and legacy allocations and POCs.  But I understand
that others are likely to feel differently, and I think the scheme I
have described would still have substantial merit even if only applied
to a subset of ARIN region allocations, e.g. just the non-legacy stuff.

I suspect that if the above scheme were put into practice, within 90
days as much as 40% of all ARIN region allocated IP space would be
reclaimed.

I don't know how much that would be, but it would be a lot.

And no, I do not see any of this as creating _any_ sorts of new legal
liability for ARIN.  In fact I will go further and say that I suspect
that most of the people who postulate publically about such possibilities
have themselves never set foot inside of a courtroom.

(Judges are not idiots, and they don't like people making work for them
unnecessarily, e.g. by filing court cases when they could just as easly...
or perhaps even more easily... worked out the problem amicably, without
any help from the judicial system.  So all _theoretical_ liability that
might, in theory, accrue from the above scheme can be eliminated trivially,
simply by adding to all of the above a community directive to ARIN that
if anybody ever shows up, very late, after their suff has already been
reclaimed, and says that they are mad and they want their stuff back,
ARIN should bend over backwards to give them some fresh new replacement
stuff that will do just as well... and a special small reserve pool should
be set aside and held by ARIN against exactly such rare and highly unlikely
possibilities.  If anybody _still_ wants to sue, even after being given
equal-sized replacement stuff, then they are just going to look like
assholes in court, _and_ they would have to demonstrated that they were
somehow harmed by being given a shiny new /18 to replace the /18 they
are bitching about... the one that got reclaimed.  And as long as ARIN
does reasonble due diligence... e.g. checking for emptyness and/or non-
routedness...  before it reclaims anything, then the whiner is going to
have a tough time selling his theory of ``harm'' in court, because there
isn't any.)


Regards,
rfg


From warren at wholesaleinternet.com  Sat Nov  6 20:50:42 2010
From: warren at wholesaleinternet.com (Warren Johnson)
Date: Sat, 6 Nov 2010 19:50:42 -0500
Subject: [arin-ppml] Comcast
Message-ID: <043301cb7e15$cf2fa410$6d8eec30$@com>

Anyone else notice that Comcast got 8 million IPs?

http://www.ipv4depletion.com/





From jbates at brightok.net  Sat Nov  6 22:04:52 2010
From: jbates at brightok.net (Jack Bates)
Date: Sat, 06 Nov 2010 21:04:52 -0500
Subject: [arin-ppml] Comcast
In-Reply-To: <043301cb7e15$cf2fa410$6d8eec30$@com>
References: <043301cb7e15$cf2fa410$6d8eec30$@com>
Message-ID: <4CD60944.3020505@brightok.net>

On 11/6/2010 7:50 PM, Warren Johnson wrote:
> Anyone else notice that Comcast got 8 million IPs?
>
> http://www.ipv4depletion.com/
>

Good for them. I'm sure they needed it.


Jack


From jcurran at arin.net  Sat Nov  6 22:07:48 2010
From: jcurran at arin.net (John Curran)
Date: Sat, 6 Nov 2010 22:07:48 -0400
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
	<AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>
Message-ID: <74580385-7F72-464D-8E75-B8B74445402F@arin.net>

On Nov 6, 2010, at 4:03 PM, William Herrin wrote:
> 
> John,
> 
> At some point within the next 24 months I think it very likely that
> this community will ask ARIN to aggressively recover unused space.
> This will likely include some sort of mechanism for recovering space
> whose registrants can't be contacted or won't confirm the resources'
> continued use.  I think it would be very helpful to have some legal
> guidance from ARIN counsel as to the least risky approaches to doing
> so before that policy gets drafted.

Legal review occurs as part of the policy development process for 
any draft policy, but I understand what you are requesting.  We 
have looked into this in the past regarding reclamation of number
resources from defunct companies and have determined that the least 
risky approach is to have clear legal dissolution of the holder, or 
to have one of the contacts on the resource make a statement that it 
can be reclaimed.  To the extent that a policy is put forth which 
directs ARIN to proceed in additional circumstances, we'll have a
legal review done of the best options to minimize the risk.

/John

John Curran
President and CEO
ARIN







From marty at akamai.com  Sat Nov  6 23:48:42 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Sat, 6 Nov 2010 23:48:42 -0400
Subject: [arin-ppml] Comcast
In-Reply-To: <043301cb7e15$cf2fa410$6d8eec30$@com>
Message-ID: <C8FB99DA.168A8%marty@akamai.com>




On 11/6/10 8:50 PM, "Warren Johnson" <warren at wholesaleinternet.com> wrote:

> Anyone else notice that Comcast got 8 million IPs?
> 
> http://www.ipv4depletion.com/




Yes. And? Please be explicit and detailed if you opt to answer in the
negative.


-M<





From owen at delong.com  Sun Nov  7 01:48:48 2010
From: owen at delong.com (Owen DeLong)
Date: Sat, 6 Nov 2010 23:48:48 -0700
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <61093.1289033556@tristatelogic.com>
References: <61093.1289033556@tristatelogic.com>
Message-ID: <E1F34DE7-B03F-4853-A929-B15C24E9368B@delong.com>


On Nov 6, 2010, at 1:52 AM, Ronald F. Guilmette wrote:

> 
> In message <C8FA2E84.167F4%marty at akamai.com>, 
> "Hannigan, Martin" <marty at akamai.com> wrote:
> 
>> Do you think we could get another year or two our of v4 if we are able to
>> recover any addresses that are being utilized fraudulently?
>> 
>> Ron? Ted? Leo?
> 
> Does it matter?
> 
> I think you are asking the wrong question.
> 
> Let me explain why I say that.
> 
> Quite simply, I'm looking at this v4->v6 transtion and I frankly think
> its going to be a debacle of historic proportions, not because people
> of good will haven't been working their butts off to try to make it all
> go smoothly... many many surely have... but rather because they are all
> struggling, vainly, I think, against one of the most fundamental aspects
> of human nature, inertia.  And against that, they are nearly powerless.
> 
Right, so, inertia will receive a rather large force acting on bodies
when IPv4 runs out.

> We have, I think, a model for how a mass technology transition like this
> can be pulled off with a reasonable level of success and without too
> awfully much confusion and pain, i.e. the transition, in North America,
> from analog to digital TV.  In that transition also, we had producers
> and consumers and a massive chicken & egg problem, but somehow it all
> worked.  I think it worked for one simple reason... somebody, and I'm
> not even sure who (the government?) put their foot down at some point
> and said ``OK, after this date certain, EVERYBODY is going to get onto
> the new standard, and to make sure that we get even the lazy, and the
> stupid, and the die-hards to do that, we are going to actually pull
> the plug on the old system and SHUT THE DAMN THING DOWN ENTIRELY as of
> date X.''
> 
The main reason that transition wasn't so painful is because regulators
were able to force the largest dependencies to switch. That doesn't apply
here.

The set top box program from NTIA was an absolute disaster of epoch
proportion in terms of the consumer confusion and irritation created,
but, $40 STBs are a pretty easy thing for the majority of consumers
to eat anyway, so, at the end of the day, the coupon problems were
mostly noise.

The IPv6 transition, unfortunately, isn't as easy as putting a $40
STB in front of every computer, so, the CPE solution space is
also different.

I don't think your model fits as well as you think it does, and, we don't
have time to apply it at this point, anyway.

> For whatever reasons... and I don't even know the reasons because I
> wansn't in the room at the time... the decision was made that this
> would NOT be the way the v4->v6 transition would be handled... no
> big brother coming in and pointing a gun at all our heads, no date
> certain for the ``universal'' changeover, and most importantly, no
> committment by anybody, as far as I know, to turn down and turn off
> IPv4.
> 
Note: At the end of the last deadline, the FCC tried to get the broadcasters
to accept yet another extension to the deadline and the broadcasters basically
said "Look... You set a date by which we had to be on digital. You don't have
anything that legally requires us to keep running analog and we're stopping
because it's costing too much to keep it running."

So... While regulation and a date certain got the ball rolling, it was actually
the industry decision not to keep spending money on the legacy that
actually completed the transition and turned off analog. The FCC actually
wanted to extend the date.

> To be clear, I am not criticizing the decision to try to operate the old
> and the new, v4 and v6, in parallel for an extended period of time, nor
> would I, because I am almost completely ignorant of the reasoning or argu-
> uments that went into that decision.  I am only offering my observations
> on what seems likely to unfold, based on that decision.
> 
Extended parallelism was a good plan. The problem was that we
did a poor job of convincing CxOs and others that they needed to
add IPv6 capabilities sooner rather than later.

> And what seems most likely to me is that v4 will be around and will be
> in active use for another 5, 10, and possibly even 20 years.  As long as
> you can be v4 and yet still have v6 on the side, some people and organi-
> zations will continue to cling to v4 like a life preserver.  And they
> will be right to do so as long as there are _other_ people they want to
> communicate with who are v4 only.  (And there will be.)
> 
I doubt v4 will ever be fully deprecated, but, I do think its use as a
globally routed internet protocol will probably only last 3-5 years
after address runout.

> I see a big potential downside here for future innovation.
> 
Maybe, maybe not. Certainly IPv4 has had several downsides
for innovation, not the least of which is NAT. I think IPv6 will
eventually encourage quite a bit of innovation, but, the longer
we take to transition the longer that will take to achieve
fruition.


> So what's going to happen to the next generation of Internet innovations
> and innovators?  Are they going to be hamstrung in their quests for success
> because they can't get any IPv4 and because they have the misfortune of
> comming online at a time when 50% of the planet still speaks only that?
> How will tomorrow's New Upstarts compete against the Old Guard, when the
> latter has access to 100% market share while the former only has access
> to 50% of that?
> 
Nope... Not getting IPv4 is not what will hamstring them. The innovation
will be happening in IPv6 and the rest of the internet will adapt to IPv6
relatively rapidly once they no longer have the option of remaining at
rest.

> I don't know what the next great and indispensible Internet site or service
> is going to be.  I wish I did.  All I know is that there _is_ going to be
> one... or rather many.  Do _you_ want to be the one to tell the next great
> Internet innovators that they are SOL as far as IPv4 connectivity simply
> because a bunch of crooks got there ahead of them and stole what remained
> of the IPv4 space (and because nobody even took the time to clean that mess
> up)?  I don't.
> 
First, characterizing the users of the majority of address space as crooks
presumes facts not in evidence.

Second, no matter how you slice it, we need more than 3.2 billion unicast
addresses and IPv4 doesn't scale. So I have no problem telling them or
anyone else that IPv4 is dying and IPv6 is the place where future
internet innovation should be happening.

> So who would you rather see get the last remaining bits of the IPv4 space...
> the next eBay or Google or Huffington Post or Facebook, or a bunch of
> fraudsters?
> 
I could care less... I'm much more concerned at this point with making sure
that eBay, Google, Huffington Post, Facebook, and whoever else needs it
can get and use IPv6 address space.

> In short, I don't think it is a question of how long we can keep on giving
> _everybody_ (and every toaster) more IPv4 space.  To me the question comes
> back to stewardship.... as long as IPv4 lives it should have good stewardship
> and somebody should make sure that deserving and needy entities get preference
> for WHATEVER amounts remain... including whatever amounts can be recovered...
> in preference over both (a) crooks and also (b) toasters & refrigerators.

Good stewardship includes prioritizing where to put resources. That includes
human resources. Applying human resources that could be used to deploy IPv6
to projects to recover IPv4 is not good stewardship at this point. It might be
good IPv4 stewardship, but, it is not good internet stewardship and it is not
good management of resources on behalf of the community.

Owen



From owen at delong.com  Sun Nov  7 02:27:07 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 7 Nov 2010 00:27:07 -0700
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
	for IPv4 Allocations by the IANA Post Exhaustion- Last
	Call	(textrevised)
In-Reply-To: <4CD59C8A.3080407@sprunk.org>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net> <4CD382AB.1030107@sprunk.org>
	<C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
	<4CD43014.9050606@sprunk.org>
	<4F0FC5AB-8640-427F-A57F-53677C74480E@delong.com>
	<4CD59C8A.3080407@sprunk.org>
Message-ID: <647376A0-7C13-421B-91A2-2D910B5B1848@delong.com>


On Nov 6, 2010, at 11:20 AM, Stephen Sprunk wrote:

> On 06 Nov 2010 04:08, Owen DeLong wrote:
>> On Nov 5, 2010, at 9:25 AM, Stephen Sprunk wrote:
>>> On 05 Nov 2010 01:56, Owen DeLong wrote:
>>>> On Nov 4, 2010, at 9:06 PM, Stephen Sprunk wrote:
>>>>> On 02 Nov 2010 22:30, Ted Mittelstaedt wrote:
>>>>>> Ultimately the goal should be to take legacy resources away that
>>>>>> are either being hoarded, or are abandoned.
>>>>> "Hoarded" is a loaded term, and it's difficult to prove someone's
>>>>> doing it.  "Justified" is easily determined, though, since we
>>>>> _already_ have dozens of pages of policy describing exactly what
>>>>> that means.
>>>> What we don't have is any form of agreement by the legacy holders
>>>> that the ARIN definition of justified applies to them.
>>> 
>>> OTOH, absent an LRSA, there is no formal agreement that it doesn't.
>>> 
>> 
>> Uh, generally it's pretty hard to claim that a contract is binding on
>> an opt-out basis.
>> 
>> I can't just make up a contract and then say you are subject to it's
>> terms just because you don't have a contract that says otherwise.
> 
> A homeless shelter is quite certainly free to dictate people wear shoes
> in order to get a free meal.
> 
Yes, but, once you had a man that isn't wearing shoes a meal, you
can't then take the meal back because you now require shoes.

>>>> Non-signatories to the LRSA are, thus, in an uncertain area.
>>>> Signatories of the LRSA are clearly protected from current and
>>>> future ARIN policies in this regard.
>>> 
>>> Yes, that's an excellent carrot for folks to sign the LRSA.  We
>>> disagree only about the stick.
>>> 
>>> I don't like using sticks, but eventually we're going to run out of
>>> folks that are interested in the carrot.
>>> 
>> 
>> So? I really don't see the problem with leaving them alone to do their
>> own thing. I'd rather see them join the community, but, I simply don't
>> see any valid argument for attempting to do so by force.
> 
> There are several problems.  The most relevant to this discussion is
> that, without regular contact (e.g. via annual dues), it is difficult to
> keep information in WHOIS current and it's much easier for fraudsters to
> steal resources.
> 
Which is why I advocate annual contact and marking of unresponsive
contacts. That should make it possible to solve the theft problems
through filtration.

>>> I was willing to accept granting special privileges to _all_ legacy
>>> holders prior to the LRSA being made available; now that it is,
>>> though, I'm reluctant to accept continuing to grant those same
>>> special privileges to those who do not sign.
>>> 
>> First, I don't agree with your use of the term "special privileges".
> 
> You don't think that being exempt from revocation or having limits on
> fee increases (or no fees at all, if one doesn't sign an LRSA) qualify
> as "special privileges"?  How does someone with an RSA get those terms?
> 
No, I do not. I think they are the existing T&Cs of yesteryear.

There are lots of examples of T&Cs given to people in the past that are
not available to new customers. For example, if you have an AT&T
unlimited plan for your iPhone or iPad, you are on different T&Cs than
anyone can get with new service today.

Would you call people on unlimited plans "people with special privileges"?
I wouldn't.

>> Second, I really don't think legacy holders are a major problem and I
>> don't see the point in pursuing them with pitchforks and torches just
>> because they choose not to join the ARIN community.
> 
> I don't think pitchforks and torches are necessary, but I do think _at
> minimum_ ARIN owes the community some due diligence to make sure WHOIS
> is correct.
> 
Agreed. However, it appears that your definition of due diligence has
some elements in common with my definition of pitchforks and torches.

>>>> I think that involuntary reclamation of legacy resources or
>>>> "termination of services" to legacy holders is contrary to ARIN's
>>>> best interests.
>>> 
>>> I disagree.
>>> 
>> 
>> And you are free to do so.
>> 
>> Care to back that up with what ARIN possibly gains by doing so other
>> than litigation expenses?
> 
> First, a stick would get more legacy holders to sign the LRSA--or
> perhaps even an RSA.  Second, I believe a significant amount of
> abandoned or unused resources would be discovered and reclaimed.  Both
> outcomes benefit the community.
> 
Sticks can accomplish lots of things. However, the question isn't whether
or not it is possible to get signatures using a stick. The question is whether
or not it is valid to use a stick.

Information can be obtained through torture or "enhanced interrogation
techniques". Often it isn't reliable information, but, that's a digression.
The real question is whether or not it is appropriate to use torture
or "enhanced interrogation techniques" to obtain information regardless
of quality.

I don't support "enhanced interrogation techniques" and I think it would
not be correct to use sticks here, either.

>>>> I think that going beyond "termination of services" to the step of
>>>> placing resources back into the free pool and issuing them to other
>>>> organizations would be outright counter-productive for all concerned
>>>> (except in the case of clear abandonment).
>>> 
>>> It depends on the legal explanation of exactly what it is ARIN does.
>>> At the end of the day, the "resources" that ARIN "issues" to
>>> registrants are merely entries in WHOIS and rDNS.  ARIN cannot
>>> actually issue numbers to (or take them away from) registrants
>>> because numbers themselves cannot be owned, leased, etc.
>>> 
>> 
>> Yep.
> 
> If you can agree to that explanation, I don't see how you can continue
> to hold the position that you do.
> 
It's really not that hard.

>>> I do not see a significant difference between removing a non-paying
>>> registrant's entries from WHOIS/rDNS and replacing them with a paying
>>> registrant's entries that happen to have the same or similar
>>> numbers.  And, frankly, if we don't do the latter, what's the point
>>> in the former?  Marking a bunch of space as "permanently unavailable"
>>> accomplishes little.
>>> 
>> 
>> It makes it easy to filter it out so it doesn't get hijacked.
> 
> Okay, that's of benefit.
> 
>> Besides who said anything about permanently unavailable. The space is
>> either held by an organization or it isn't.  If we can't findthe
>> organization, we record that fact and make it visible. Eventually,
>> either we find out for sure that the organization is defunct, or, we
>> find out that they do still exist. In the former case, resources can
>> be reclaimed. In the latter case, they cannot.
> 
> Based on John Curran's recent messages, it is very difficult and
> time-consuming to reliably determine that a company is defunct.  Given
> ARIN's demonstrated unwillingness to take on work that policy doesn't
> explicitly require them to take, the likely result is that space would
> forever be "temporarily" unavailable.
> 
Which I don't see as a particular problem as long as it is at least marked
that way.

1.	Recovering the space isn't of any particular benefit to the community.

2.	Having legacy holders that are using the space able to continue doing
	so is of benefit and is our moral obligation IMHO.

3.	Identifying blocks which are in disuse or have invalid contact information
	and making the community aware of blocks with that status is of benefit
	to the community.

Re-issuing the space to someone else absent definite knowledge that
it is no longer in legitimate use for its original purpose is going beyond
3 to achieve 1 to the detriment of 2.

>> I'm just saying we shouldn't reclaim resources until we are certain
>> that the organization no longer exists.
> 
> In contrast, I think we should reclaim resources if we cannot, after a
> reasonable amount of effort, determine the registrant still exists _and_
> either is still using those resources or is willing to sign an LRSA.
> 
Yes... I understood that before. I still disagree with you, as I have
restated above.

>>>> There is no document anywhere that I know of which gives ARIN any
>>>> such authority to revoke legacy resources based on current ARIN
>>>> policy where it differs from the policies in effect under which the
>>>> legacy resources were issued.
>>> 
>>> I forget the original Latin, but there's a famous legal principle
>>> that "what is not illegal must be legal".
>> 
>> It is illegal to enforce terms of a contract against a non-signatory.
> 
> Yes, but I don't see the relevance of that statement.
> 
What you are proposing isn't something that is legal because it isn't
illegal. What you are proposing is attempting to enforce terms of a
contract that doesn't exist against an organization that never
agreed to the non-existant contract in the first place.

>>> ARIN can add or remove any WHOIS/rDNS entry it wishes unless
>>> restricted by policy or by a contract, i.e. an RSA or LRSA.  IOW,
>>> since non-LRSA legacy holders have no contract restricting what ARIN
>>> does, they have no (legal) standing to complain if ARIN decides to
>>> stop providing them unpaid, uncontracted registry services--just like
>>> a homeless person has no (legal) standing to complain if a shelter
>>> decides to stop giving them free meals.  That's purely a moral issue.
>>> 
>> 
>> That's an interesting theory, but, I doubt that as the successor
>> registry to registries that granted the registrations to organizations
>> on very different terms with no contract stating that the terms could
>> be subsequently changed without agreement, ARIN would actually have as
>> good a standing as you
>> claim in that situation.
> 
> ARIN only inherited an obligation to provide services gratis and in
> perpetuity if its predecessors actually contracted with registrants to
> do so _and_ ARIN is their legal successor in interest.  I'm fairly sure
> the latter is true, but I'm almost certain the former is not.
> 
It's very gray, but, whether there is a written contract or not, certainly,
at the time the resources were issued, it was the standard policy
and expectation that whois, in-addr, and registration services would
be performed by the registry gratis in perpetuity.

> A contract is only valid if there is an exchange of "consideration"
> (usually goods or services in one direction and money in the other).  If
> I promise you a free meal tomorrow but fail to provide one, you _cannot_
> sue me for breach of contract because you paid no "consideration" for my
> promise and therefore it was not a valid contract.
> 
The exchange required does not have to be direct. There are many
instances where contracts create third-party rights and/or obligations.

In this case, the USDoD, DARPA, and USDoC have provided consideration
and a contract to the predecessor registries to operate the services.
Legacy holders are a third-party obligation of those contracts.

>>>>> One can address most of those by having other processes that add to
>>>>> the same list of resources to be reviewed.  For instance, one might
>>>>> consider a resource not appearing in the DFZ to be a sign of
>>>>> probable non-compliance which triggers a review.  Or resources
>>>>> which have not been updated in the last N years.  Or not having
>>>>> valid rDNS servers.  If the review concludes they're valid, the
>>>>> registrant has 24 months before they have to worry about being
>>>>> hassled again.
>>>> There are specific policies allowing for non-connected networks and
>>>> always have been. Why would the fact that a resource does not appear
>>>> in one particular view (or even several views) of the DFZ be
>>>> considered a sign of probable non-compliance? As to update cycle,
>>>> some organizations are actually extremely stable. ... When did
>>>> maintaining valid rDNS become a requirement even for a non-legacy
>>>> holder? I can't find that requirement anywhere in the NRPM.
>>> 
>>> Those are merely possible reasons to put someone into the review
>>> queue.  If it turns out their use is justified (or close to it), no
>>> action will be taken against them and they're exempt from another
>>> without-cause review for 24 months.
>>> 
>>> This is _precisely_ why I put that clause in 2007-14: to clarify that
>>> ARIN could review resources that _appeared_ to be unjustified without
>>> needing a priori proof of such.  The remainder of 2007-14 is there to
>>> make sure that, when ARIN makes use of this power, the registrant is
>>> protected.  I believe that ARIN has _always_ had this power, but the
>>> response to an ACSP suggestion of mine indicated that ARIN was
>>> uncomfortable wielding that power without explicit policy supporting it.
>>> 
>> 
>> I'm saying that going after all or even some random number of
>> resources on that basis is a dubious set of selection criteria at best
>> and seems rather arbitrary to me.
> 
> If I see an elderly lady down the street from me tending her garden
> every day for years, but then a few days go by without any sign of her
> and there's an awful smell coming from her house, it's not unreasonable
> for the police to enter and check to make sure she's still alive.  If it
> turns out she's fine, no harm was done.
> 
Sure... But, what you are proposing is that if the police don't find her
and don't find a body, they should let you sell her house.

That's where we are disagreeing. I'm all for ARIN contacting the POCs,
flagging the resources as potentially abandoned if there's no old
lady and no corpse. Where we disagree is when it comes to selling
her house if we can't find her.

>>>>> Yes, a sufficiently cagey registrant may be able to avoid all of
>>>>> our heuristics, but most won't even try to.  It's reasonable to
>>>>> lose a battle to a skilled and dedicated opponent; it's absolutely
>>>>> indefensible to surrender a battle when your opponent doesn't even
>>>>> show up, which is where we are right now.  Let's fix the latter
>>>>> problem before we worry about the former.
>>>> When did this shift from stewardship to seeking battles with legacy
>>>> holders? That certainly was not my intent in NRPM 12.
>>> 
>>> It's a metaphor.
>> 
>> It doesn't sound like one. It sounds like an attempt to go after
>> legacy holders just because they didn't sign the LRSA. I don't think
>> that's right.
> 
> Regardless of how you may have interpreted, it was a metaphor.
> 
> And, for the record, I'd like to see LRSA signatories reviewed as well. 
> We can't revoke their space, but it's useful for the community to
> understand exactly what it is we're sanctioning so that we can decide if
> it's a good idea to continue offering the LRSA.
> 
I have no problem with reviewing LRSA signatories so long as we
stick to our contractual obligations and don't attempt to revoke their
space.

>>>> What reasons do you have for actively seeking to reclaim legacy
>>>> resources that are not abandoned ... ?
>>> 
>>> Primarily, it is the moral obligation we have to the _entire
>>> community_ to act as stewards in an impartial manner, and IMHO that
>>> overrides any moral obligation we have to individual
>>> registrants--particularly ones that refuse to participate in the
>>> community or take advantage of the (exceedingly generous, IMHO) terms
>>> that the LRSA offers.
>> 
>> I think that mis-characterizes the situation. Legacy holders received
>> their resources under a different set of terms from predecessor
>> registries. ARIN, if it doesn't want to be the successor registry and
>> wants to terminate its services to legacy holders is welcome to do so.
>> In that case, ARIN should identify a successor registry to transfer
>> the stewardship of those resources to.
> 
> I'd be happy for ARIN to be rid of the legacy mess if anyone were
> willing to operate a viable successor registry.  However, who is going
> to do that when none of its registrants will be paying for the services
> they receive?
> 
I don't know, but, the point is that ARIN isn't somehow magically
entitled to the resources just because they are the (current) successor
registry.

>> This theory that ARIN is somehow entitled as the successor registry to
>> retroactively change the terms under which legacy resources were
>> issued without the consent of the recipients really strikes me as
>> being quite odd.
> 
> That's exactly what happened with domain names and with the other RIRs
> that inherited legacy numbers.  ARIN has been far more generous to
> legacy registrants, but IMHO now that we have the LRSA, it's time for
> the honeymoon to end.
> 
Holding up what happened with domain names as an example of how
ARIN should behave is not going to win any points with me. I think that
domain names have become an unmitigated mess and a profiteering
opportunity for ICANN which has led to some seriously misguided
policies in that area.

>>> Also, I am concerned about the complaints (and potential legal
>>> action) ARIN will face if we start actively reclaiming non-legacy
>>> resources but do not attempt to reclaim (non-LRSA) legacy resources.
>>> Worse, showing irresponsibility here may justify attempts by others
>>> to impose governmental (i.e. ITU) interference or end community-based
>>> governance entirely.
>>> 
>> 
>> I think it's pretty easy to show that those resources were issued by
>> predecessor registries under different terms and conditions.
> 
> IMHO, that is irrelevant.
> 
I think it's extremely relevant because that is a valid defense to the
actions you are claiming would arise.

Owen



From bicknell at ufp.org  Sun Nov  7 07:40:40 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Sun, 7 Nov 2010 04:40:40 -0800
Subject: [arin-ppml] Audits
In-Reply-To: <390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
Message-ID: <20101107124040.GA92140@ussenterprise.ufp.org>

In a message written on Sat, Nov 06, 2010 at 09:29:30AM -0400, John Curran wrote:
> Leo's message also includes both "abuse" & "defunct companies" which 
> definitely require better definition via policy before ARIN knows how to 
> ramp up these activities.  If abuse means anything other than the fraud
> definition we're using, then we need to be very clear about what you all
> believe constitutes abuse.  

I will note that in the policy text I submitted I did not include
abuse for this very reason.  It was a mistake for me to include it
in the previous message I wrote.

ARIN seems to already know what fraud is, the only question there
is if they only work reactively to community reports, or also work
proactively.  The question with proactive seems to be how much time
shoud be spent, and I suspect if I put in policy something like
"400 hours of staff time per year" or "$100k of resource per year"
there would be great pushback that these are operational details.

I think ARIN leadership is able to make a determination on an
appropriate resource level, and that over time the feedback process
of reporting at the meetings how many cases were investigated and
the result will let the leadership, with feedback from the community,
determine if that activity should get more or less resources.

> We have similar issues with resources held by "defunct" organizations, 
> since it can be very difficult to find the appropriate original legal 
> entity that was assigned a legacy resource, and then even more challenging
> to determine if they're actually defunct when there's no declaration of
> same, given the chain of mergers, acquisitions, and divestitures that 
> occurred in this the early days of this industry. 
> 
> Tracing these legally is just manageable when dealing with someone inside
> the successor firm, who has access to their legal records, and is willing 
> to be responsive to our requests for documentation (as occurs with transfers 
> due to merger and acquisition.)  Attempting to prove the same decades later 
> entirely from external legal records would to be a real adventure...

When ARIN created the LRSA a set of criteria had to be generated
to "prove" the person asking to sign the LRSA is indeed a successor
in interest to the original allocation and able to sign binding
contracts to that effect.  You allude to this in your last paragrah
here, ARIN asks for various records.  I don't know exactly what
records and don't believe ARIN publishes a list, but I believe it
is things like copies of drivers licenses or passports for the
people involved, and things like copies of articles of incorporation,
merger contracts, and so on for the business entities involved.

While ARIN asked the communnity for input on this process generating
the criteria did not require any work in the public policy process,
or even the ASCP.  Rather ARIN Legal, Staff, and Executive Management
worked out the operational details of what would be a firm legal
footing for ARIN to stand on in this process.  It is also my
understanding the set of criteria is not completely fixed, that it
can both vary case by case, but also that ARIN alters the set of
criteria over time as they learn from the process.  This is all
good.

This is why I am puzzled and frustrated that the negative version
of the same thing, "proving" a defuct company, would be treated any
differently from a process perspective.  Just as in the positive
case above ARIN will have to find multiple sources of information
that when taken as a whole provide enough evidence that ARIN Legal,
Staff, and Executitve Management find any risk is de minimus.
Indeed, the vast majority of the input to this process I believe
comes from ARIN Legal as the real fear here behind all of the
discussion is that ARIN makes the wrong determination and is then
sued by the person harmed.  The fundamental question is does ARIN
have the best defense possible in this case that it took all
reasonable actions.  That is a question that I, a non-lawyer am not
qualified to answer.

What I, as a community member, would like to direct ARIN to do in
the case of defunct companies is to perform the exact same internal
process they did in the positive case of the LRSA to generate a set
of criteria in the negative case.  Further, I would expect, just
as in the LRSA case, ARIN would start with low hanging fruit, report
to the community on the activities, and work up the tree.  At some
point community feedback will be that it costs too much to get fruit
higher on the tree, and that's ok.

However, this is the last message I'm going to post on subjects
other than my policy.  In chatting with several folks who also read
PPML about why I seem to be misunderstood on what I want one of the
pieces of feedback I've gotten is that by posting in threads with
other subjects folks may be inadvertantly conflating my desires
with greater issues in the thread.

I'm going to wait for the AC to make their determination on my
policy, and will then argue my case there where it is clear.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101107/b42f2829/attachment.sig>

From mueller at syr.edu  Sun Nov  7 09:56:55 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 7 Nov 2010 09:56:55 -0500
Subject: [arin-ppml] Comcast
In-Reply-To: <043301cb7e15$cf2fa410$6d8eec30$@com>
References: <043301cb7e15$cf2fa410$6d8eec30$@com>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC108D816@SUEX07-MBX-04.ad.syr.edu>

Some commentary on that
http://blog.internetgovernance.org/blog/_archives/2010/11/2/4670510.html#comments 

> -----Original Message-----
> 
> Anyone else notice that Comcast got 8 million IPs?
> 
> http://www.ipv4depletion.com/
> 


From mpetach at netflight.com  Sun Nov  7 16:02:25 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 7 Nov 2010 13:02:25 -0800
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
	<AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>
Message-ID: <AANLkTinfQxdkXkyt+9RsB9m=36t0GXHOg2vV=oUpVBBQ@mail.gmail.com>

On Sat, Nov 6, 2010 at 1:03 PM, William Herrin <bill at herrin.us> wrote:
> On Sat, Nov 6, 2010 at 12:18 PM, John Curran <jcurran at arin.net> wrote:
>> Send listed contact Mr. John Smith an email, and Mr. Smith writes
>> back and says: "Yep, the Company ABC is deceased (which I did list
>> in my LinkedIN profile and am a contact for); you should contact Bob
>> who I think was the owner at 1-234-555-1212"... We call this supplied
>> number and then accept whatever the person claiming to be Bob then
>> tells us?
>>
>> Example: ?Bob says: "No, it's still around. ?We are actually using
>> those numbers internally. ?Please update the records to say "BobNet"
>> which is our DBA name for Company ABC & here's my new email address"
>> Or do we only accept what Bob says if he claims the resources should
>> be returned?
>>
>> Note the liability to ARIN in either of the above cases in acting
>> without clear legal documentation (not just attestation from "Bob")
>> is likely unacceptable, and doesn't improve the database integrity
>> but actually weakens it (not to mention the resource hijacking or
>> potentially wrongful reclamation from an otherwise unreachable
>> company which Mr. Smith or "Bob" are now seeking revenge against...)
>
> John,
>
> At some point within the next 24 months I think it very likely that
> this community will ask ARIN to aggressively recover unused space.
> This will likely include some sort of mechanism for recovering space
> whose registrants can't be contacted or won't confirm the resources'
> continued use. ?I think it would be very helpful to have some legal
> guidance from ARIN counsel as to the least risky approaches to doing
> so before that policy gets drafted.
>
> Regards.
> Bill Herrin

I'm feeling kinda dumb right now, so I apologize to the rest of the list
for having to ask simple questions, but isn't recovering unused space
a trivial matter of looking to see who hasn't paid their annual fees?

Or are you talking about reclaiming space that is being paid for by a
current POC, whose records are up to date, who is in good standing
as a member organization of ARIN, but is somehow otherwise lacking
in right attributes according to the rest of the community, and must
therefore give up any rights to the space it is paying for?

If you're talking about organizations that have fallen into disarrears, I
think the non-payment of fees case should be sufficient for starting
the reclamation process, and we already have perfectly good policy
to address that.

If you're talking about taking resources away from members that are
otherwise in good standing, however, I think that's highly unconscionable,
and quite frankly would be a slap in the face to the nature of the ARIN
organization.  Pitting one member against another, encouraging us to
become informants, whispering the secrets of our fellow organizations
to anonymous tip lines in the hopes of seeing the IP Gestapo haul them
away (have I managed to invoke Godwin's law yet?) so that perhaps some
day we might be able to lay claim to their resources is barbaric, and I
cannot believe we as a community are seriously considering this.

If an organization is up to date with their contacts and their annual fees,
we have no reason to second-guess ARIN's evaluation of their IP needs,
and go stomping in, all a-jackbooted to take them back.  If their POC
data is suspected of becoming stale, *look at who is paying the annual
fees* and contact them to find out what the state of the POCs is.  Unless
people are paying ARIN by leaving unmarked bills in a paper sack outside
the front door with a note stapled to it, there should be some trail on the
money that leads back to whomever sent it.

I agree spam is a evil, nasty, icky problem.  But trying to solve that problem
by taking number resources away from organizations is the wrong way to
attack the problem.  No matter how much the workers at the DMV may dislike
child pornography on the internet, they do not deny the renewal of a person's
drivers license based on their evaluation of a person's ill-choice of viewing
material--it's not their purpose to be the judge and enforcement branch of
society around those issues.  Likewise, ARIN is responsible for stewardship
of number resources, *not* the being gatekeeper for what we consider to be
Internet decency.  If an organization provided adequate documentation to
satisfy the ARIN staff evaluation of need in order to obtain  the number
resources in the first place, and are paying their fees, and maintaining
their status as a member of ARIN in good standing, then we have no
reason to go back and try to reverse the decision of that ARIN staff
member; why are we even debating this?

Again, apologies for asking such dumb questions; I just don't understand
why we're spending so many cycles talking about taking resources back
from members in good standing who obtained them after due diligence
on the part of ARIN staff members (unless perhaps what's really obliquely
being said is that the community no longer trusts the hiring practices of
ARIN, and suspects the staffers of not adequately performing the
aforementioned due diligence, which would be a most unfortunate charge.)  :(

Thanks!

Matt


From bill at herrin.us  Sun Nov  7 16:20:26 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 7 Nov 2010 16:20:26 -0500
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTinfQxdkXkyt+9RsB9m=36t0GXHOg2vV=oUpVBBQ@mail.gmail.com>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
	<AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>
	<AANLkTinfQxdkXkyt+9RsB9m=36t0GXHOg2vV=oUpVBBQ@mail.gmail.com>
Message-ID: <AANLkTimp1W_PyDyWuDuf_8frv4R_f3=X7zhzy4Ba2Qxr@mail.gmail.com>

On Sun, Nov 7, 2010 at 4:02 PM, Matthew Petach <mpetach at netflight.com> wrote:
> I'm feeling kinda dumb right now, so I apologize to the rest of the list
> for having to ask simple questions, but isn't recovering unused space
> a trivial matter of looking to see who hasn't paid their annual fees?

Hi Matthew,

Only for space allocated by ARIN since its inception in 1997.

Space allocated prior to ARIN's existence, so-called "legacy space,"
was assigned under a sometimes informal and sometimes semi-formal
regime in which any contracts, if they existed at all, were implied.
Questions about rights, responsibilities and durations were simply not
addressed.

Legacy space falls into a status quo of sorts where ARIN keeps the
registrations as they were and doesn't touch them to the maximum
extent practical except in very limited ways at the original
registrants' request.

Regards,
Bill Herrin



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


From mpetach at netflight.com  Sun Nov  7 16:46:07 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 7 Nov 2010 13:46:07 -0800
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: <E1F34DE7-B03F-4853-A929-B15C24E9368B@delong.com>
References: <61093.1289033556@tristatelogic.com>
	<E1F34DE7-B03F-4853-A929-B15C24E9368B@delong.com>
Message-ID: <AANLkTik3KvoYjAO5WyHr9uvWLw0FXWEYnQzQOCkt1Z3_@mail.gmail.com>

On Sat, Nov 6, 2010 at 11:48 PM, Owen DeLong <owen at delong.com> wrote:
> On Nov 6, 2010, at 1:52 AM, Ronald F. Guilmette wrote:
...
>> We have, I think, a model for how a mass technology transition like this
>> can be pulled off with a reasonable level of success and without too
>> awfully much confusion and pain, i.e. the transition, in North America,
>> from analog to digital TV. ?In that transition also, we had producers
>> and consumers and a massive chicken & egg problem, but somehow it all
>> worked. ?I think it worked for one simple reason... somebody, and I'm
>> not even sure who (the government?) put their foot down at some point
>> and said ``OK, after this date certain, EVERYBODY is going to get onto
>> the new standard, and to make sure that we get even the lazy, and the
>> stupid, and the die-hards to do that, we are going to actually pull
>> the plug on the old system and SHUT THE DAMN THING DOWN ENTIRELY as of
>> date X.''
>>
> The main reason that transition wasn't so painful is because regulators
> were able to force the largest dependencies to switch. That doesn't apply
> here.
>
> The set top box program from NTIA was an absolute disaster of epoch
> proportion in terms of the consumer confusion and irritation created,
> but, $40 STBs are a pretty easy thing for the majority of consumers
> to eat anyway, so, at the end of the day, the coupon problems were
> mostly noise.
>
> The IPv6 transition, unfortunately, isn't as easy as putting a $40
> STB in front of every computer, so, the CPE solution space is
> also different.
>
> I don't think your model fits as well as you think it does, and, we don't
> have time to apply it at this point, anyway.

Over the five year period from 2005 to 2010 when the switchover (mostly)
happened (there are still analog stations running, grandfathered in, which
you can read about in the wikipedia page at
http://en.wikipedia.org/wiki/DTV_transition_in_the_United_States  )
the US government *directly* spent over $2 billion dollars on coupons
for conversion boxes, and spent an estimated $1 billion more in the
overall public awareness campaign, equipment upgrades, assistance
programs for public television stations, etc.

I imagine if the government had stepped forward with $3 billion in
money five years ago, and started a massive public awareness
and education campaign, including coupons for v4-v6 translator
appliances to go into the home to support legacy gear, we would
be in a much better position than we are now...and that's just for
one country.  The rest of the ARIN region would still have to come
up with their own funding, let alone the rest of the world.

>> For whatever reasons... and I don't even know the reasons because I
>> wansn't in the room at the time... the decision was made that this
>> would NOT be the way the v4->v6 transition would be handled... no
>> big brother coming in and pointing a gun at all our heads, no date
>> certain for the ``universal'' changeover, and most importantly, no
>> committment by anybody, as far as I know, to turn down and turn off
>> IPv4.
>>
> Note: At the end of the last deadline, the FCC tried to get the broadcasters
> to accept yet another extension to the deadline and the broadcasters basically
> said "Look... You set a date by which we had to be on digital. You don't have
> anything that legally requires us to keep running analog and we're stopping
> because it's costing too much to keep it running."
>
> So... While regulation and a date certain got the ball rolling, it was actually
> the industry decision not to keep spending money on the legacy that
> actually completed the transition and turned off analog. The FCC actually
> wanted to extend the date.

Look, that's all nice and whatever, but THERE IS NO WORLD GOVERNMENT.

There's nobody out there to say "look, planet, we're all going to flip
from v4 to v6
tomorrow, and since we're your planetary government, you have no choice to
comply."  Look at
http://en.wikipedia.org/wiki/Digital_television_transition
There's countries that won't be converted to digital TV until *2030*.

Realize that the IPv4 to IPv6 conversion will be in a similar state, where some
areas convert quickly, and others linger for a long, long time.  We don't hold
up innovation in digital television because Cambodia is still 20 years away
from it; nor did Nokia wait to make DTVs until 2010 because the US hadn't
converted, even though Finland had gone all digital in 2007.  Different areas
move at different paces, and we're not going to stop innovating on IPv6 just
because some areas are still using IPv4.  However, the need for growing the
IPv4 presence dwindles over time, as the bulk of the traffic will move to IPv6,
and thus the pressure on v4 address resources also decreases; at some point,
it will be like IPv6 was five years ago, where you could only get it by special
request.

*heh*  In fact, I can imagine Owen, ten years from now, registering
tunnelbroker4.net
and tunnelbroker4.org, and providing legacy IPv4 tunnel services for the crusty,
crufty few who live on the bleeding, trailing edge of the Internet.  ;-)

Matt


From mpetach at netflight.com  Sun Nov  7 17:06:39 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 7 Nov 2010 14:06:39 -0800
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTimp1W_PyDyWuDuf_8frv4R_f3=X7zhzy4Ba2Qxr@mail.gmail.com>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
	<AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>
	<AANLkTinfQxdkXkyt+9RsB9m=36t0GXHOg2vV=oUpVBBQ@mail.gmail.com>
	<AANLkTimp1W_PyDyWuDuf_8frv4R_f3=X7zhzy4Ba2Qxr@mail.gmail.com>
Message-ID: <AANLkTik187Fz411cQ_e_U3_0NzFtqpDiN7qy_eOdQ4A4@mail.gmail.com>

On Sun, Nov 7, 2010 at 1:20 PM, William Herrin <bill at herrin.us> wrote:
> On Sun, Nov 7, 2010 at 4:02 PM, Matthew Petach <mpetach at netflight.com> wrote:
>> I'm feeling kinda dumb right now, so I apologize to the rest of the list
>> for having to ask simple questions, but isn't recovering unused space
>> a trivial matter of looking to see who hasn't paid their annual fees?
>
> Hi Matthew,
>
> Only for space allocated by ARIN since its inception in 1997.
>
> Space allocated prior to ARIN's existence, so-called "legacy space,"
> was assigned under a sometimes informal and sometimes semi-formal
> regime in which any contracts, if they existed at all, were implied.
> Questions about rights, responsibilities and durations were simply not
> addressed.
>
> Legacy space falls into a status quo of sorts where ARIN keeps the
> registrations as they were and doesn't touch them to the maximum
> extent practical except in very limited ways at the original
> registrants' request.
>
> Regards,
> Bill Herrin

Ah.  So this is *only* about fraud/abuse in non-RSA/non-LRSA
legacy-holder space, which ARIN has no real rights over anyhow.

Gotcha.

Thanks for the clarification.  This is really a disguised "eminent domain"
issue, then, where the community votes to have ARIN act as the
"government" to seize back assets from private use that it deems
are necessary to be used in a different manner for the public good.

Perhaps, like with more traditional cases of eminent domain, the
transfer should be accompanied by monetary compensation to
the entity whose resources are being taken?  (but who would do
the paying?  ARIN, as the 'government' entity in the relationship?)

Or is the pressure here to follow a model more akin to the
contraband forfeiture procedures that states follow when seizing
illegally obtained merchandise?  (but in that case, who is to say
what constitutes a 'legal' use of address resources?)

I'm not happy with either model; forcing ARIN to play the part of the
government in eminent domain situations, to lay claim to resources
that could potentially be used by legacy holders, would need to
include compensation for resources being claimed, which, like taxes,
would raise everyone's burden.

Similarly, forcing ARIN to play 'cop' to determine when resources
were obtained illegally, or used for illegal purposes, requires us to
codify what is 'legal' and what is 'illegal' as far as use of number
resources go; and I think that's hard to do without hampering
innovation, and creating a huge overlap between ARIN and real
governments.  :(

Is there a third scenario or model for what's being proposed that
I'm missing?

Thanks!

Matt


From marka at isc.org  Sun Nov  7 17:13:25 2010
From: marka at isc.org (Mark Andrews)
Date: Mon, 08 Nov 2010 09:13:25 +1100
Subject: [arin-ppml] Fraud reporting and self-incrimination
In-Reply-To: Your message of "Sun, 07 Nov 2010 13:46:07 -0800."
	<AANLkTik3KvoYjAO5WyHr9uvWLw0FXWEYnQzQOCkt1Z3_@mail.gmail.com>
References: <61093.1289033556@tristatelogic.com>
	<E1F34DE7-B03F-4853-A929-B15C24E9368B@delong.com><AANLkTik3KvoYjAO5WyHr9uvWLw0FXWEYnQzQOCkt1Z3_@mail.gmail.com>
Message-ID: <20101107221325.AB9A264F27C@drugs.dv.isc.org>


In message <AANLkTik3KvoYjAO5WyHr9uvWLw0FXWEYnQzQOCkt1Z3_ at mail.gmail.com>, Matt
hew Petach writes:
> On Sat, Nov 6, 2010 at 11:48 PM, Owen DeLong <owen at delong.com> wrote:
> > On Nov 6, 2010, at 1:52 AM, Ronald F. Guilmette wrote:
> ...
> >> We have, I think, a model for how a mass technology transition like this
> >> can be pulled off with a reasonable level of success and without too
> >> awfully much confusion and pain, i.e. the transition, in North America,
> >> from analog to digital TV. =A0In that transition also, we had producers
> >> and consumers and a massive chicken & egg problem, but somehow it all
> >> worked. =A0I think it worked for one simple reason... somebody, and I'm
> >> not even sure who (the government?) put their foot down at some point
> >> and said ``OK, after this date certain, EVERYBODY is going to get onto
> >> the new standard, and to make sure that we get even the lazy, and the
> >> stupid, and the die-hards to do that, we are going to actually pull
> >> the plug on the old system and SHUT THE DAMN THING DOWN ENTIRELY as of
> >> date X.''
> >>
> > The main reason that transition wasn't so painful is because regulators
> > were able to force the largest dependencies to switch. That doesn't apply
> > here.
> >
> > The set top box program from NTIA was an absolute disaster of epoch
> > proportion in terms of the consumer confusion and irritation created,
> > but, $40 STBs are a pretty easy thing for the majority of consumers
> > to eat anyway, so, at the end of the day, the coupon problems were
> > mostly noise.
> >
> > The IPv6 transition, unfortunately, isn't as easy as putting a $40
> > STB in front of every computer, so, the CPE solution space is
> > also different.
> >
> > I don't think your model fits as well as you think it does, and, we don't
> > have time to apply it at this point, anyway.
> 
> Over the five year period from 2005 to 2010 when the switchover (mostly)
> happened (there are still analog stations running, grandfathered in, which
> you can read about in the wikipedia page at
> http://en.wikipedia.org/wiki/DTV_transition_in_the_United_States  )
> the US government *directly* spent over $2 billion dollars on coupons
> for conversion boxes, and spent an estimated $1 billion more in the
> overall public awareness campaign, equipment upgrades, assistance
> programs for public television stations, etc.
> 
> I imagine if the government had stepped forward with $3 billion in
> money five years ago, and started a massive public awareness
> and education campaign, including coupons for v4-v6 translator
> appliances to go into the home to support legacy gear, we would
> be in a much better position than we are now...and that's just for
> one country.  The rest of the ARIN region would still have to come
> up with their own funding, let alone the rest of the world.
> 
> >> For whatever reasons... and I don't even know the reasons because I
> >> wansn't in the room at the time... the decision was made that this
> >> would NOT be the way the v4->v6 transition would be handled... no
> >> big brother coming in and pointing a gun at all our heads, no date
> >> certain for the ``universal'' changeover, and most importantly, no
> >> committment by anybody, as far as I know, to turn down and turn off
> >> IPv4.
> >>
> > Note: At the end of the last deadline, the FCC tried to get the broadcast=
> ers
> > to accept yet another extension to the deadline and the broadcasters basi=
> cally
> > said "Look... You set a date by which we had to be on digital. You don't =
> have
> > anything that legally requires us to keep running analog and we're stoppi=
> ng
> > because it's costing too much to keep it running."
> >
> > So... While regulation and a date certain got the ball rolling, it was ac=
> tually
> > the industry decision not to keep spending money on the legacy that
> > actually completed the transition and turned off analog. The FCC actually
> > wanted to extend the date.
> 
> Look, that's all nice and whatever, but THERE IS NO WORLD GOVERNMENT.
> 
> There's nobody out there to say "look, planet, we're all going to flip
> from v4 to v6
> tomorrow, and since we're your planetary government, you have no choice to
> comply."  Look at
> http://en.wikipedia.org/wiki/Digital_television_transition
> There's countries that won't be converted to digital TV until *2030*.
> 
> Realize that the IPv4 to IPv6 conversion will be in a similar state, where =
> some
> areas convert quickly, and others linger for a long, long time.  We don't h=
> old
> up innovation in digital television because Cambodia is still 20 years away
> from it; nor did Nokia wait to make DTVs until 2010 because the US hadn't
> converted, even though Finland had gone all digital in 2007.  Different are=
> as
> move at different paces, and we're not going to stop innovating on IPv6 just
> because some areas are still using IPv4.  However, the need for growing the
> IPv4 presence dwindles over time, as the bulk of the traffic will move to I=
> Pv6,
> and thus the pressure on v4 address resources also decreases; at some point,
> it will be like IPv6 was five years ago, where you could only get it by spe=
> cial
> request.
> 
> *heh*  In fact, I can imagine Owen, ten years from now, registering
> tunnelbroker4.net
> and tunnelbroker4.org, and providing legacy IPv4 tunnel services for the cr=
> usty,
> crufty few who live on the bleeding, trailing edge of the Internet.  ;-)
> 
> Matt

Except it will be AFTR and a DHCP6 option for those that still need
the service.  Your ISP will out source their IPv4 connectivity and
it will work reasonably well similar to HE's tunnel broker service. 

You won't even notice when your ISP moves you. :-)

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From bill at herrin.us  Sun Nov  7 18:19:01 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 7 Nov 2010 18:19:01 -0500
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTik187Fz411cQ_e_U3_0NzFtqpDiN7qy_eOdQ4A4@mail.gmail.com>
References: <27141.1288874999@tristatelogic.com>
	<0F135456-F298-40D4-95BB-5C4087637B67@arin.net>
	<AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com>
	<71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net>
	<20101105181927.GA56626@ussenterprise.ufp.org>
	<8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
	<AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>
	<AANLkTinfQxdkXkyt+9RsB9m=36t0GXHOg2vV=oUpVBBQ@mail.gmail.com>
	<AANLkTimp1W_PyDyWuDuf_8frv4R_f3=X7zhzy4Ba2Qxr@mail.gmail.com>
	<AANLkTik187Fz411cQ_e_U3_0NzFtqpDiN7qy_eOdQ4A4@mail.gmail.com>
Message-ID: <AANLkTikg0U2e7mabWfYt3sfq2Se9StNd2fzazX-LPjgn@mail.gmail.com>

On Sun, Nov 7, 2010 at 5:06 PM, Matthew Petach <mpetach at netflight.com> wrote:
> On Sun, Nov 7, 2010 at 1:20 PM, William Herrin <bill at herrin.us> wrote:
>> On Sun, Nov 7, 2010 at 4:02 PM, Matthew Petach <mpetach at netflight.com> wrote:
>>> isn't recovering unused space
>>> a trivial matter of looking to see who hasn't paid their annual fees?
>>
>> Space allocated prior to ARIN's existence, so-called "legacy space,"
>> falls into a status quo of sorts where ARIN keeps the
>> registrations as they were and doesn't touch them to the maximum
>> extent practical
>
> Ah. ?So this is *only* about fraud/abuse in non-RSA/non-LRSA
> legacy-holder space, which ARIN has no real rights over anyhow.

Hi Matthew,

Not entirely, no. There's also a problem of underutilization and
improper utilization of resources by post-1997 registrants. The
canonical example is the bankrupt company that is no longer using the
addresses at all but continues paying the annual fee.

However, it is primarily an issue with the legacy-holder space, yes.


> Thanks for the clarification. ?This is really a disguised "eminent domain"
> issue, then, where the community votes to have ARIN act as the
> "government" to seize back assets from private use that it deems
> are necessary to be used in a different manner for the public good.

Why surely it can't be an eminent domain issue; eminent domain applies
to real property and IP addresses aren't property. ;-)

Seriously though, that's exactly what it is: an eminent domain-like issue.


> Is there a third scenario or model for what's being proposed that
> I'm missing?

A. ARIN could assert dominion over "abandoned" registrations,
following procedures comparable to what the government follows for
abandoned property. Announce the search for registrants. Put ads in
the right places. Any registrant who doesn't step forward is canceled.

Assuming ARIN is reasonably vocal, waits long enough and doesn't
require too high a standard of proof just to to retain the
registration as-is, who's going to legally contest it later after not
bothering to make any indication that they still use and still want a
particular block of addresses?

Besides, if the original registration so many years ago implied
nothing else, it surely implied a duty to keep contact information up
to date for so long as the registration was desired.


B. ARIN could assert dominion over legacy registrations period. Sign
the LRSA by the first or you're out. Legally challenging based solely
on ARIN's relationship with ICANN, but likely doable with legislative
support from the national governments in ARIN's territory.

If ARIN wants to dip into the shark-infested waters of seeking new
law. Which I'm very sure we don't. No amount of recovery in the legacy
space could justify giving the Congress a foothold into our business.

Regards,
Bill Herrin


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


From gbonser at seven.com  Sun Nov  7 18:30:37 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 7 Nov 2010 15:30:37 -0800
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTik187Fz411cQ_e_U3_0NzFtqpDiN7qy_eOdQ4A4@mail.gmail.com>
References: <27141.1288874999@tristatelogic.com><0F135456-F298-40D4-95BB-5C4087637B67@arin.net><AANLkTik33iB6ncfxaa+igLqM2F-0ZuXwqt5a9SnvB=4N@mail.gmail.com><71B42C3E-9582-46D7-A494-EEF79EE1CB4B@arin.net><20101105181927.GA56626@ussenterprise.ufp.org><8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net><FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com><390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net><20101106151255.GA29852@ussenterprise.ufp.org><9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net><AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com><AANLkTinfQxdkXkyt+9RsB9m=36t0GXHOg2vV=oUpVBBQ@mail.gmail.com><AANLkTimp1W_PyDyWuDuf_8frv4R_f3=X7zhzy4Ba2Qxr@mail.gmail.com>
	<AANLkTik187Fz411cQ_e_U3_0NzFtqpDiN7qy_eOdQ4A4@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C7FA@RWC-EX1.corp.seven.com>

> 
> Thanks for the clarification.  This is really a disguised "eminent
> domain"
> issue, then, where the community votes to have ARIN act as the
> "government" to seize back assets from private use that it deems
> are necessary to be used in a different manner for the public good.

I think it needs to be very clearly stated by ARIN and stated often that
once their v4 allocations run out, the public should have absolutely no
expectation of ever seeing any more.  While it might be that some space
could be recovered, ARIN is not (currently) in the IPv4 number recovery
business and that the shortage and runout of such addresses had been
foreseen for a very long time and we have arrived. 

In other words, setting the public expectation that once the addresses
have run out, then they have run out and there is a good possibility
that they won't get any more is a prudent measure to take.  Even having
a "waiting list" shouldn't be interpreted to imply that anyone on that
list will ever see their request fulfilled.

  


From bicknell at ufp.org  Sun Nov  7 19:07:24 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Sun, 7 Nov 2010 16:07:24 -0800
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTikg0U2e7mabWfYt3sfq2Se9StNd2fzazX-LPjgn@mail.gmail.com>
References: <8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
	<AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>
	<AANLkTinfQxdkXkyt+9RsB9m=36t0GXHOg2vV=oUpVBBQ@mail.gmail.com>
	<AANLkTimp1W_PyDyWuDuf_8frv4R_f3=X7zhzy4Ba2Qxr@mail.gmail.com>
	<AANLkTik187Fz411cQ_e_U3_0NzFtqpDiN7qy_eOdQ4A4@mail.gmail.com>
	<AANLkTikg0U2e7mabWfYt3sfq2Se9StNd2fzazX-LPjgn@mail.gmail.com>
Message-ID: <20101108000724.GA34324@ussenterprise.ufp.org>

In a message written on Sun, Nov 07, 2010 at 06:19:01PM -0500, William Herrin wrote:
> Not entirely, no. There's also a problem of underutilization and
> improper utilization of resources by post-1997 registrants. The
> canonical example is the bankrupt company that is no longer using the
> addresses at all but continues paying the annual fee.

There is a distinction I tried to make yesterday that I'm afraid
was lost on everyone, but your message gives me an opportunity to
be more clear.

I think it is important to separate abandoned resources from
under-utilized or miss-utilized resources.  While I'm not sure the
eminent domain argument is squarely on point, I will note that in
most states abandoned property is treated totally different from
property being taken under eminent domain.

I think this is where John and I were talking past each other.

In the case of an abandoned resource there is in theory no other
party to harm.  It is my contention ARIN doesn't need any policy
or ASCP input to go after these, staff should just do it.  There
is a minor issue that it will require some detective work, which
is staff time, which is money, but we don't decide how to allocate
money in policy.

In any sort of under-utilized or miss-utilized case there is another
party to harm.  John is absolutely right that if the ARIN community
wants ARIN to take action on these resources they need a clear
indication from the community o what "under-utilized" or "miss-utilized"
means.

It is because of these differences I think we should act on them
separately.  I think we can move on abandoned resources quickly,
with a much lighter weight process and that under-utilized or
miss-utilized resources will take a much longer process with lots
of community input.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101107/3f0c5648/attachment.sig>

From mpetach at netflight.com  Sun Nov  7 21:30:39 2010
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 7 Nov 2010 18:30:39 -0800
Subject: [arin-ppml] Audits
In-Reply-To: <20101108000724.GA34324@ussenterprise.ufp.org>
References: <8E7BDD0A-9505-4E59-B1B9-DB69188A0FD9@arin.net>
	<FE672D00-E261-4E01-9AE7-D69E90FAC7BE@delong.com>
	<390E6CAA-E0C5-4199-8217-B6F5F7E1AA47@arin.net>
	<20101106151255.GA29852@ussenterprise.ufp.org>
	<9E5B5AEF-9C69-492E-B860-5898FC383D79@arin.net>
	<AANLkTimbrLX1LhQ4+ymb3tbqKm92Rzj=w-ceiZfmKmBE@mail.gmail.com>
	<AANLkTinfQxdkXkyt+9RsB9m=36t0GXHOg2vV=oUpVBBQ@mail.gmail.com>
	<AANLkTimp1W_PyDyWuDuf_8frv4R_f3=X7zhzy4Ba2Qxr@mail.gmail.com>
	<AANLkTik187Fz411cQ_e_U3_0NzFtqpDiN7qy_eOdQ4A4@mail.gmail.com>
	<AANLkTikg0U2e7mabWfYt3sfq2Se9StNd2fzazX-LPjgn@mail.gmail.com>
	<20101108000724.GA34324@ussenterprise.ufp.org>
Message-ID: <AANLkTikTJ07gSa4dwiQMO+Xy5uGC1dM2abAmaPaNnr=H@mail.gmail.com>

On Sun, Nov 7, 2010 at 4:07 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Sun, Nov 07, 2010 at 06:19:01PM -0500, William Herrin wrote:
>> Not entirely, no. There's also a problem of underutilization and
>> improper utilization of resources by post-1997 registrants. The
>> canonical example is the bankrupt company that is no longer using the
>> addresses at all but continues paying the annual fee.
>
> There is a distinction I tried to make yesterday that I'm afraid
> was lost on everyone, but your message gives me an opportunity to
> be more clear.
>
> I think it is important to separate abandoned resources from
> under-utilized or miss-utilized resources. ?While I'm not sure the
> eminent domain argument is squarely on point, I will note that in
> most states abandoned property is treated totally different from
> property being taken under eminent domain.
>
> I think this is where John and I were talking past each other.
>
> In the case of an abandoned resource there is in theory no other
> party to harm. ?It is my contention ARIN doesn't need any policy
> or ASCP input to go after these, staff should just do it. ?There
> is a minor issue that it will require some detective work, which
> is staff time, which is money, but we don't decide how to allocate
> money in policy.
>
> In any sort of under-utilized or miss-utilized case there is another
> party to harm. ?John is absolutely right that if the ARIN community
> wants ARIN to take action on these resources they need a clear
> indication from the community o what "under-utilized" or "miss-utilized"
> means.
>
> It is because of these differences I think we should act on them
> separately. ?I think we can move on abandoned resources quickly,
> with a much lighter weight process and that under-utilized or
> miss-utilized resources will take a much longer process with lots
> of community input.

Completely agree with you, and I think it would help prevent the same
confusion I was suffering under from afflicting other participants if
we split the two situations completely apart.

Abandoned resources, ones that are not currently routed/reachable, have
no reachable POCs, and have no fee-based mechanism for recovery should
have a policy defined for how to deal with them.  They're a public nuisance,
like the abandoned car in the middle of the road, or the leftover unexploded
ordinance from a war long-past; they have a tendency to invite abuse or
mischief.

Resources that are actively in use, but are suspected of being under-utilized
or mis-utilized is a totally separate issue, and one I have a great many more
reservations about.  It becomes very, very difficult to determine the difference
between poor forecasting, weak business uptake, and intentional
misrepresentation
or fraud.  Going after Comcast with pitchforks because they got 8
million addresses
but their sales people could only sell 2 million accounts is
ludicrous.  That's not
fraud, that's simply optimistic sales projections--and show me *any* dot-com
from the late 90's that didn't have the same hockey-stick growth curve projected
into their sales forecasts.  ^_^;

So...with that in mind, I'll raise my voice against the active witch-hunting of
members in good standing, but in favour of cleaning up abandoned resources
which have become a public nuisance.   :)

Matt


From rfg at tristatelogic.com  Sun Nov  7 21:48:04 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Sun, 07 Nov 2010 18:48:04 -0800
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTik187Fz411cQ_e_U3_0NzFtqpDiN7qy_eOdQ4A4@mail.gmail.com> 
Message-ID: <34129.1289184484@tristatelogic.com>


In message <AANLkTik187Fz411cQ_e_U3_0NzFtqpDiN7qy_eOdQ4A4 at mail.gmail.com>, 
Matthew Petach <mpetach at netflight.com> wrote:

>This is really a disguised "eminent domain"
>issue, then, where the community votes to have ARIN act as the
>"government" to seize back assets from private use that it deems
>are necessary to be used in a different manner for the public good.

I don't know for sure, or precisely, what all of the different participants
in this discussion have a desire to achieve, but the sense I have gotten
from what I have read is that really, the most common desire expressed here
isn't so much to take back stuff that is "in private use", but rather to
return to the free pool stuff that _isn't_ actually being used... or at
least stuff that isn't being used by the particular entities to which the
assets in question were originally allocated, or some legitimate sucessor
thereto.

With reference to your "eminent domain" concern, I rather doubt that anyone
had (or has) in mind to come in a force the proverbial disabled elderly
couple out of their ancestral home of 57 years (and into a shabby apartment)
in order to make way for a new freeway or upscale shopping mall.  That isn't
what this is about, I think.  A better analogy might be the demolition of
a dilapidated _abandoned_ home, where the one and only owner has long since
died, without any heir apparent, and demolition of said eyesore and crime
magnet _before_ the crack heads move in, take it over, and thus drive down
_everybody's_ property values.

If you want to call the latter an exercise of "eminent domain", then so be
it.  Have at it, and more power to you.  I won't quibble over terminology.
But don't condemn the general idea based on any misunderstanding of the
motivation.  This isn't about "economic development" and evicting people
from their homes to build a sparkling new shopping mall.  The motivation
here is, I think, more about public sanitation.


Regards,
rfg



From rfg at tristatelogic.com  Sun Nov  7 22:05:57 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Sun, 07 Nov 2010 19:05:57 -0800
Subject: [arin-ppml] Audits
In-Reply-To: <AANLkTikTJ07gSa4dwiQMO+Xy5uGC1dM2abAmaPaNnr=H@mail.gmail.com> 
Message-ID: <34274.1289185557@tristatelogic.com>


In message <AANLkTikTJ07gSa4dwiQMO+Xy5uGC1dM2abAmaPaNnr=H at mail.gmail.com>, 
Matthew Petach <mpetach at netflight.com> wrote:

>Going after Comcast with pitchforks because they got 8 million addresses
>but their sales people could only sell 2 million accounts is ludicrous.

Yea, but it is still kind-of a fun way to pass time, you know, when there's
nothing on those 500 cable channels worth watching... OH!  WAIT!  That's
them too!!

>That's not fraud, that's simply optimistic sales projections

Now THAT is .sig material if I ever saw any!




From warren at wholesaleinternet.com  Mon Nov  8 17:07:52 2010
From: warren at wholesaleinternet.com (Warren Johnson)
Date: Mon, 8 Nov 2010 16:07:52 -0600
Subject: [arin-ppml] Comcast
In-Reply-To: <C8FB99DA.168A8%marty@akamai.com>
References: <043301cb7e15$cf2fa410$6d8eec30$@com>
	<C8FB99DA.168A8%marty@akamai.com>
Message-ID: <206001cb7f91$64b8f6e0$2e2ae4a0$@com>

I simply think it is intriguing that a large evangelist and proponent of
ipv6 adoption required a gigantic allocation.  It demonstrates the
complexity of the issue.

-----Original Message-----
From: Hannigan, Martin [mailto:marty at akamai.com] 
Sent: Saturday, November 06, 2010 10:49 PM
To: Warren Johnson; arin-ppml at arin.net
Subject: Re: [arin-ppml] Comcast




On 11/6/10 8:50 PM, "Warren Johnson" <warren at wholesaleinternet.com> wrote:

> Anyone else notice that Comcast got 8 million IPs?
> 
> http://www.ipv4depletion.com/




Yes. And? Please be explicit and detailed if you opt to answer in the
negative.


-M<




-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2362 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101108/57182036/attachment.bin>

From kkargel at polartel.com  Mon Nov  8 17:15:29 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 8 Nov 2010 16:15:29 -0600
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <AANLkTinSie39u8ex25U9vqNsP4ne4KQxNvGonwj0Sm4J@mail.gmail.com>
References: <4CD55B73.9030104@arin.net>
	<AANLkTinSie39u8ex25U9vqNsP4ne4KQxNvGonwj0Sm4J@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD288C049E9D@MAIL1.polartel.local>

I agree with Mr. Herrin and will take it a step further.  " shall use any reasonable and practical" equates to a no-op in policy because it leaves the determination to the executor.  Tasks need to be quantifiable to be measurable.  

I suspect that this would place these efforts at the bottom of the priority list in the 'spare time' category.  

It is great to get this discussion rolling though, Leo. 

Kevin


 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Saturday, November 06, 2010 9:43 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 120: Protecting Number Resources
> 
> On Sat, Nov 6, 2010 at 9:43 AM, ARIN <info at arin.net> wrote:
> > Policy Proposal 120: Protecting Number Resources
> > Proposal Originator: Leo Bicknell
> >
> > ARIN shall use any reasonable and practical methods to proactively
> > look for fraudulently obtained or abandoned number resources and
> > seek the return of those resources to ARIN.
> 
> Hi Leo,
> 
> Two thoughts I'd like to share...
> 
> This is too open ended for the nature of the topic. How shall ARIN
> look? Spend staff time keeping up with forums where abuse-related
> reports tend to surface? Increase random audits and generally make a
> nuisance of themselves? Something else? For something actionable, and
> something that's not going to create an extra hassle for all of us,
> this should be more specific.
> 
> How big an effort? Should ARIN dedicate 1 individual to proactively
> looking for abuse? 20? 100? As many as it takes until some diminishing
> returns formula kicks in? In a strictly technical sense, there's no
> limit to the amount of manpower that can be spent searching for
> something that might or might not be found. Thus a policy that calls
> for such proactive investigations should specify that upper limit.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From marka at isc.org  Mon Nov  8 17:40:05 2010
From: marka at isc.org (Mark Andrews)
Date: Tue, 09 Nov 2010 09:40:05 +1100
Subject: [arin-ppml] Comcast
In-Reply-To: Your message of "Mon, 08 Nov 2010 16:07:52 MDT."
	<206001cb7f91$64b8f6e0$2e2ae4a0$@com>
References: <043301cb7e15$cf2fa410$6d8eec30$@com>
	<C8FB99DA.168A8%marty@akamai.com><206001cb7f91$64b8f6e0$2e2ae4a0$@com>
Message-ID: <20101108224005.E839C6598CE@drugs.dv.isc.org>


In message <206001cb7f91$64b8f6e0$2e2ae4a0$@com>, "Warren Johnson" writes:
> 
> I simply think it is intriguing that a large evangelist and proponent of
> ipv6 adoption required a gigantic allocation.  It demonstrates the
> complexity of the issue.

You have to keep the ipv4 side running while the world spins up
their ipv6 deployments.  Unfortunately there are lots of people who
still havn't put their foot on the break in preparation to turn the
ipv6 ignition key.

Mark
> -----Original Message-----
> From: Hannigan, Martin [mailto:marty at akamai.com] 
> Sent: Saturday, November 06, 2010 10:49 PM
> To: Warren Johnson; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Comcast
> 
> 
> 
> 
> On 11/6/10 8:50 PM, "Warren Johnson" <warren at wholesaleinternet.com> wrote:
> 
> > Anyone else notice that Comcast got 8 million IPs?
> > 
> > http://www.ipv4depletion.com/
> 
> 
> 
> 
> Yes. And? Please be explicit and detailed if you opt to answer in the
> negative.
> 
> 
> -M<
> 
> 
> 
> 
> 
> ------=_NextPart_000_2061_01CB7F5F.1A1E86E0
> Content-Type: application/ms-tnef;
> 	name="winmail.dat"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> 	filename="winmail.dat"
> 
> eJ8+IjYWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
> b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgDkCAAANQAAAAsAAgABAAAAAwAmAAAAAAALACkAAAAAAAsA
> KwAAAAAAAwAuAAAAAAAeAHAAAQAAABQAAABbYXJpbi1wcG1sXSBDb21jYXN0AAIBcQABAAAAIAAA
> AAHLfhXCRdv/6tgh20zCm01+FxxCGW8ABjpKswBYpt3gCwABDgAAAAACAQoOAQAAABgAAAAAAAAA
> cbcS5WvfekSQbJ1SqLguhsKAAAADABQOAQAAAB4AKA4BAAAAQwAAADAwMDAwMDBhAXdhcnJlbkB3
> aG9sZXNhbGVpbnRlcm5ldC5jb20Bd2FycmVuQHdob2xlc2FsZWludGVybmV0LmNvbQAAHgApDgEA
> AABDAAAAMDAwMDAwMGEBd2FycmVuQHdob2xlc2FsZWludGVybmV0LmNvbQF3YXJyZW5Ad2hvbGVz
> YWxlaW50ZXJuZXQuY29tAAADAN4/n04AAAMA8T8JBAAAAwAJWQEAAAADABCAAyAGAAAAAADAAAAA
> AAAARgAAAAABgQAAAAAAAAUAEYADIAYAAAAAAMAAAAAAAABGAAAAAAKBAAAAAAAAAAAAAAMAEoAD
> IAYAAAAAAMAAAAAAAABGAAAAABOBAAABAAAACwAUgAMgBgAAAAAAwAAAAAAAAEYAAAAAHIEAAAAA
> AAALAB2ACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAHoAIIAYAAAAAAMAAAAAAAABGAAAA
> ABCFAAAAAAAAAwApgAMgBgAAAAAAwAAAAAAAAEYAAAAAI4EAAP///38DADuACCAGAAAAAADAAAAA
> AAAARgAAAAABhQAAAAAAAAsAT4AIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwBQgAggBgAA
> AAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALAFGACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAsA
> YIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAHgBhgAggBgAAAAAAwAAAAAAAAEYAAAAANIUA
> AAEAAAA5AAAATjtFTUFJTDowMDAwMDAwMEU0QjFBMjNDMTY4RUNCNDJBRDYyQURCMjY3MDZDRkY5
> NjIzRDI5MDAAAAAAAwCGgAMgBgAAAAAAwAAAAAAAAEYAAAAAEIEAAAAAAAADAIeAAyAGAAAAAADA
> AAAAAAAARgAAAAARgQAAAAAAAAsAjYADIAYAAAAAAMAAAAAAAABGAAAAACSBAAAAAAAACwCOgAMg
> BgAAAAAAwAAAAAAAAEYAAAAALIEAAAAAAAADAI+AAyAGAAAAAADAAAAAAAAARgAAAAApgQAAAAAA
> AAMAkIADIAYAAAAAAMAAAAAAAABGAAAAACqBAAAAAAAAHgCVgAMgBgAAAAAAwAAAAAAAAEYAAAAA
> J4EAAAEAAAABAAAAAAAAAAMAnIADIAYAAAAAAMAAAAAAAABGAAAAABKBAAABAAAAHgCggAMgBgAA
> AAAAwAAAAAAAAEYAAAAAIYEAAAEAAAABAAAAAAAAAAsAo4ADIAYAAAAAAMAAAAAAAABGAAAAAAOB
> AAAAAAAACwCkgAMgBgAAAAAAwAAAAAAAAEYAAAAAJoEAAAAAAAALAB8OAQAAAAIB+A8BAAAAEAAA
> AHG3EuVr33pEkGydUqi4LoYCAfoPAQAAABAAAABxtxLla996RJBsnVKouC6GAwD+DwUAAAACAQkQ
> AQAAANgCAADUAgAABgQAAExaRnVjgZp1AwAKAHJjcGcxMjUiMgNDdGV4BUJiaf5kBAADMAEDAfcK
> gAKkA+T/BxMCgBBzAFAEVghVB7IRpScOUQMBAgBjaArAc2XcdDIGAAbDEaUzBEYUN94wEqwRswjv
> Cfc7GJ8OMHY1EaIMYGMAUAsJAWQzRjYW0AumIEkgAJBtIQtQeSB0aAuAayAuaQVAD1ELgHQFEGd1
> lQuAZx3xYQVAYSALYMByZ2UgZXYAcCAQhmwEAB+hbmQgcANgTnACIAnwBUBvZh5QcJR2Nh+wZCFQ
> dGkCILogGKBxHyAYoR+xZx8AqwBwIpBjH7BsGDBjH5D5IqEuIB1gBUABAARgAID/HuAfkAeRHgAg
> IAWgHbEOwL8eYB3gIdEl8gQBClAuCqLrCoQKgC0ock8e8QuAB0BzBdAHkHNhIBAocye0RnEDYTog
> SABwAwAjsSxvBdAKwCKQA6BbAMADEHQMbzoAwAAgeUBha+phK/EuJjFdCuMKgAZgFwIwKrAGEHQI
> cGRheVErUE5vdiUwYhMBMDY2K1AB0DEW0C/QOjRQOSBQTSe0VCxAII5XCsAYoAOgSm9oAIANAiA7
> H7AFEG4tcHCsbWwssDIxLiGAdC2FmHViagWQLhFSZSqw7lsyJy1gCFBtJGAgwCe6CTYPCk8DoDEx
> LzbiLy/RODo1FtAwYCtQQiIxLCIgPHcxM0Dcd2gG8AeQB0BlHsEEkWMUoC0iPiB3A2AOsDpjJ7o7
> oEFueSFxIDBs+RSQIG474A3gICAfczU15yOAO+A4ICBtAxAgoCKxsElQcz88hjyGaAJAoHA6Ly93
> QZAuIgHeNAEAJmEkgyYxLzZvQ6vOWQeQJMA9AGQ/MFAmcO81cCAgLzAgMHgLUA3gHmG/IPIBAAGQ
> AxAjQQaQID0g/nUhwAUxLDAg4QPgEwErsf8l8Se0IYAjsCKQLwAnqygVLE08Sh9MG31NUAMADTT9
> P6UGAwAPNP0/pQYCARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAw
> MDA3MUI3MTJFNTZCREY3QTQ0OTA2QzlENTJBOEI4MkU4NkU0NDVFMjAwAAAAAAMABhArkZ+ZAwAH
> EPQBAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASVNJTVBMWVRISU5LSVRJU0lOVFJJR1VJ
> TkdUSEFUQUxBUkdFRVZBTkdFTElTVEFORFBST1BPTkVOVE9GSVBWNkFET1BUSU9OUkVRVUlSRURB
> R0lHQU5USUNBTExPQ0FUSU9OSQAAAAB70g==
> 
> ------=_NextPart_000_2061_01CB7F5F.1A1E86E0
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> 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.
> ------=_NextPart_000_2061_01CB7F5F.1A1E86E0--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From marty at akamai.com  Mon Nov  8 18:36:51 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 8 Nov 2010 18:36:51 -0500
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <4CD55B73.9030104@arin.net>
Message-ID: <C8FDF3C3.16B1D%marty@akamai.com>




On 11/6/10 9:43 AM, "ARIN" <info at arin.net> wrote:

> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
> 
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
> 
> The AC invites everyone to comment on the 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.
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal 120: Protecting Number Resources
> 
> Proposal Originator: Leo Bicknell
> 
> Proposal Version: 1.0
> 
> Date: 5 November 2010
> 
> Proposal type: new
> 
> Policy term: permanent
> 
> Policy statement:
> 
> ARIN shall use any reasonable and practical methods to proactively
> look for fraudulently obtained or abandoned number resources and
> seek the return of those resources to ARIN.
> 


I like this. It's simple and straight forward policy writin'.

I'd like to suggest even greater simplification. Split this into two chunks,
one for dealing with resources that are abandoned, not all are being
utilized fraudulently but this would cover "all" abandonment, and one for
dealing with resources that are fraudulently obtained. Two very different
states IMHO. 

I can't determine which one will be "easier" to get consensus on, but I
suspect it will be a proposal related to abandoned resources even though
that one is probably more fraught with legal issues.


> A report of activities under this policy shall be delivered at each
> ARIN meeting.

You might consider adding/adjusting this to something like "A report of
activities clearly demonstrating success, failure and costs under this
policy". I'd really like to be able to gauge the return of each activity so
we can figure out when we need to what's broken and if it could be fixed.


Best,

-M<



> 
> Rationale:
> 
> ARIN has generally only reactively looked for fraudulently obtained
> or abandoned number resources, generally via reports to
> https://www.arin.net/resources/fraud/.
> 
> While it is great for ARIN to take these community reports, ARIN
> can be in a far better position to know which resources were
> fraudulently obtained or abandoned due to the additional paperwork
> that ARIN holds which is not available to the public, and the record
> of interactions (or lack thereof) with the resource holder.
> 
> ] From: John Curran <jcurran at arin.net>
> ] To: Leo Bicknell <bicknell at ufp.org>
> ] CC: "arin-ppml at arin.net" <arin-ppml at arin.net>
> ] Subject: Re: [arin-ppml] Audits
> ]
> ] On Nov 5, 2010, at 2:19 PM, Leo Bicknell wrote:
> ] >  What would the community have to get the ARIN staff to go proactively
> ] >  looking for fraud, abuse, defunct companies and other non-compliant
> ] >  uses of the address space?
> ]
> ] As usual: have the community develop an appropriate policy and ensure that
> ] there is an adequate level of support for the increased ARIN costs (which
> ] will appear back as overall service fees) once we get to implementation.
> ]
> ] /John
> 
> I expect the board/executive management will interpret reasonable
> and practical to be some amount of staff time that is not zero, but
> will also not "break the bank".
> 
> I also expect that ARIN will report on the number resources (in the
> aggregate) that were returned due to this proactive activity, as
> well as the cost to the members of this activity (again, in the
> aggregate) so as to obtain feedback if more, or less resources
> should be used in this area.
> 
> 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 rfg at tristatelogic.com  Mon Nov  8 21:26:05 2010
From: rfg at tristatelogic.com (Ronald F. Guilmette)
Date: Mon, 08 Nov 2010 18:26:05 -0800
Subject: [arin-ppml] Comcast
In-Reply-To: <206001cb7f91$64b8f6e0$2e2ae4a0$@com> 
Message-ID: <47240.1289269565@tristatelogic.com>


In message <206001cb7f91$64b8f6e0$2e2ae4a0$@com>, 
"Warren Johnson" <warren at wholesaleinternet.com> wrote:

>I simply think it is intriguing that a large evangelist and proponent of
>ipv6 adoption required a gigantic allocation.  It demonstrates the
>complexity of the issue.


Just curious... Who is the official keeper of the IPv4 doomsday clock,
and how much closer to midnite does this allocation put us?

(I see a couple of things out there that look sort-of like IPv4 doomsday
counter-downers, but nothing that's really clock-looking.  I'd like to
see a real clock someplace, with hands.  I guess that if one takes the
whole of the IPv4 space as being 12 hours, then I guess that we are
already well past 11 PM, yes?)


From owen at delong.com  Mon Nov  8 22:01:57 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 8 Nov 2010 19:01:57 -0800
Subject: [arin-ppml] Comcast
In-Reply-To: <47240.1289269565@tristatelogic.com>
References: <47240.1289269565@tristatelogic.com>
Message-ID: <6D10D958-D4F6-4CBD-9CB4-0D564374268E@delong.com>

None of this is official, but, it is baed on my observations of the various
projections and the industry trends.

The closest thing I've seen to a clock is:
		http://ipv6.he.net/statistics/

This sort of has hands and is a liberal artistic license inspired by
the corpus clock (http://www.youtube.com/watch?v=cCqGtvTA36k).


On Nov 8, 2010, at 6:26 PM, Ronald F. Guilmette wrote:

> 
> In message <206001cb7f91$64b8f6e0$2e2ae4a0$@com>, 
> "Warren Johnson" <warren at wholesaleinternet.com> wrote:
> 
>> I simply think it is intriguing that a large evangelist and proponent of
>> ipv6 adoption required a gigantic allocation.  It demonstrates the
>> complexity of the issue.
> 
> 
> Just curious... Who is the official keeper of the IPv4 doomsday clock,
> and how much closer to midnite does this allocation put us?
> 
> (I see a couple of things out there that look sort-of like IPv4 doomsday
> counter-downers, but nothing that's really clock-looking.  I'd like to
> see a real clock someplace, with hands.  I guess that if one takes the
> whole of the IPv4 space as being 12 hours, then I guess that we are
> already well past 11 PM, yes?)

Way way way past... Depending on which definition of doomsday
you want to use...

Definition 1: The day IANA issues the last 5 /8s to the RIRs

	By that definition, it is approximately 11:58

Definition 2: The day the first RIR approves but cannot satisfy
	a request for IPv4 addresses due to lack of available addresses
	in RIR inventory with no ability to gain more from IANA.

	By that definition, it is approximately 11:54

Definition 3: The day the first RIR can no longer provide even
	a minimum allocation (APNIC = /24, ARIN = /24, AfriNIC = /24,
		RIPE = /32, LACNIC I'm not sure).

	By that definition, it is approximately 11:45

Definition 4: The day the first RIR can't satisfy a median-sized (for that RIR)
	request.

	By this definition, it is approximately 11:50

Definition 5: The day NO RIR can satisfy a median-sized (for that RIR)
	request.

	By this definition, it is approximately 11:35

Definition 6: The day NO RIR can satisfy any request for IPv4 space.

	By this definition, it is approximately 11:20

Owen



From tedm at ipinc.net  Mon Nov  8 22:52:34 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 08 Nov 2010 19:52:34 -0800
Subject: [arin-ppml] Comcast
In-Reply-To: <47240.1289269565@tristatelogic.com>
References: <47240.1289269565@tristatelogic.com>
Message-ID: <4CD8C582.9070002@ipinc.net>

On 11/8/2010 6:26 PM, Ronald F. Guilmette wrote:
>
> In message<206001cb7f91$64b8f6e0$2e2ae4a0$@com>,
> "Warren Johnson"<warren at wholesaleinternet.com>  wrote:
>
>> I simply think it is intriguing that a large evangelist and proponent of
>> ipv6 adoption required a gigantic allocation.  It demonstrates the
>> complexity of the issue.
>
>
> Just curious... Who is the official keeper of the IPv4 doomsday clock,
> and how much closer to midnite does this allocation put us?
>

That's a catch-22.  You cannot runout of IPv4 unless you get the 
Internet very popular but it's the popularity of the Internet that 
forces you to runout of IPv4.

I frankly am much more interested in what the percentage of that 8
million IPs is free Legacy space and what percentage are they paying
ARIN for?

Ted


From heather.skanks at gmail.com  Mon Nov  8 23:19:35 2010
From: heather.skanks at gmail.com (Heather Schiller)
Date: Mon, 8 Nov 2010 23:19:35 -0500
Subject: [arin-ppml] Comcast
In-Reply-To: <4CD8C582.9070002@ipinc.net>
References: <47240.1289269565@tristatelogic.com> <4CD8C582.9070002@ipinc.net>
Message-ID: <AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>

On Mon, Nov 8, 2010 at 10:52 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> On 11/8/2010 6:26 PM, Ronald F. Guilmette wrote:
>>
>> In message<206001cb7f91$64b8f6e0$2e2ae4a0$@com>,
>> "Warren Johnson"<warren at wholesaleinternet.com> ?wrote:
>>
>>> I simply think it is intriguing that a large evangelist and proponent of
>>> ipv6 adoption required a gigantic allocation. ?It demonstrates the
>>> complexity of the issue.
>>
>>
>> Just curious... Who is the official keeper of the IPv4 doomsday clock,
>> and how much closer to midnite does this allocation put us?
>>
>
> That's a catch-22. ?You cannot runout of IPv4 unless you get the Internet
> very popular but it's the popularity of the Internet that forces you to
> runout of IPv4.
>
> I frankly am much more interested in what the percentage of that 8
> million IPs is free Legacy space and what percentage are they paying
> ARIN for?
>

 Huh?  They got the /9 on 10/21/2010 - which means none of it is
legacy and they are paying for all of it.  ...they were probably
already billing as an XL ($18k/yr) so it isn't costing them anything
extra.

No magic here.. anyone can look at the allocation, allocation dates
and the resources held under an org id:

The allocation:
http://whois.arin.net/rest/org/CCCH-3.html

Resources held under that org-id (including a /13, which would have
put them into the XL category prior to the /9 being allocated)
http://whois.arin.net/rest/org/CCCH-3/nets



> 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 tedm at ipinc.net  Mon Nov  8 23:49:27 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 08 Nov 2010 20:49:27 -0800
Subject: [arin-ppml] Comcast
In-Reply-To: <AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
References: <47240.1289269565@tristatelogic.com>	<4CD8C582.9070002@ipinc.net>
	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
Message-ID: <4CD8D2D7.6020008@ipinc.net>

On 11/8/2010 8:19 PM, Heather Schiller wrote:
> On Mon, Nov 8, 2010 at 10:52 PM, Ted Mittelstaedt<tedm at ipinc.net>  wrote:
>> On 11/8/2010 6:26 PM, Ronald F. Guilmette wrote:
>>>
>>> In message<206001cb7f91$64b8f6e0$2e2ae4a0$@com>,
>>> "Warren Johnson"<warren at wholesaleinternet.com>    wrote:
>>>
>>>> I simply think it is intriguing that a large evangelist and proponent of
>>>> ipv6 adoption required a gigantic allocation.  It demonstrates the
>>>> complexity of the issue.
>>>
>>>
>>> Just curious... Who is the official keeper of the IPv4 doomsday clock,
>>> and how much closer to midnite does this allocation put us?
>>>
>>
>> That's a catch-22.  You cannot runout of IPv4 unless you get the Internet
>> very popular but it's the popularity of the Internet that forces you to
>> runout of IPv4.
>>
>> I frankly am much more interested in what the percentage of that 8
>> million IPs is free Legacy space and what percentage are they paying
>> ARIN for?
>>
>
>   Huh?  They got the /9 on 10/21/2010 - which means none of it is
> legacy and they are paying for all of it.  ...they were probably
> already billing as an XL ($18k/yr) so it isn't costing them anything
> extra.
>
> No magic here.. anyone can look at the allocation, allocation dates
> and the resources held under an org id:
>
> The allocation:
> http://whois.arin.net/rest/org/CCCH-3.html
>
> Resources held under that org-id (including a /13, which would have
> put them into the XL category prior to the /9 being allocated)
> http://whois.arin.net/rest/org/CCCH-3/nets
>

Interesting, I didn't realize that they had all of their allocation
under a single /9

Obviously Comcast would have never qualified for a /9 when they were
first getting started.  So they must have renumbered dozens of times
as they got larger and worked their way up in size, qualifying for
larger and larger allocations.

It must have been holy hell on their customers to have to go through
all that renumbering, though.

Ted

>
>
>> 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 Wesley.E.George at sprint.com  Tue Nov  9 00:25:53 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Tue, 9 Nov 2010 05:25:53 +0000
Subject: [arin-ppml] Comcast
In-Reply-To: <4CD8D2D7.6020008@ipinc.net>
References: <47240.1289269565@tristatelogic.com> <4CD8C582.9070002@ipinc.net>
	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
	<4CD8D2D7.6020008@ipinc.net>
Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E021DAE@PLSWM12A.ad.sprint.com>

 
> On Mon, Nov 8, 2010 at 10:52 PM, Ted Mittelstaedt<tedm at ipinc.net>  wrote:

>> I frankly am much more interested in what the percentage of that 8 
>> million IPs is free Legacy space and what percentage are they paying 
>> ARIN for?
>>
[Wes] Taking your question a different way than you intended... Interop
handed back most of a legacy /8, Comcast got a /10. Though I doubt that it's
the same block, this is mostly a wash and I'm impressed at how much
angst/ire/discussion it's generating. As is usually the case with most
people's household finances, we had an unplanned windfall, which immediately
went back out the door for a legitimate use. Nothing to see here, move
along, we're still running out if IPv4 addresses...

>So they must have renumbered dozens of times as they got larger and worked
their way up in size, qualifying for >larger and larger allocations.

>It must have been holy hell on their customers to have to go through all
that renumbering, though.
[Wes] Uh, Comcast is majority residential DHCP customers. How is that hard
to renumber? Add new pool, expire lease, remove old pool. Done. I'd bet that
a large portion didn't even notice, and those who did chalked it up to the
fact that they are trying to run a host service on a dynamic IP, updated
their configs and moved on with their lives.
Yes, there are a nonzero number of static IP customers, but I'd argue that
most of those are not operating really big networks that would be hell to
renumber. Comcast business class service is a relatively recent occurrence.

Wes George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6793 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/aef9b90e/attachment.bin>

From Wesley.E.George at sprint.com  Tue Nov  9 03:31:15 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Tue, 9 Nov 2010 08:31:15 +0000
Subject: [arin-ppml] Comcast
In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E021DAE@PLSWM12A.ad.sprint.com>
References: <47240.1289269565@tristatelogic.com> <4CD8C582.9070002@ipinc.net>
	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
	<4CD8D2D7.6020008@ipinc.net>
	<54E900DC635DAB4DB7A6D799B3C4CD8E021DAE@PLSWM12A.ad.sprint.com>
Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E021FCC@PLSWM12A.ad.sprint.com>

 
[Wes] Taking your question a different way than you intended... Interop
handed back most of a legacy /8, Comcast got a /10. 

Fingers faster than brain. %s/10/9

Thanks Owen!


Wes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6793 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/6f46f376/attachment.bin>

From jcurran at arin.net  Tue Nov  9 08:24:31 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 9 Nov 2010 08:24:31 -0500
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <6ADA4C3D-8615-4F3E-8E0A-90A4F330274C@arin.net>
References: <46738.1288961816@tristatelogic.com>
	<F34108F3-1D71-4B46-8099-B8C000A6095A@arin.net>
	<4CD463CC.3090107@ipinc.net>
	<6ADA4C3D-8615-4F3E-8E0A-90A4F330274C@arin.net>
Message-ID: <9BD1345A-DA50-4AF9-A2FA-5942EA96D4D0@arin.net>

On Nov 5, 2010, at 4:23 PM, John Curran wrote:
> On Nov 5, 2010, at 4:06 PM, Ted Mittelstaedt wrote:
>> 
>> "...ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy...."
>> 
>> I would recommend that any "auditing" be concentrated on this list FIRST.
>> 
>> John, please provide the URL for this list and Ron can do his
>> auditing on that.
> 
> Ted - 
>   We're actively working on the automation to generate this list.  I'll provide an ETA shortly.
> /John

Ted -

This functionality is available within ARIN Online to those that have a signed Bulk WHOIS Acceptable Use Policy (AUP) on file with ARIN.
Through this feature, ARIN provides a list of resources with no valid Points of Contacts (POCs).  This report is available on the Downloads tab when logged in to ARIN Online.

/John

John Curran
President and CEO
ARIN



From heather.skanks at gmail.com  Tue Nov  9 08:56:25 2010
From: heather.skanks at gmail.com (Heather Schiller)
Date: Tue, 9 Nov 2010 08:56:25 -0500
Subject: [arin-ppml] Comcast
In-Reply-To: <4CD8D2D7.6020008@ipinc.net>
References: <47240.1289269565@tristatelogic.com> <4CD8C582.9070002@ipinc.net>
	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
	<4CD8D2D7.6020008@ipinc.net>
Message-ID: <AANLkTiktXm-cE674SiettUdaohjhq2yGja+UEkkik2EA@mail.gmail.com>

On Mon, Nov 8, 2010 at 11:49 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> On 11/8/2010 8:19 PM, Heather Schiller wrote:
>>
>> On Mon, Nov 8, 2010 at 10:52 PM, Ted Mittelstaedt<tedm at ipinc.net> ?wrote:
>>>
>>> On 11/8/2010 6:26 PM, Ronald F. Guilmette wrote:
>>>>
>>>> In message<206001cb7f91$64b8f6e0$2e2ae4a0$@com>,
>>>> "Warren Johnson"<warren at wholesaleinternet.com> ? ?wrote:
>>>>
>>>>> I simply think it is intriguing that a large evangelist and proponent
>>>>> of
>>>>> ipv6 adoption required a gigantic allocation. ?It demonstrates the
>>>>> complexity of the issue.
>>>>
>>>>
>>>> Just curious... Who is the official keeper of the IPv4 doomsday clock,
>>>> and how much closer to midnite does this allocation put us?
>>>>
>>>
>>> That's a catch-22. ?You cannot runout of IPv4 unless you get the Internet
>>> very popular but it's the popularity of the Internet that forces you to
>>> runout of IPv4.
>>>
>>> I frankly am much more interested in what the percentage of that 8
>>> million IPs is free Legacy space and what percentage are they paying
>>> ARIN for?
>>>
>>
>> ?Huh? ?They got the /9 on 10/21/2010 - which means none of it is
>> legacy and they are paying for all of it. ?...they were probably
>> already billing as an XL ($18k/yr) so it isn't costing them anything
>> extra.
>>
>> No magic here.. anyone can look at the allocation, allocation dates
>> and the resources held under an org id:
>>
>> The allocation:
>> http://whois.arin.net/rest/org/CCCH-3.html
>>
>> Resources held under that org-id (including a /13, which would have
>> put them into the XL category prior to the /9 being allocated)
>> http://whois.arin.net/rest/org/CCCH-3/nets
>>
>
> Interesting, I didn't realize that they had all of their allocation
> under a single /9
>

/sigh

 They don't have *all of their allocation under a single /9*

Really.. just click the link (I promise it's SFW, no dancing bears, no
exploding malware) http://whois.arin.net/rest/org/CCCH-3/nets    It
takes you to ARIN's website and shows you a listing of everything
under that Comcast account.  Which includes the /9, *and* a bunch of
other space.  They probably don't even have all their allocations
under a single org id... lots of companies don't.

PPML is for discussion of policy proposals, not for conjecture or fud
about allocations ARIN has made.


> Obviously Comcast would have never qualified for a /9 when they were
> first getting started. ?So they must have renumbered dozens of times
> as they got larger and worked their way up in size, qualifying for
> larger and larger allocations.
>
> It must have been holy hell on their customers to have to go through
> all that renumbering, though.
>
> Ted
>
>>
>>
>>> 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 bicknell at ufp.org  Tue Nov  9 09:01:19 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Nov 2010 06:01:19 -0800
Subject: [arin-ppml] Comcast
In-Reply-To: <4CD8D2D7.6020008@ipinc.net>
References: <47240.1289269565@tristatelogic.com> <4CD8C582.9070002@ipinc.net>
	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
	<4CD8D2D7.6020008@ipinc.net>
Message-ID: <20101109140119.GA24194@ussenterprise.ufp.org>

In a message written on Mon, Nov 08, 2010 at 08:49:27PM -0800, Ted Mittelstaedt wrote:
> Interesting, I didn't realize that they had all of their allocation
> under a single /9

They have more than one OrgID.  Lots of the largest folks do, usually
the result of various mergers or operating companies.

They have several dozen blocks across a half dozen OrgID's, one of
them is a /8, 73/8, which was obtained from ARIN.  Interestingly
it wasn't obtained all at once, when ARIN issued it they got a /10
and /9, IIRC, then later qualified for the other /10 to make it a
whole /8.

All together I would not be surprised that they had 3-4 /8's worth
of space if you added up all of their blocks.  If you believe
http://en.wikipedia.org/wiki/Comcast they have around 16 million
high speed internet residential users.  They do have other services
that eat IP's, for instance business users (not business cable,
actual GigE over fiber business users) who get larger blocks, and
some of their video and voice services also use IP's.

At a quick glance I don't see any significant blocks of legacy
space, I think they have gotten almost all of their space under
various ARIN policies.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/6150c292/attachment.sig>

From mueller at syr.edu  Tue Nov  9 09:42:35 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 9 Nov 2010 09:42:35 -0500
Subject: [arin-ppml] Comcast
In-Reply-To: <AANLkTiktXm-cE674SiettUdaohjhq2yGja+UEkkik2EA@mail.gmail.com>
References: <47240.1289269565@tristatelogic.com> <4CD8C582.9070002@ipinc.net>
	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
	<4CD8D2D7.6020008@ipinc.net>
	<AANLkTiktXm-cE674SiettUdaohjhq2yGja+UEkkik2EA@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC108D89E@SUEX07-MBX-04.ad.syr.edu>

I don't understand these attempt to discourage discussion. Since policy guides allocations and we can only assess policy through its impact on allocations why would anyone say that the implications of specific large-scale allocations cannot be discussed?

If you think specific comments are conjectural, wrong or FUD make your case. But don't try to exempt ARIN from an open discussion of what it does. 

> -----Original Message-----
> 
> PPML is for discussion of policy proposals, not for conjecture or fud
> about allocations ARIN has made.
> 

From mueller at syr.edu  Tue Nov  9 09:44:27 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 9 Nov 2010 09:44:27 -0500
Subject: [arin-ppml] Comcast
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC108D89E@SUEX07-MBX-04.ad.syr.edu>
References: <47240.1289269565@tristatelogic.com> <4CD8C582.9070002@ipinc.net>
	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
	<4CD8D2D7.6020008@ipinc.net>
	<AANLkTiktXm-cE674SiettUdaohjhq2yGja+UEkkik2EA@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D70AC108D89E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D70AC108D8A0@SUEX07-MBX-04.ad.syr.edu>

But I will grant you, Heather, that Ted's speculation that part of the /9 might be "free legacy space" seems way off base, given that they got it from ARIN.

> -----Original Message-----
> 
> I don't understand these attempt to discourage discussion. Since policy
> guides allocations and we can only assess policy through its impact on
> allocations why would anyone say that the implications of specific
> large-scale allocations cannot be discussed?
> 
> If you think specific comments are conjectural, wrong or FUD make your
> case. But don't try to exempt ARIN from an open discussion of what it
> does.
> 
> > -----Original Message-----
> >
> > PPML is for discussion of policy proposals, not for conjecture or fud
> > about allocations ARIN has made.
> >
> _______________________________________________
> 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 Nov  9 09:48:35 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 9 Nov 2010 07:48:35 -0700
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <C8FDF3C3.16B1D%marty@akamai.com>
References: <4CD55B73.9030104@arin.net>
	<C8FDF3C3.16B1D%marty@akamai.com>
Message-ID: <AANLkTi=ayyr_vEEH1vj+XO4yUv4UxOhRuc4XDa15QLGF@mail.gmail.com>

On Mon, Nov 8, 2010 at 16:36, Hannigan, Martin <marty at akamai.com> wrote:
>
> I like this. It's simple and straight forward policy writin'.
>
> I'd like to suggest even greater simplification. Split this into two chunks,
> one for dealing with resources that are abandoned, not all are being
> utilized fraudulently but this would cover "all" abandonment, and one for
> dealing with resources that are fraudulently obtained. Two very different
> states IMHO.

I agree but I think the policy mechanisms necessary for ARIN to go
after fraud are already in place. What is likely needed in that area
is a suggestion (through the official suggestion process) to actively
seek fraud using those mechanisms.

That leaves the abandonment issue, which I agree needs some policy.

~Chris

> I can't determine which one will be "easier" to get consensus on, but I
> suspect it will be a proposal related to abandoned resources even though
> that one is probably more fraught with legal issues.
>
> On 11/6/10 9:43 AM, "ARIN" <info at arin.net> wrote:
>> A report of activities under this policy shall be delivered at each
>> ARIN meeting.
>
> You might consider adding/adjusting this to something like "A report of
> activities clearly demonstrating success, failure and costs under this
> policy". I'd really like to be able to gauge the return of each activity so
> we can figure out when we need to what's broken and if it could be fixed.
>
>
> Best,
>
> -M<
>
> _______________________________________________
> 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.
>




-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From Wesley.E.George at sprint.com  Tue Nov  9 09:55:25 2010
From: Wesley.E.George at sprint.com (George, Wes E IV [NTK])
Date: Tue, 9 Nov 2010 14:55:25 +0000
Subject: [arin-ppml] Comcast
In-Reply-To: <75822E125BCB994F8446858C4B19F0D70AC108D89E@SUEX07-MBX-04.ad.syr.edu>
References: <47240.1289269565@tristatelogic.com> <4CD8C582.9070002@ipinc.net>
	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
	<4CD8D2D7.6020008@ipinc.net>
	<AANLkTiktXm-cE674SiettUdaohjhq2yGja+UEkkik2EA@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D70AC108D89E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E0223DD@PLSWM12A.ad.sprint.com>

 
-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Milton L Mueller
Sent: Tuesday, November 09, 2010 10:43 PM
To: Heather Schiller; Ted Mittelstaedt
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Comcast

	I don't understand these attempt to discourage discussion. Since
policy guides allocations and we can only 	assess policy through its
impact on allocations why would anyone say that the implications of specific
large-scale allocations cannot be discussed?

	If you think specific comments are conjectural, wrong or FUD make
your case. But don't try to exempt ARIN 	from an open discussion of
what it does. 


No one is trying to exempt ARIN from anything. There is a list for
[off-topic] discussion. It's conveniently labeled arin-discuss for a reason.
Please use it for its intended purpose. 
PPML is for discussing draft and potential policies, and as far as I can
tell, none of the discussion and conjecture around what ARIN and Comcast
have done or not done has been tied even tenuously to any current or
proposed policy currently up for discussion. If I'm wrong, let's bring the
discussion back to that instead of acting like we're trying to censor
discussion when someone points out that this is off-topic.

Wes George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6793 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/318f0a43/attachment.bin>

From lear at cisco.com  Tue Nov  9 09:55:43 2010
From: lear at cisco.com (Eliot Lear)
Date: Tue, 09 Nov 2010 15:55:43 +0100
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <4CD55B73.9030104@arin.net>
References: <4CD55B73.9030104@arin.net>
Message-ID: <4CD960EF.2010202@cisco.com>

I would very much like to understand the meaning of the term "abandoned"
in this context.  Does it mean, for instance, that the address space is
not routed or that there is no NPRM signed to cover that space?

thanks,

Eliot

On 11/6/10 2:43 PM, ARIN wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
>
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
>
> The AC invites everyone to comment on the 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.
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal 120: Protecting Number Resources
>
> Proposal Originator: Leo Bicknell
>
> Proposal Version: 1.0
>
> Date: 5 November 2010
>
> Proposal type: new
>
> Policy term: permanent
>
> Policy statement:
>
> ARIN shall use any reasonable and practical methods to proactively
> look for fraudulently obtained or abandoned number resources and
> seek the return of those resources to ARIN.
>
> A report of activities under this policy shall be delivered at each
> ARIN meeting.
>
> Rationale:
>
> ARIN has generally only reactively looked for fraudulently obtained
> or abandoned number resources, generally via reports to
> https://www.arin.net/resources/fraud/.
>
> While it is great for ARIN to take these community reports, ARIN
> can be in a far better position to know which resources were
> fraudulently obtained or abandoned due to the additional paperwork
> that ARIN holds which is not available to the public, and the record
> of interactions (or lack thereof) with the resource holder.
>
> ] From: John Curran <jcurran at arin.net>
> ] To: Leo Bicknell <bicknell at ufp.org>
> ] CC: "arin-ppml at arin.net" <arin-ppml at arin.net>
> ] Subject: Re: [arin-ppml] Audits
> ]
> ] On Nov 5, 2010, at 2:19 PM, Leo Bicknell wrote:
> ] >  What would the community have to get the ARIN staff to go
> proactively
> ] >  looking for fraud, abuse, defunct companies and other non-compliant
> ] >  uses of the address space?
> ]
> ] As usual: have the community develop an appropriate policy and
> ensure that
> ] there is an adequate level of support for the increased ARIN costs
> (which
> ] will appear back as overall service fees) once we get to
> implementation.
> ]
> ] /John
>
> I expect the board/executive management will interpret reasonable
> and practical to be some amount of staff time that is not zero, but
> will also not "break the bank".
>
> I also expect that ARIN will report on the number resources (in the
> aggregate) that were returned due to this proactive activity, as
> well as the cost to the members of this activity (again, in the
> aggregate) so as to obtain feedback if more, or less resources
> should be used in this area.
>
> 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 bicknell at ufp.org  Tue Nov  9 10:19:58 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Nov 2010 07:19:58 -0800
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <4CD960EF.2010202@cisco.com>
References: <4CD55B73.9030104@arin.net> <4CD960EF.2010202@cisco.com>
Message-ID: <20101109151958.GA30382@ussenterprise.ufp.org>

In a message written on Tue, Nov 09, 2010 at 03:55:43PM +0100, Eliot Lear wrote:
> I would very much like to understand the meaning of the term "abandoned"
> in this context.  Does it mean, for instance, that the address space is
> not routed or that there is no NPRM signed to cover that space?

Abandoned is intended to mean more or less what people would assume
it means; space where the resource holder is no longer using it for
any purpose.  It may or may not mean the original resource holder
still exists, however I suspect in the vast majority of these cases
we are talking about resources holders who do not exist any longer.

Examples:
  - A resource allocated to an individual, that person dies.
  - A resource allocated to a sole-propietor business that has
    simply closes.

Let me break that down a bit further.  If space was obtained from
ARIN it was done under an RSA and has a yearly fee attached.  If
the fee is no longer paid ARIN will reclaim the address space.  I
don't think there is a significant issue in this case, and don't
think the policy proposal affects it in any material way.

Now, if space was obtained before ARIN existed (legacy space) there
is no yearly fee.  It is my understanding from staff they will not
reclaim that space under any circumstances at this point in time.
This policy is aimed squarely at space in this situation.

A to target this space is that there are folks out there looking
for these abandoned blocks to use for nefarious purposes, for
instance spamming.  Since the original owner is gone/no longer
interested in them they can hijack and use them fairly easily right
now.  Another reason is with impeneding run-out, I think the community
should make a reasonable effort to insure there are no stranded
blocks in this condition.

I want to be quite clear that "not routed" is an interesting
identifier, but not required.  The low hanging fruit here is not
routed space, and I firmly expect ARIN would start with the easy
stuff.  Imagine a block obtained by an individual in 1993 for his
garage dial-up Internet business.  However before he could get the
modem banks up and running he was hit by a bus.  The space has never
been routed.  There is no more resouce holder, let's get it back
in the free pool and move on.

From there let's construct a more interesting example, we can imagine
that the same space went unrouted until 2005, when a spammer hijacked
it and started spamming from it, which they have been doing ever
since.  The space _is_ routed.  It is also to my mind abandoned by
the original owner, and being used frauduently.  This is why I
included both fraud and abandoned in the policy, I can see folks
might call this space either, or both as I do.  Any way you slice
it though the space should be reclaimed (no longer marked as being
allocated to the original owner) and returned to the free pool.
It's my understanding ARIN would reclaim this as fraud if reported
to them via the web page, just right now staff will spend no time
proactively looking for such things.

Lastly, this policy is not intended to address the problem of space
transferred outside the ARIN process.  If in the previous paragraph
the owner said the space was sold to the spammer in 2005 that's not
abandoned.  ARIN may want to look into that situation using other
policies and tools, but I don't want to wade into that mess with
this policy.  Abandoned here means the original owner does not
exist, or no longer neeeds/uses the space 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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/46954661/attachment.sig>

From bicknell at ufp.org  Tue Nov  9 10:50:01 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Nov 2010 07:50:01 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal 120:
	Protecting Number Resources
In-Reply-To: <4CD55B73.9030104@arin.net>
References: <4CD55B73.9030104@arin.net>
Message-ID: <20101109155001.GA34127@ussenterprise.ufp.org>


I have a request for some data from ARIN staff I think would help
people evaluate this policy.

Can ARIN tell ppml how many IPv4 number resources were reclaimed/revoked
last year (last 12 months, calendar 2009, whatever is handy) for
non-payment?

My thinking is non-payment largely indicates abandoned resources
allocated under RSA.  Since ARIN actually has the non-payment hook
under the RSA, it can give us a glimpse into the order of magnitude
of the problem.  If they had been legacy resources not under any
RSA they would likely have ended up the abandoned resources I wish
to target with this policy.

It's not a perfect estimation of the size of the problem in legacy
space, but it's the only thing I can think of that even gives us a
rough estimation.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/b93e3f8c/attachment.sig>

From lear at cisco.com  Tue Nov  9 10:57:34 2010
From: lear at cisco.com (Eliot Lear)
Date: Tue, 09 Nov 2010 16:57:34 +0100
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <20101109151958.GA30382@ussenterprise.ufp.org>
References: <4CD55B73.9030104@arin.net> <4CD960EF.2010202@cisco.com>
	<20101109151958.GA30382@ussenterprise.ufp.org>
Message-ID: <4CD96F6E.2050306@cisco.com>

Leo,

Thank you for your explanation. It seems as though you would like to
start with low hanging fruit where "abandoned" would mean:

   1. the address space is not routed; and
   2. one of the following circumstances applies:
         1. administrative (or technical?) contact disavows use of the space
         2. no contacts can be found either by email, by phone, or by post.

This is the sort of specificity that would provide good direction to
staff, scope the work, and provide the community some visibility as to
the cost of the effort.

I write "start" above because I could see this sort of policy evolving
over time.

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

From jcurran at arin.net  Tue Nov  9 11:11:25 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 9 Nov 2010 11:11:25 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <20101109155001.GA34127@ussenterprise.ufp.org>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
Message-ID: <95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>

On Nov 9, 2010, at 10:50 AM, Leo Bicknell wrote:
> 
> I have a request for some data from ARIN staff I think would help
> people evaluate this policy.
> 
> Can ARIN tell ppml how many IPv4 number resources were reclaimed/revoked
> last year (last 12 months, calendar 2009, whatever is handy) for
> non-payment?

A summary is presented at each ARIN meeting during the Registration
Services report: https://www.arin.net/participate/meetings/reports/ARIN_XXVI/PDF/Friday/nobile_rsd_update.pdf
(slide 4)  This is a total cumulative slide and reflects space in
/16 equivalents; we can work on getting a more granular breakdown 
if that would be useful.  This has lines for returned, revoked (for
non-payment), and reclaimed (generally due to fraud).

> My thinking is non-payment largely indicates abandoned resources
> allocated under RSA.  Since ARIN actually has the non-payment hook
> under the RSA, it can give us a glimpse into the order of magnitude
> of the problem.  If they had been legacy resources not under any
> RSA they would likely have ended up the abandoned resources I wish
> to target with this policy.

Non-payment of resources under RSA results in revocation.

> It's not a perfect estimation of the size of the problem in legacy
> space, but it's the only thing I can think of that even gives us a
> rough estimation.

I'm not sure how this information relates to "the problem in legacy 
space", but in any case if you need more details, please let me know.

/John

John Curran
President and CEO
ARIN





From stephen at sprunk.org  Tue Nov  9 11:13:40 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 09 Nov 2010 10:13:40 -0600
Subject: [arin-ppml] Comcast
In-Reply-To: <4CD8D2D7.6020008@ipinc.net>
References: <47240.1289269565@tristatelogic.com>	<4CD8C582.9070002@ipinc.net>	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>
	<4CD8D2D7.6020008@ipinc.net>
Message-ID: <4CD97334.8070300@sprunk.org>

On 08 Nov 2010 22:49, Ted Mittelstaedt wrote:
> Obviously Comcast would have never qualified for a /9 when they were 
> first getting started.  So they must have renumbered dozens of times
> as they got larger and worked their way up in size, qualifying for
> larger and larger allocations.
>
> It must have been holy hell on their customers to have to go through
> all that renumbering, though.

There is no policy that _requires_ an org to return smaller
allocations/assignments when they qualify for a larger one.  As you
note, that would cause a lot of renumbering as the org grows.  Policy
_allows_ orgs to exchange multiple smaller blocks for a single larger
one, but I suspect that's fairly rare.

This is the primary reason why the prefix:AS ratio is so high with
IPv4.  That is also the reason why the goal is to give ridiculously
large IPv6 blocks: to keep the prefix:AS ratio as low as possible.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/9c0c00b0/attachment.p7s>

From cgrundemann at gmail.com  Tue Nov  9 12:23:54 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 9 Nov 2010 10:23:54 -0700
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
Message-ID: <AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>

On Tue, Nov 9, 2010 at 09:11, John Curran <jcurran at arin.net> wrote:
>
> A summary is presented at each ARIN meeting during the Registration
> Services report: https://www.arin.net/participate/meetings/reports/ARIN_XXVI/PDF/Friday/nobile_rsd_update.pdf
> (slide 4) ?This is a total cumulative slide and reflects space in
> /16 equivalents; we can work on getting a more granular breakdown
> if that would be useful. ?This has lines for returned, revoked (for
> non-payment), and reclaimed (generally due to fraud).

A great start - seeing this broken down per-year would be helpful I
think. Something similar to the requests received and issued graphs
but with returns, reclamations and revocations.

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


-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From owen at delong.com  Tue Nov  9 12:45:34 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Nov 2010 09:45:34 -0800
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <4CD960EF.2010202@cisco.com>
References: <4CD55B73.9030104@arin.net> <4CD960EF.2010202@cisco.com>
Message-ID: <01C0C46D-CDED-404B-B428-36F431E46E26@delong.com>

My understanding is that it means space allocated to an organization
which no longer exists.

This would hold true regardless of RSA status (which is what I think you
meant rather than NPRM).

Owen

On Nov 9, 2010, at 6:55 AM, Eliot Lear wrote:

> I would very much like to understand the meaning of the term "abandoned"
> in this context.  Does it mean, for instance, that the address space is
> not routed or that there is no NPRM signed to cover that space?
> 
> thanks,
> 
> Eliot
> 
> On 11/6/10 2:43 PM, ARIN wrote:
>> ARIN received the following policy proposal and is posting it to the
>> Public Policy Mailing List (PPML) in accordance with the Policy
>> Development Process.
>> 
>> The ARIN Advisory Council (AC) will review the proposal at their next
>> regularly scheduled meeting (if the period before the next regularly
>> scheduled meeting is less than 10 days, then the period may be extended
>> to the subsequent regularly scheduled meeting). The AC will decide how
>> to utilize the proposal and announce the decision to the PPML.
>> 
>> The AC invites everyone to comment on the 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.
>> 
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>> 
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>> 
>> Mailing list subscription information can be found
>> at: https://www.arin.net/mailing_lists/
>> 
>> Regards,
>> 
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> ## * ##
>> 
>> 
>> Policy Proposal 120: Protecting Number Resources
>> 
>> Proposal Originator: Leo Bicknell
>> 
>> Proposal Version: 1.0
>> 
>> Date: 5 November 2010
>> 
>> Proposal type: new
>> 
>> Policy term: permanent
>> 
>> Policy statement:
>> 
>> ARIN shall use any reasonable and practical methods to proactively
>> look for fraudulently obtained or abandoned number resources and
>> seek the return of those resources to ARIN.
>> 
>> A report of activities under this policy shall be delivered at each
>> ARIN meeting.
>> 
>> Rationale:
>> 
>> ARIN has generally only reactively looked for fraudulently obtained
>> or abandoned number resources, generally via reports to
>> https://www.arin.net/resources/fraud/.
>> 
>> While it is great for ARIN to take these community reports, ARIN
>> can be in a far better position to know which resources were
>> fraudulently obtained or abandoned due to the additional paperwork
>> that ARIN holds which is not available to the public, and the record
>> of interactions (or lack thereof) with the resource holder.
>> 
>> ] From: John Curran <jcurran at arin.net>
>> ] To: Leo Bicknell <bicknell at ufp.org>
>> ] CC: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> ] Subject: Re: [arin-ppml] Audits
>> ]
>> ] On Nov 5, 2010, at 2:19 PM, Leo Bicknell wrote:
>> ] >  What would the community have to get the ARIN staff to go
>> proactively
>> ] >  looking for fraud, abuse, defunct companies and other non-compliant
>> ] >  uses of the address space?
>> ]
>> ] As usual: have the community develop an appropriate policy and
>> ensure that
>> ] there is an adequate level of support for the increased ARIN costs
>> (which
>> ] will appear back as overall service fees) once we get to
>> implementation.
>> ]
>> ] /John
>> 
>> I expect the board/executive management will interpret reasonable
>> and practical to be some amount of staff time that is not zero, but
>> will also not "break the bank".
>> 
>> I also expect that ARIN will report on the number resources (in the
>> aggregate) that were returned due to this proactive activity, as
>> well as the cost to the members of this activity (again, in the
>> aggregate) so as to obtain feedback if more, or less resources
>> should be used in this area.
>> 
>> 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.
>> 
> _______________________________________________
> 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 Nov  9 14:13:25 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Nov 2010 11:13:25 -0800
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <4CD96F6E.2050306@cisco.com>
References: <4CD55B73.9030104@arin.net> <4CD960EF.2010202@cisco.com>
	<20101109151958.GA30382@ussenterprise.ufp.org>
	<4CD96F6E.2050306@cisco.com>
Message-ID: <FF5DDC84-F924-44D8-929B-3D26BF2B45BC@delong.com>


On Nov 9, 2010, at 7:57 AM, Eliot Lear wrote:

> Leo,
> 
> Thank you for your explanation. It seems as though you would like to start with low hanging fruit where "abandoned" would mean:
> the address space is not routed; and 
> one of the following circumstances applies:
> administrative (or technical?) contact disavows use of the space
> no contacts can be found either by email, by phone, or by post.
2(b) is problematic IMHO. Just because we can't locate the contacts does not mean that
the organization is defunct or has stopped utilizing the resources.

Owen

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

From jcurran at arin.net  Tue Nov  9 14:50:30 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 9 Nov 2010 14:50:30 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
Message-ID: <24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>

On Nov 9, 2010, at 12:23 PM, Chris Grundemann wrote:
> On Tue, Nov 9, 2010 at 09:11, John Curran <jcurran at arin.net> wrote:
>> 
>> A summary is presented at each ARIN meeting during the Registration
>> Services report: https://www.arin.net/participate/meetings/reports/ARIN_XXVI/PDF/Friday/nobile_rsd_update.pdf
>> (slide 4)  This is a total cumulative slide and reflects space in
>> /16 equivalents; we can work on getting a more granular breakdown
>> if that would be useful.  This has lines for returned, revoked (for
>> non-payment), and reclaimed (generally due to fraud).
> 
> A great start - seeing this broken down per-year would be helpful I
> think. Something similar to the requests received and issued graphs
> but with returns, reclamations and revocations.

Will do the full table by year for future reports.  In the meantime, 
here's the breakdown of revoked space annually for your use:

2004:  29.00 /16s
2005:  14.61 /16s
2006:  14.01 /16s
2007:  30.50 /16s
2008:   8.45 /16s
2009:   8.37 /16s
2010*:  5.84 /16s   (*through Oct 31, 2010)

Total: 110.78 /16s

Best wishes,
/John

John Curran
President and CEO
ARIN





From owen at delong.com  Tue Nov  9 15:03:57 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Nov 2010 12:03:57 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
	120: Protecting Number Resources
In-Reply-To: <24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
Message-ID: <473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>

So in almost 7 years, we've reclaimed less than we gave Comcast last week.

Looks like a pretty small problem with minimal gain to me.

Owen

On Nov 9, 2010, at 11:50 AM, John Curran wrote:

> On Nov 9, 2010, at 12:23 PM, Chris Grundemann wrote:
>> On Tue, Nov 9, 2010 at 09:11, John Curran <jcurran at arin.net> wrote:
>>> 
>>> A summary is presented at each ARIN meeting during the Registration
>>> Services report: https://www.arin.net/participate/meetings/reports/ARIN_XXVI/PDF/Friday/nobile_rsd_update.pdf
>>> (slide 4)  This is a total cumulative slide and reflects space in
>>> /16 equivalents; we can work on getting a more granular breakdown
>>> if that would be useful.  This has lines for returned, revoked (for
>>> non-payment), and reclaimed (generally due to fraud).
>> 
>> A great start - seeing this broken down per-year would be helpful I
>> think. Something similar to the requests received and issued graphs
>> but with returns, reclamations and revocations.
> 
> Will do the full table by year for future reports.  In the meantime, 
> here's the breakdown of revoked space annually for your use:
> 
> 2004:  29.00 /16s
> 2005:  14.61 /16s
> 2006:  14.01 /16s
> 2007:  30.50 /16s
> 2008:   8.45 /16s
> 2009:   8.37 /16s
> 2010*:  5.84 /16s   (*through Oct 31, 2010)
> 
> Total: 110.78 /16s
> 
> Best wishes,
> /John
> 
> John Curran
> President and CEO
> 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 bill at herrin.us  Tue Nov  9 15:40:48 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 9 Nov 2010 15:40:48 -0500
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <FF5DDC84-F924-44D8-929B-3D26BF2B45BC@delong.com>
References: <4CD55B73.9030104@arin.net> <4CD960EF.2010202@cisco.com>
	<20101109151958.GA30382@ussenterprise.ufp.org>
	<4CD96F6E.2050306@cisco.com>
	<FF5DDC84-F924-44D8-929B-3D26BF2B45BC@delong.com>
Message-ID: <AANLkTinzUyemqfmVns8m_J421-RNtW_Qe7VcdMD2nukM@mail.gmail.com>

On Tue, Nov 9, 2010 at 2:13 PM, Owen DeLong <owen at delong.com> wrote:
> On Nov 9, 2010, at 7:57 AM, Eliot Lear wrote:
> Thank you for your explanation. It seems as though you would like to start with low hanging fruit where "abandoned" would mean:
>
> the address space is not routed; and
> one of the following circumstances applies:
>
> administrative (or technical?) contact disavows use of the space
> no contacts can be found either by email, by phone, or by post.
>
> 2(b) is problematic IMHO. Just because we can't locate the contacts does not mean that
> the organization is defunct or has stopped utilizing the resources.

There are probably some useful process formulas to be found in the
various state escheat laws. The typical process is different
everywhere you look but the commonalities appear to be about like
this: if a property goes unclaimed with no activity for a year, the
entity holding that property can seek to escheat. They make three
diligent attempts over 120 days to contact the owner. If no one
asserting ownership can be contacted, the property is turned over to
the state. The state sells, auctions or otherwise converts the
property to cash. It then holds the cash for five or ten years in
trust for the owner should he ever show up after which it goes in to
the state treasury.

None of this is directly applicable because "IP addresses aren't
property" (sic) and ARIN isn't a government agency.

Some key principles in the escheat process relevant to what we're
talking about are:

1. No activity for a year. So, no updates, no acknowledgements, no BGP
announcements that weren't confirmed to be fraud, etc. Maybe make this
a little longer since activity in the Internet sense tends to be
further apart than what happens offline.

2. Three diligent contact attempts over 120 days. Presumably also
means contacting the company in general if possible and trying to find
someone who knows something about the IP addresses.

3. Cash value. In this case, probably an offer to provide a comparable
number of first-available addresses under the same legacy terms if the
person shows up within five years.

Regards,
Bill Herrin


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


From marty at akamai.com  Tue Nov  9 15:48:59 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 9 Nov 2010 15:48:59 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
Message-ID: <C8FF1DEB.16CB3%marty@akamai.com>




On 11/9/10 3:03 PM, "Owen DeLong" <owen at delong.com> wrote:

> So in almost 7 years, we've reclaimed less than we gave Comcast last week.
> 
> Looks like a pretty small problem with minimal gain to me.
> 


Taking the largest and the smallest years and mapping back to a cost of $40
per address. 


> 2004:  29.00 /16s

7424 /24 = $76,021,760.00

> 2010*:  5.84 /16s

1495 /24 = $15,309,209.00

Looking at the rest of this list:

> 2004:  29.00 /16s
> 2005:  14.61 /16s
> 2006:  14.01 /16s
> 2007:  30.50 /16s
> 2008:   8.45 /16s
> 2009:   8.37 /16s
> 2010*:  5.84 /16s

Doesn't really say much other than 2008 seemed to decline and there's no
explanation why, at least one that is obvious.



Best,

-M<



From marty at akamai.com  Tue Nov  9 16:01:11 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 9 Nov 2010 16:01:11 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <C8FF1DEB.16CB3%marty@akamai.com>
Message-ID: <C8FF20C7.16CBD%marty@akamai.com>




On 11/9/10 3:48 PM, "Hannigan, Martin" <marty at akamai.com> wrote:

> 
> 
> 
> On 11/9/10 3:03 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> So in almost 7 years, we've reclaimed less than we gave Comcast last week.
>> 
>> Looks like a pretty small problem with minimal gain to me.
>> 
> 
> 
> Taking the largest and the smallest years and mapping back to a cost of $40
> per address. 
> 
> 
>> 2004:  29.00 /16s
> 
> 7424 /24 = $76,021,760.00

2007 was larger, mea culpa:

7808 /24 = $$79,953,920.00



And the implication is that if members have to go out and access markets for
addresses that they could get from ARIN, this "small problem" is
devastating.


Best,

-M<



From owen at delong.com  Tue Nov  9 16:08:36 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Nov 2010 13:08:36 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
	120: Protecting Number Resources
In-Reply-To: <C8FF1DEB.16CB3%marty@akamai.com>
References: <C8FF1DEB.16CB3%marty@akamai.com>
Message-ID: <32424BCB-FC02-4E06-9658-356D63FB0847@delong.com>


> Looking at the rest of this list:
> 
>> 2004:  29.00 /16s
>> 2005:  14.61 /16s
>> 2006:  14.01 /16s
>> 2007:  30.50 /16s
>> 2008:   8.45 /16s
>> 2009:   8.37 /16s
>> 2010*:  5.84 /16s
> 
> Doesn't really say much other than 2008 seemed to decline and there's no
> explanation why, at least one that is obvious.
> 
> 
Actually, what it says to me is that there was an anomalous spike in 2007
and otherwise it has generally declined since the beginning.

Since 2004 is the first year of the statistics presented, it is hard to tell if that
was a spike or the starting point of the decline.

Looking at it linearly....(all values rounded up to whole numbers):

31  |   |   |   | * |   |   |   |
30  |   |   |   |   |   |   |   |
29  | * |   |   |   |   |   |   |
28  |   |   |   |   |   |   |   |
27  |   |   |   |   |   |   |   |
26  |   |   |   |   |   |   |   |
25  |   |   |   |   |   |   |   |
24  |   |   |   |   |   |   |   |
23  |   |   |   |   |   |   |   |
22  |   |   |   |   |   |   |   |
21  |   |   |   |   |   |   |   |
20  |   |   |   |   |   |   |   |
19  |   |   |   |   |   |   |   |
18  |   |   |   |   |   |   |   |
17  |   |   |   |   |   |   |   |
16  |   |   |   |   |   |   |   |
15  |   | * | * |   |   |   |   |
14  |   |   |   |   |   |   |   |
13  |   |   |   |   |   |   |   |
12  |   |   |   |   |   |   |   |
11  |   |   |   |   |   |   |   |
10  |   |   |   |   |   |   |   |
 9  |   |   |   |   | * | * |   |
 8  |   |   |   |   |   |   |   |
 7  |   |   |   |   |   |   |   |
 6  |   |   |   |   |   |   | * |
=================================
     '04 '05 '06 '07 '08 '09 '10

To me this looks like the negative side of a parabola on a biennial
step with an anomaly at 2007. (In other words, returns diminishing
rapidly at the beginning with a continuing near zero rate over time).


Owen

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

From owen at delong.com  Tue Nov  9 16:10:21 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Nov 2010 13:10:21 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
	120: Protecting Number Resources
In-Reply-To: <C8FF20C7.16CBD%marty@akamai.com>
References: <C8FF20C7.16CBD%marty@akamai.com>
Message-ID: <08823139-E81C-4ADF-B936-268A0D81110B@delong.com>


On Nov 9, 2010, at 1:01 PM, Hannigan, Martin wrote:

> 
> 
> 
> On 11/9/10 3:48 PM, "Hannigan, Martin" <marty at akamai.com> wrote:
> 
>> 
>> 
>> 
>> On 11/9/10 3:03 PM, "Owen DeLong" <owen at delong.com> wrote:
>> 
>>> So in almost 7 years, we've reclaimed less than we gave Comcast last week.
>>> 
>>> Looks like a pretty small problem with minimal gain to me.
>>> 
>> 
>> 
>> Taking the largest and the smallest years and mapping back to a cost of $40
>> per address. 
>> 
>> 
>>> 2004:  29.00 /16s
>> 
>> 7424 /24 = $76,021,760.00
> 
> 2007 was larger, mea culpa:
> 
> 7808 /24 = $$79,953,920.00
> 
> 
> 
> And the implication is that if members have to go out and access markets for
> addresses that they could get from ARIN, this "small problem" is
> devastating.
> 
The implication is that if members continue to procrastinate IPv6
deployments and need addresses once none are available, the market
isn't a cost effective solution vs. IPv6 transition.

Owen



From marty at akamai.com  Tue Nov  9 16:43:22 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 9 Nov 2010 16:43:22 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <32424BCB-FC02-4E06-9658-356D63FB0847@delong.com>
Message-ID: <C8FF2AAA.16CDA%marty@akamai.com>




On 11/9/10 4:08 PM, "Owen DeLong" <owen at delong.com> wrote:

> 
>> Looking at the rest of this list:
>> 
>>> 2004:  29.00 /16s
>>> 2005:  14.61 /16s
>>> 2006:  14.01 /16s
>>> 2007:  30.50 /16s
>>> 2008:   8.45 /16s
>>> 2009:   8.37 /16s
>>> 2010*:  5.84 /16s
>> 
>> Doesn't really say much other than 2008 seemed to decline and there's no
>> explanation why, at least one that is obvious.
>> 
>> 
> Actually, what it says to me is that there was an anomalous spike in 2007
> and otherwise it has generally declined since the beginning.
> 
> Since 2004 is the first year of the statistics presented, it is hard to tell
> if that
> was a spike or the starting point of the decline.
> 
> Looking at it linearly....(all values rounded up to whole numbers):
> 
> 31  |   |   |   | * |   |   |   |
> 30  |   |   |   |   |   |   |   |
> 29  | * |   |   |   |   |   |   |
> 28  |   |   |   |   |   |   |   |
> 27  |   |   |   |   |   |   |   |
> 26  |   |   |   |   |   |   |   |
> 25  |   |   |   |   |   |   |   |
> 24  |   |   |   |   |   |   |   |
> 23  |   |   |   |   |   |   |   |
> 22  |   |   |   |   |   |   |   |
> 21  |   |   |   |   |   |   |   |
> 20  |   |   |   |   |   |   |   |
> 19  |   |   |   |   |   |   |   |
> 18  |   |   |   |   |   |   |   |
> 17  |   |   |   |   |   |   |   |
> 16  |   |   |   |   |   |   |   |
> 15  |   | * | * |   |   |   |   |
> 14  |   |   |   |   |   |   |   |
> 13  |   |   |   |   |   |   |   |
> 12  |   |   |   |   |   |   |   |
> 11  |   |   |   |   |   |   |   |
> 10  |   |   |   |   |   |   |   |
>  9  |   |   |   |   | * | * |   |
>  8  |   |   |   |   |   |   |   |
>  7  |   |   |   |   |   |   |   |
>  6  |   |   |   |   |   |   | * |
> =================================
>      '04 '05 '06 '07 '08 '09 '10
> 
> To me this looks like the negative side of a parabola on a biennial
> step with an anomaly at 2007. (In other words, returns diminishing
> rapidly at the beginning with a continuing near zero rate over time).
> 


Would you like some fries with that?

I apologize in advance for addressing this hyperbole, but this "could"
indicate a real problem vs. no problem at all. It could mean that ARIN has
done nothing with respect to recovery; not enough work has been done to
flush it out one way or the other.

Best,

-M<




From stephen at sprunk.org  Tue Nov  9 17:31:11 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 09 Nov 2010 16:31:11 -0600
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy
 Proposal	120: Protecting Number Resources
In-Reply-To: <473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
References: <4CD55B73.9030104@arin.net>	<20101109155001.GA34127@ussenterprise.ufp.org>	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
Message-ID: <4CD9CBAF.90901@sprunk.org>

On 09 Nov 2010 14:03, Owen DeLong wrote:
> On Nov 9, 2010, at 11:50 AM, John Curran wrote:
>> 2004:  29.00 /16s
>> 2005:  14.61 /16s
>> 2006:  14.01 /16s
>> 2007:  30.50 /16s
>> 2008:   8.45 /16s
>> 2009:   8.37 /16s
>> 2010*:  5.84 /16s   (*through Oct 31, 2010)
>>
>> Total: 110.78 /16s
> So in almost 7 years, we've reclaimed less than we gave Comcast last week.
>
> Looks like a pretty small problem with minimal gain to me.

Keep in mind that's how much ARIN has reclaimed passively, i.e. based on
reports of fraud, or due to non-payment of annual fees.

There seems to be a fairly strong consensus that the numbers would be
significantly larger if ARIN were actively looking for abandoned or
unjustified resources.

Also, keep in mind that the goal is _not_ to reclaim a significant
amount of space, e.g. to extend the lifetime of IPv4, so how the
reclamation rate compares to the allocation/assignment rate is irrelevant.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/9633fda7/attachment.p7s>

From jcurran at arin.net  Tue Nov  9 18:16:52 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 9 Nov 2010 18:16:52 -0500
Subject: [arin-ppml] Policy Proposal 120: Protecting Number Resources
In-Reply-To: <FF5DDC84-F924-44D8-929B-3D26BF2B45BC@delong.com>
References: <4CD55B73.9030104@arin.net> <4CD960EF.2010202@cisco.com>
	<20101109151958.GA30382@ussenterprise.ufp.org>
	<4CD96F6E.2050306@cisco.com>
	<FF5DDC84-F924-44D8-929B-3D26BF2B45BC@delong.com>
Message-ID: <F89BF204-4E2B-4598-AA21-9DDB03E4685D@arin.net>

On Nov 9, 2010, at 2:13 PM, Owen DeLong wrote:
On Nov 9, 2010, at 7:57 AM, Eliot Lear wrote:

Leo,

Thank you for your explanation. It seems as though you would like to start with low hanging fruit where "abandoned" would mean:

 1.  the address space is not routed; and
 2.  one of the following circumstances applies:
    *   administrative (or technical?) contact disavows use of the space
    *   no contacts can be found either by email, by phone, or by post.

2(b) is problematic IMHO. Just because we can't locate the contacts does not mean that
the organization is defunct or has stopped utilizing the resources.

Some other attributes also to consider (I'm not advocating either way, but just
providing some additional insight that may be of use):

  1) Was the address space ever routed, and/or how long ago?

      We don't have absolute data on this but do have some reference
      sources that appear fairly accurate.

  2) Are there valid (i.e. reachable & responding to SOA queries) in-addr DNS
      nameservers for the address space?

      Again, while not perfect due to use of split horizon, it can be a valid sign
      of life...

We look into some of these data points when researching hijacking/fraud
cases.

FYI,
/John

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

From bicknell at ufp.org  Tue Nov  9 18:29:11 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Nov 2010 15:29:11 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy
	Proposal	120: Protecting Number Resources
In-Reply-To: <4CD9CBAF.90901@sprunk.org>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
Message-ID: <20101109232911.GA65697@ussenterprise.ufp.org>


Stephen gave me a great foil to both pick on and praise. :)

In a message written on Tue, Nov 09, 2010 at 04:31:11PM -0600, Stephen Sprunk wrote:
> There seems to be a fairly strong consensus that the numbers would be
> significantly larger if ARIN were actively looking for abandoned or
> unjustified resources.

I caution anyone trying to draw such conclusions.  For instance,
there were many fewer people and likely fewer resources being sought
in say, 1991 than 2008.  At the same time it's more likely that
pre-ARIN property is abandoned, as many folks didn't know how to
or that they needed to turn it back in, and if you think about stuff
abandoned in the late 1990's scarcity wasn't as big an issue as
today.

The actual number I was looking for was not the size of the space,
but the NUMBER of netblocks.  I'm more curious if it's 500 or 5000
defunct blocks per year because I suspect the staff time is more
proportal to the number of blocks that must be investigated than
the space.

> Also, keep in mind that the goal is _not_ to reclaim a significant
> amount of space, e.g. to extend the lifetime of IPv4, so how the
> reclamation rate compares to the allocation/assignment rate is irrelevant.

I can't emphasize this enough.  Even if we could get back an entire /8's
worth in the aggregate, which I think is extremely unlikely, it's a drop
in the bucket compared to exhaustion.

But imagine how much spam could be sent, or malware distributed
from a /16 of space someone was able to hijack because the original
owner was no longer interested in it.  I think finding this space and
taking away the big "hijack me" sign on it could be a real benefit to
the network as a whole.

The most important thing to me though is that ARIN is actively taking
care of the space.  Unfortunately one of the duties of a good steward is
to clean up the mess when someone else just walks away.  I'd prefer
folks return addresses when they are done with them rathter than leave
them by the side of a road somewhere like a discarded pop can.  But if
they do leave them by the side of the road ARIN should pick them up,
dust them off and recycle them.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/3b6d7804/attachment.sig>

From stephen at sprunk.org  Tue Nov  9 19:04:49 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 09 Nov 2010 18:04:49 -0600
Subject: [arin-ppml] Draft Policy 2010-10 (Global Proposal):GlobalPolicy
 for IPv4 Allocations by the IANA Post Exhaustion- Last Call	(textrevised)
In-Reply-To: <647376A0-7C13-421B-91A2-2D910B5B1848@delong.com>
References: <4CCAF8EA.7080109@arin.net><20101029164738.GA49730@ussenterprise.ufp.org><4CCB08F9.1030303@umn.edu><75822E125BCB994F8	446858C4B19F0D70AC125B367@SUEX07-MBX-04.ad.syr.edu><6DE15637-1434-4CC2-8E63-C9CA539563AF@arin.net><75822E125BCB994F8446858C4B19	F0D70AC125B37F@SUEX07-MBX-04.ad.syr.edu>	<5CCD142D-C890-44BF-958F-AC1A1958E1AF@arin.net>	<32136639FEF54CFDB80A5AB685165263@mike>	<36D1C1A9-971F-4900-AB9C-04243D49100A@arin.net>	<4CD092B1.4090203@ipinc.net>	<ce1f01cb7ae3$2770f470$7652dd50$@net>	<EACF8B735E9CBA4B8BAF9E4165D03087915440@ex1.cait.wustl.edu>
	<4CD0D768.3060905@ipinc.net> <4CD382AB.1030107@sprunk.org>
	<C8C452C9-23DE-4209-BE49-139666EAC65A@delong.com>
	<4CD43014.9050606@sprunk.org>
	<4F0FC5AB-8640-427F-A57F-53677C74480E@delong.com>
	<4CD59C8A.3080407@sprunk.org>
	<647376A0-7C13-421B-91A2-2D910B5B1848@delong.com>
Message-ID: <4CD9E1A1.6040700@sprunk.org>

On 07 Nov 2010 01:27, Owen DeLong wrote:
> On Nov 6, 2010, at 11:20 AM, Stephen Sprunk wrote:
>> On 06 Nov 2010 04:08, Owen DeLong wrote:
>>> On Nov 5, 2010, at 9:25 AM, Stephen Sprunk wrote:
>>>> OTOH, absent an LRSA, there is no formal agreement that [ARIN] doesn't [have the power to enforce policy].
>>> Uh, generally it's pretty hard to claim that a contract is binding on an opt-out basis.
>>>
>>> I can't just make up a contract and then say you are subject to it's terms just because you don't have a contract that says otherwise.
>> A homeless shelter is quite certainly free to dictate people wear shoes in order to get a free meal.
> Yes, but, once you had a man that isn't wearing shoes a meal, you
> can't then take the meal back because you now require shoes.

You can't take the meal back because it's already been eaten and we
haven't discovered time travel yet.  However, just because you gave a
man without shoes a meal yesterday doesn't mean you are obligated to
give him one again tomorrow.

>>>> I was willing to accept granting special privileges to _all_ legacy holders prior to the LRSA being made available; now that it is, though, I'm reluctant to accept continuing to grant those same special privileges to those who do not sign.
>>> First, I don't agree with your use of the term "special privileges".
>> You don't think that being exempt from revocation or having limits on fee increases (or no fees at all, if one doesn't sign an LRSA) qualify as "special privileges"?  How does someone with an RSA get those terms?
> No, I do not. I think they are the existing T&Cs of yesteryear.

Yesteryear did not have a limit on fee increases because yesteryear had
no fees at all.

> There are lots of examples of T&Cs given to people in the past that are not available to new customers. For example, if you have an AT&T unlimited plan for your iPhone or iPad, you are on different T&Cs than anyone can get with new service today.

That's different because they have a contract specifying those
terms--and if the carrier is remotely competent, they'll have clauses in
the contract that allow them to terminate the contract after some period
if they see fit.  They usually don't, since the risk of losing the
customer to a competitor is not worth whatever extra revenue they
_might_ be able to bring in by forcing a change in terms, but they _could_.

Also, do note that ARIN, via the LRSA, is _still_ offering special terms
to legacy registrants that are not available to others, so it's not just
yesteryear we're talking about.

>>> Second, I really don't think legacy holders are a major problem and I don't see the point in pursuing them with pitchforks and torches just because they choose not to join the ARIN community.
>> I don't think pitchforks and torches are necessary, but I do think _at minimum_ ARIN owes the community some due diligence to make sure WHOIS is correct.
> Agreed. However, it appears that your definition of due diligence has
> some elements in common with my definition of pitchforks and torches.

Perhaps.  And, when we get to that point in the process, we can debate
the merits of each viewpoint; however, that should not stop us from
moving forward on the part we do agree on, which is having ARIN actively
doing reviews.

>>> Care to back that up with what ARIN possibly gains by [using a stick] other than litigation expenses?
>> First, a stick would get more legacy holders to sign the LRSA--or perhaps even an RSA.  Second, I believe a significant amount of abandoned or unused resources would be discovered and reclaimed.  Both outcomes benefit the community.
> Sticks can accomplish lots of things. However, the question isn't whether or not it is possible to get signatures using a stick. The question is whether or not it is valid to use a stick.

We have carrots and we have sticks.  I'm all for using the carrots to
entice as many folks as possible to join the community or at least
establish contact with ARIN formalize their resources.  However, at some
point we must break down and admit we have run out of people who carrots
work on, and either we throw up our hands and admit we've failed or we
continue on, using sticks.

>>> Besides who said anything about permanently unavailable. The space is either held by an organization or it isn't.  If we can't findthe organization, we record that fact and make it visible. Eventually, either we find out for sure that the organization is defunct, or, we find out that they do still exist. In the former case, resources can be reclaimed. In the latter case, they cannot.
>> Based on John Curran's recent messages, it is very difficult and time-consuming to reliably determine that a company is defunct.  Given ARIN's demonstrated unwillingness to take on work that policy doesn't explicitly require them to take, the likely result is that space would forever be "temporarily" unavailable.
> Which I don't see as a particular problem as long as it is at least marked that way.

IMHO, simply marking the space unavailable is insufficient.

> 1.	Recovering the space isn't of any particular benefit to the community.

There is benefit in being able to issue that space to other applicants,
though I doubt it'll be significant enough to justify the effort on that
basis alone.

> 2.	Having legacy holders that are using the space able to continue doing so is of benefit and is our moral obligation IMHO.

That's a red herring, since all they have to do to continue using the
space is respond and, if they are not remotely in compliance with
current justification rules, sign an LRSA.

>>> I'm just saying we shouldn't reclaim resources until we are certain that the organization no longer exists.
>> In contrast, I think we should reclaim resources if we cannot, after a reasonable amount of effort, determine the registrant still exists _and_ either is still using those resources or is willing to sign an LRSA.
> Yes... I understood that before. I still disagree with you, as I have
> restated above.

Well, I suppose all that's left is for us to write policy proposals
reflecting our viewpoints and see which, if either, gains consensus and
is adopted.

>>>> ARIN can add or remove any WHOIS/rDNS entry it wishes unless restricted by policy or by a contract, i.e. an RSA or LRSA.  IOW, since non-LRSA legacy holders have no contract restricting what ARIN does, they have no (legal) standing to complain if ARIN decides to stop providing them unpaid, uncontracted registry services--just like a homeless person has no (legal) standing to complain if a shelter decides to stop giving them free meals.  That's purely a moral issue.
>>> That's an interesting theory, but, I doubt that as the successor registry to registries that granted the registrations to organizations on very different terms with no contract stating that the terms could be subsequently changed without agreement, ARIN would actually have as good a standing as you claim in that situation.
>> ARIN only inherited an obligation to provide services gratis and in perpetuity if its predecessors actually contracted with registrants to do so _and_ ARIN is their legal successor in interest.  I'm fairly sure the latter is true, but I'm almost certain the former is not.
> It's very gray, but, whether there is a written contract or not, certainly, at the time the resources were issued, it was the standard policy and expectation that whois, in-addr, and registration services would be performed by the registry gratis in perpetuity.

Ah, but

>> A contract is only valid if there is an exchange of "consideration (usually goods or services in one direction and money in the other).  If I promise you a free meal tomorrow but fail to provide one, you _cannot_ sue me for breach of contract because you paid no "consideration" for my promise and therefore it was not a valid contract.
> The exchange required does not have to be direct. There are many instances where contracts create third-party rights and/or obligations.
>
> In this case, the USDoD, DARPA, and USDoC have provided consideration and a contract to the predecessor registries to operate the services. Legacy holders are a third-party obligation of those contracts.

AIUI, only the parties to a contract (e.g. DARPA et al) can sue for
breach of that contract .  Still, where are the contracts that would
supposedly be breached?

>>> I'm saying that going after all or even some random number of resources on that basis is a dubious set of selection criteria at best and seems rather arbitrary to me.
>> If I see an elderly lady down the street from me tending her garden every day for years, but then a few days go by without any sign of her and there's an awful smell coming from her house, it's not unreasonable for the police to enter and check to make sure she's still alive.  If it turns out she's fine, no harm was done.
> Sure... But, what you are proposing is that if the police don't find her
> and don't find a body, they should let you sell her house.

There are standard procedures for that--and yes, the state will
eventually auction off her house to cover unpaid taxes, and if she
doesn't show up in a reasonable time to collect any remaining proceeds,
they'll keep that too.

>> And, for the record, I'd like to see LRSA signatories reviewed as well.  We can't revoke their space, but it's useful for the community to understand exactly what it is we're sanctioning so that we can decide if it's a good idea to continue offering the LRSA.
> I have no problem with reviewing LRSA signatories so long as we stick to our contractual obligations and don't attempt to revoke their space.

Of course.  That _would_ be a breach of contract.

>>> This theory that ARIN is somehow entitled as the successor registry to retroactively change the terms under which legacy resources were issued without the consent of the recipients really strikes me as being quite odd.
>> That's exactly what happened with domain names and with the other RIRs that inherited legacy numbers.  ARIN has been far more generous to legacy registrants, but IMHO now that we have the LRSA, it's time for the honeymoon to end.
> Holding up what happened with domain names as an example of how ARIN should behave is not going to win any points with me. I think that domain names have become an unmitigated mess and a profiteering opportunity for ICANN which has led to some seriously misguided policies in that area.

I'm sure we all have complaints about how DNS is managed, but the
reality is that orgs with legacy domains ended up having to sign new
contracts with and pay fees to the successor registry--and DARPA et al
didn't step in and claim it breached some contract with the prior registry.

The _exact_ same thing happened with legacy number resources being
transferred to the other RIRs, so it's ARIN that's the odd one out, not DNS.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/ea31c747/attachment.p7s>

From owen at delong.com  Tue Nov  9 19:25:06 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Nov 2010 16:25:06 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy
	Proposal	120: Protecting Number Resources
In-Reply-To: <4CD9CBAF.90901@sprunk.org>
References: <4CD55B73.9030104@arin.net>	<20101109155001.GA34127@ussenterprise.ufp.org>	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
Message-ID: <DBE59288-7635-45D3-A4FD-550E0B3E5EF4@delong.com>


On Nov 9, 2010, at 2:31 PM, Stephen Sprunk wrote:

> On 09 Nov 2010 14:03, Owen DeLong wrote:
>> On Nov 9, 2010, at 11:50 AM, John Curran wrote:
>>> 2004:  29.00 /16s
>>> 2005:  14.61 /16s
>>> 2006:  14.01 /16s
>>> 2007:  30.50 /16s
>>> 2008:   8.45 /16s
>>> 2009:   8.37 /16s
>>> 2010*:  5.84 /16s   (*through Oct 31, 2010)
>>> 
>>> Total: 110.78 /16s
>> So in almost 7 years, we've reclaimed less than we gave Comcast last week.
>> 
>> Looks like a pretty small problem with minimal gain to me.
> 
> Keep in mind that's how much ARIN has reclaimed passively, i.e. based on
> reports of fraud, or due to non-payment of annual fees.
> 
I believe John said that was the amount reclaimed due to non-payment
of fees. I believe that's a fair representation of the abandonment rate.

> There seems to be a fairly strong consensus that the numbers would be
> significantly larger if ARIN were actively looking for abandoned or
> unjustified resources.
> 
I'm not sure where this consensus comes from. I don't think addresses
are getting abandoned any faster now. Fraud and underutilization
are a different matter, but, in terms of abandonment, I think the
numbers show that there's not as much as some seem to be claiming.

> Also, keep in mind that the goal is _not_ to reclaim a significant
> amount of space, e.g. to extend the lifetime of IPv4, so how the
> reclamation rate compares to the allocation/assignment rate is irrelevant.
> 
Depends on who you talk to.

Owen



From owen at delong.com  Tue Nov  9 19:35:03 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Nov 2010 16:35:03 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy
	Proposal	120: Protecting Number Resources
In-Reply-To: <20101109232911.GA65697@ussenterprise.ufp.org>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
Message-ID: <2E20B993-0A06-40C8-B2AD-411354E1C0D3@delong.com>

> 
>> Also, keep in mind that the goal is _not_ to reclaim a significant
>> amount of space, e.g. to extend the lifetime of IPv4, so how the
>> reclamation rate compares to the allocation/assignment rate is irrelevant.
> 
> I can't emphasize this enough.  Even if we could get back an entire /8's
> worth in the aggregate, which I think is extremely unlikely, it's a drop
> in the bucket compared to exhaustion.
> 
> But imagine how much spam could be sent, or malware distributed
> from a /16 of space someone was able to hijack because the original
> owner was no longer interested in it.  I think finding this space and
> taking away the big "hijack me" sign on it could be a real benefit to
> the network as a whole.
> 
And here's where you wander off in the weeds...

How does reclamation in any way improve this beyond what is
accomplished by marking records with invalid/unverifiable POC
data as such and leaving them?

Seems to me doing an actual reclamation requires significantly
more diligence (effort/staff time/expense) on ARIN's part and
yields no additional benefit in this area.

The only reason to bother reclaiming is if you intend to reissue.
Since there does seem to be consensus that reissuing is of little
value, is there any reason to allocate resources to reclamation
instead of merely marking invalid/unresponsive records?

> The most important thing to me though is that ARIN is actively taking
> care of the space.  Unfortunately one of the duties of a good steward is
> to clean up the mess when someone else just walks away.  I'd prefer
> folks return addresses when they are done with them rathter than leave
> them by the side of a road somewhere like a discarded pop can.  But if
> they do leave them by the side of the road ARIN should pick them up,
> dust them off and recycle them.
> 
There are lots of possible ways to take care. There's no physical
pollution here and reclamation while it sounds all neat and tidy
really doesn't accomplish much compared to its costs.

Owen



From bicknell at ufp.org  Tue Nov  9 20:41:19 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Nov 2010 17:41:19 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy
	Proposal	120: Protecting Number Resources
In-Reply-To: <2E20B993-0A06-40C8-B2AD-411354E1C0D3@delong.com>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
	<2E20B993-0A06-40C8-B2AD-411354E1C0D3@delong.com>
Message-ID: <20101110014119.GA72008@ussenterprise.ufp.org>

In a message written on Tue, Nov 09, 2010 at 04:35:03PM -0800, Owen DeLong wrote:
> How does reclamation in any way improve this beyond what is
> accomplished by marking records with invalid/unverifiable POC
> data as such and leaving them?

I believe there are folks who will look for that in whois and target
those blocks for hijacking.  I'd like to think every ISP carefully
checked the records before routing things, but we have years of
evidence that is not the case.  I fear we are creating an attractive
nussance.

> The only reason to bother reclaiming is if you intend to reissue.
> Since there does seem to be consensus that reissuing is of little
> value, is there any reason to allocate resources to reclamation
> instead of merely marking invalid/unresponsive records?

I believe the space should be re-issued.  I also disagree strongly
that reissueing is of little value.  It may be of little value with
respect to the problem of extending the life of IPv4, but that is
not the only measure.

It will be of huge value to the lucky recipients who are able to
get the space from ARIN who otherwise would not have had that
opportunity and either had to go without or buy it on the open
market.  Several others have attempted to estimate the value using
various measures, and the numbers are quite large.  I think there
is likely a lot of value to getting this space back in the system.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/c7ef1074/attachment.sig>

From stephen at sprunk.org  Tue Nov  9 20:59:33 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 09 Nov 2010 19:59:33 -0600
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy
 Proposal	120: Protecting Number Resources
In-Reply-To: <DBE59288-7635-45D3-A4FD-550E0B3E5EF4@delong.com>
References: <4CD55B73.9030104@arin.net>	<20101109155001.GA34127@ussenterprise.ufp.org>	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<DBE59288-7635-45D3-A4FD-550E0B3E5EF4@delong.com>
Message-ID: <4CD9FC85.20103@sprunk.org>

On 09 Nov 2010 18:25, Owen DeLong wrote:
> On Nov 9, 2010, at 2:31 PM, Stephen Sprunk wrote:
>> On 09 Nov 2010 14:03, Owen DeLong wrote:
>>> On Nov 9, 2010, at 11:50 AM, John Curran wrote:
>>>> 2004:  29.00 /16s
>>>> 2005:  14.61 /16s
>>>> 2006:  14.01 /16s
>>>> 2007:  30.50 /16s
>>>> 2008:   8.45 /16s
>>>> 2009:   8.37 /16s
>>>> 2010*:  5.84 /16s   (*through Oct 31, 2010)
>>>>
>>>> Total: 110.78 /16s
>>> So in almost 7 years, we've reclaimed less than we gave Comcast last week.
>>>
>>> Looks like a pretty small problem with minimal gain to me.
>> Keep in mind that's how much ARIN has reclaimed passively, i.e. based on reports of fraud, or due to non-payment of annual fees.
> I believe John said that was the amount reclaimed due to non-payment
> of fees.

The slides referenced earlier referred to multiple causes, so I assumed
the numbers above did as well.  In any event, they're all passive
causes, which was my point.

>  I believe that's a fair representation of the abandonment rate.

Revocation for non-payment is a fair representation of the abandonment
rate for ARIN-issued resources; it says absolutely nothing about the
legacy abandonment rate (most of which probably occurred before ARIN's
formation), nor does it say anything at all about folks that are still
paying fees and/or staying in contact but could no longer justify their
space if reviewed.

>> There seems to be a fairly strong consensus that the numbers would be significantly larger if ARIN were actively looking for abandoned or unjustified resources.
> I'm not sure where this consensus comes from. I don't think addresses
> are getting abandoned any faster now. Fraud and underutilization
> are a different matter, but, in terms of abandonment, I think the
> numbers show that there's not as much as some seem to be claiming.

I don't think the numbers presented so far show _anything_ useful,
considering that ARIN has never _gone looking_ for abandoned,
fraudulent, or underutilized space.  They _might_ indicate reporting
rates, but even that is dubious.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101109/c313946a/attachment.p7s>

From owen at delong.com  Tue Nov  9 21:03:03 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Nov 2010 18:03:03 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy
	Proposal	120: Protecting Number Resources
In-Reply-To: <20101110014119.GA72008@ussenterprise.ufp.org>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
	<2E20B993-0A06-40C8-B2AD-411354E1C0D3@delong.com>
	<20101110014119.GA72008@ussenterprise.ufp.org>
Message-ID: <99B21D26-A151-498B-B960-5A5096C2E3EB@delong.com>


On Nov 9, 2010, at 5:41 PM, Leo Bicknell wrote:

> In a message written on Tue, Nov 09, 2010 at 04:35:03PM -0800, Owen DeLong wrote:
>> How does reclamation in any way improve this beyond what is
>> accomplished by marking records with invalid/unverifiable POC
>> data as such and leaving them?
> 
> I believe there are folks who will look for that in whois and target
> those blocks for hijacking.  I'd like to think every ISP carefully
> checked the records before routing things, but we have years of
> evidence that is not the case.  I fear we are creating an attractive
> nussance.
> 
And they won't look for blocks that simply aren't in whois?

I don't buy the argument. The hijackers have no trouble finding the
blocks. This fallacious argument was used for a long time to block
efforts to get these blocks marked in public view. We finally came
to realize that marking them publicly allows for filtration to prevent
hijacking.

Obscuring the existence of the blocks does nothing to stop
hijacking. Marking them visibly does.

>> The only reason to bother reclaiming is if you intend to reissue.
>> Since there does seem to be consensus that reissuing is of little
>> value, is there any reason to allocate resources to reclamation
>> instead of merely marking invalid/unresponsive records?
> 
> I believe the space should be re-issued.  I also disagree strongly
> that reissueing is of little value.  It may be of little value with
> respect to the problem of extending the life of IPv4, but that is
> not the only measure.
> 
While I agree there is minimal value in reissuing, I think it is
dwarfed by the costs of dubious reclamations once the prior
organization notices.

> It will be of huge value to the lucky recipients who are able to
> get the space from ARIN who otherwise would not have had that
> opportunity and either had to go without or buy it on the open
> market.  Several others have attempted to estimate the value using
> various measures, and the numbers are quite large.  I think there
> is likely a lot of value to getting this space back in the system.
> 
Until they end up in a routing war with the prior holder or in
a protracted legal battle they didn't expect to be involved in
as a codefendant to ARIN.

I think that Mr. Hannigan's $40/IP is a rather inflated view of
the value of IPv4. At that price, IPv6 is cost effective almost
regardless of the amount of hardware you have to replace.

Many of the other more spectacular numbers have been even
more inflated (I've heard as much as $1,000 per IP). I simply
don't think they are real.

Owen



From tedm at ipinc.net  Wed Nov 10 03:02:41 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Nov 2010 00:02:41 -0800
Subject: [arin-ppml] Comcast
In-Reply-To: <AANLkTiktXm-cE674SiettUdaohjhq2yGja+UEkkik2EA@mail.gmail.com>
References: <47240.1289269565@tristatelogic.com>	<4CD8C582.9070002@ipinc.net>	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>	<4CD8D2D7.6020008@ipinc.net>
	<AANLkTiktXm-cE674SiettUdaohjhq2yGja+UEkkik2EA@mail.gmail.com>
Message-ID: <4CDA51A1.2060208@ipinc.net>

On 11/9/2010 5:56 AM, Heather Schiller wrote:
> On Mon, Nov 8, 2010 at 11:49 PM, Ted Mittelstaedt<tedm at ipinc.net>  wrote:
>> On 11/8/2010 8:19 PM, Heather Schiller wrote:
>>>
>>> On Mon, Nov 8, 2010 at 10:52 PM, Ted Mittelstaedt<tedm at ipinc.net>    wrote:
>>>>
>>>> On 11/8/2010 6:26 PM, Ronald F. Guilmette wrote:
>>>>>
>>>>> In message<206001cb7f91$64b8f6e0$2e2ae4a0$@com>,
>>>>> "Warren Johnson"<warren at wholesaleinternet.com>      wrote:
>>>>>
>>>>>> I simply think it is intriguing that a large evangelist and proponent
>>>>>> of
>>>>>> ipv6 adoption required a gigantic allocation.  It demonstrates the
>>>>>> complexity of the issue.
>>>>>
>>>>>
>>>>> Just curious... Who is the official keeper of the IPv4 doomsday clock,
>>>>> and how much closer to midnite does this allocation put us?
>>>>>
>>>>
>>>> That's a catch-22.  You cannot runout of IPv4 unless you get the Internet
>>>> very popular but it's the popularity of the Internet that forces you to
>>>> runout of IPv4.
>>>>
>>>> I frankly am much more interested in what the percentage of that 8
>>>> million IPs is free Legacy space and what percentage are they paying
>>>> ARIN for?
>>>>
>>>
>>>   Huh?  They got the /9 on 10/21/2010 - which means none of it is
>>> legacy and they are paying for all of it.  ...they were probably
>>> already billing as an XL ($18k/yr) so it isn't costing them anything
>>> extra.
>>>
>>> No magic here.. anyone can look at the allocation, allocation dates
>>> and the resources held under an org id:
>>>
>>> The allocation:
>>> http://whois.arin.net/rest/org/CCCH-3.html
>>>
>>> Resources held under that org-id (including a /13, which would have
>>> put them into the XL category prior to the /9 being allocated)
>>> http://whois.arin.net/rest/org/CCCH-3/nets
>>>
>>
>> Interesting, I didn't realize that they had all of their allocation
>> under a single /9
>>
>
> /sigh
>
>   They don't have *all of their allocation under a single /9*
>

I knew that,  I was being sarcastic, the thread was just too tempting to 
NOT make smart-ass responses to.  I'll admit it I'm a smart-ass,
always have been, and it's just impossible to resist when something
like that thread comes along which is just begging for it.  And the
original poster worded his post exactly so that it could be read
either that comcast got an additional /9 or comcast had a total of /9.
Such a lead in only comes around once in a great while.  Sigh.

Ted


> Really.. just click the link (I promise it's SFW, no dancing bears, no
> exploding malware) http://whois.arin.net/rest/org/CCCH-3/nets    It
> takes you to ARIN's website and shows you a listing of everything
> under that Comcast account.  Which includes the /9, *and* a bunch of
> other space.  They probably don't even have all their allocations
> under a single org id... lots of companies don't.
>
> PPML is for discussion of policy proposals, not for conjecture or fud
> about allocations ARIN has made.
>
>
>> Obviously Comcast would have never qualified for a /9 when they were
>> first getting started.  So they must have renumbered dozens of times
>> as they got larger and worked their way up in size, qualifying for
>> larger and larger allocations.
>>
>> It must have been holy hell on their customers to have to go through
>> all that renumbering, though.
>>
>> Ted
>>
>>>
>>>
>>>> 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 tedm at ipinc.net  Wed Nov 10 03:21:02 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Nov 2010 00:21:02 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy
 Proposal	120: Protecting Number Resources
In-Reply-To: <4CD9FC85.20103@sprunk.org>
References: <4CD55B73.9030104@arin.net>	<20101109155001.GA34127@ussenterprise.ufp.org>	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>	<4CD9CBAF.90901@sprunk.org>	<DBE59288-7635-45D3-A4FD-550E0B3E5EF4@delong.com>
	<4CD9FC85.20103@sprunk.org>
Message-ID: <4CDA55EE.2060009@ipinc.net>

On 11/9/2010 5:59 PM, Stephen Sprunk wrote:
>
> Revocation for non-payment is a fair representation of the abandonment
> rate for ARIN-issued resources; it says absolutely nothing about the
> legacy abandonment rate (most of which probably occurred before ARIN's
> formation)

No, BUT section 3.6.1 has the statement:

"...ARIN will maintain, and make readily available to the community, a 
current list of number resources with no valid POC; this data will be 
subject to the current bulk Whois policy...."

ARIN has publicly defined criteria for determining if a POC is non 
respondent in section 3.6

If you make what I feel is the extremely logical assumption
that invalid POCs are tied to abandoned resources, then all you
need to do is look at the current list of number resources with
no valid POC to see how much IPv4 that a reclamation drive
would gain.

The $64,000 question is, where is this list?  Why is it
not provided when it's required by policy, yet this "paid
abandonment list" which is required by nothing, is instantly
supplied by John when asked?

, nor does it say anything at all about folks that are still
> paying fees and/or staying in contact but could no longer justify their
> space if reviewed.


>
>>> There seems to be a fairly strong consensus that the numbers would be significantly larger if ARIN were actively looking for abandoned or unjustified resources.
>> I'm not sure where this consensus comes from. I don't think addresses
>> are getting abandoned any faster now. Fraud and underutilization
>> are a different matter, but, in terms of abandonment, I think the
>> numbers show that there's not as much as some seem to be claiming.
>
> I don't think the numbers presented so far show _anything_ useful,
> considering that ARIN has never _gone looking_ for abandoned,
> fraudulent, or underutilized space.  They _might_ indicate reporting
> rates, but even that is dubious.
>

Yes, this is correct - please google "self selected surveys"
if you don't understand that measuring this problem by looking
at ARIN's reports of "paid" registration abandonments is absolutely useless.


Ted


From tedm at ipinc.net  Wed Nov 10 03:33:46 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Nov 2010 00:33:46 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy
 Proposal	120: Protecting Number Resources
In-Reply-To: <4CDA55EE.2060009@ipinc.net>
References: <4CD55B73.9030104@arin.net>	<20101109155001.GA34127@ussenterprise.ufp.org>	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>	<4CD9CBAF.90901@sprunk.org>	<DBE59288-7635-45D3-A4FD-550E0B3E5EF4@delong.com>	<4CD9FC85.20103@sprunk.org>
	<4CDA55EE.2060009@ipinc.net>
Message-ID: <4CDA58EA.9020909@ipinc.net>

On 11/10/2010 12:21 AM, Ted Mittelstaedt wrote:
> On 11/9/2010 5:59 PM, Stephen Sprunk wrote:
>>
>> Revocation for non-payment is a fair representation of the abandonment
>> rate for ARIN-issued resources; it says absolutely nothing about the
>> legacy abandonment rate (most of which probably occurred before ARIN's
>> formation)
>
> No, BUT section 3.6.1 has the statement:
>
> "...ARIN will maintain, and make readily available to the community, a
> current list of number resources with no valid POC; this data will be
> subject to the current bulk Whois policy...."
>
> ARIN has publicly defined criteria for determining if a POC is non
> respondent in section 3.6
>
> If you make what I feel is the extremely logical assumption
> that invalid POCs are tied to abandoned resources, then all you
> need to do is look at the current list of number resources with
> no valid POC to see how much IPv4 that a reclamation drive
> would gain.
>
> The $64,000 question is, where is this list? Why is it
> not provided when it's required by policy, yet this "paid
> abandonment list" which is required by nothing, is instantly
> supplied by John when asked?
>

I have to apologize for this last paragraph, I just noticed the
post yesterday from John regarding the addition of a link to this
list in the downloads section.

Hopefully, THAT info should shed some light on this.

Ted

> , nor does it say anything at all about folks that are still
>> paying fees and/or staying in contact but could no longer justify their
>> space if reviewed.
>
>
>>
>>>> There seems to be a fairly strong consensus that the numbers would
>>>> be significantly larger if ARIN were actively looking for abandoned
>>>> or unjustified resources.
>>> I'm not sure where this consensus comes from. I don't think addresses
>>> are getting abandoned any faster now. Fraud and underutilization
>>> are a different matter, but, in terms of abandonment, I think the
>>> numbers show that there's not as much as some seem to be claiming.
>>
>> I don't think the numbers presented so far show _anything_ useful,
>> considering that ARIN has never _gone looking_ for abandoned,
>> fraudulent, or underutilized space. They _might_ indicate reporting
>> rates, but even that is dubious.
>>
>
> Yes, this is correct - please google "self selected surveys"
> if you don't understand that measuring this problem by looking
> at ARIN's reports of "paid" registration abandonments is absolutely
> useless.
>
>
> 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 tedm at ipinc.net  Wed Nov 10 03:53:55 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Nov 2010 00:53:55 -0800
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <9BD1345A-DA50-4AF9-A2FA-5942EA96D4D0@arin.net>
References: <46738.1288961816@tristatelogic.com>	<F34108F3-1D71-4B46-8099-B8C000A6095A@arin.net>	<4CD463CC.3090107@ipinc.net>	<6ADA4C3D-8615-4F3E-8E0A-90A4F330274C@arin.net>
	<9BD1345A-DA50-4AF9-A2FA-5942EA96D4D0@arin.net>
Message-ID: <4CDA5DA3.5050408@ipinc.net>

On 11/9/2010 5:24 AM, John Curran wrote:
> On Nov 5, 2010, at 4:23 PM, John Curran wrote:
>> On Nov 5, 2010, at 4:06 PM, Ted Mittelstaedt wrote:
>>>
>>> "...ARIN will maintain, and make readily available to the
>>> community, a current list of number resources with no valid POC;
>>> this data will be subject to the current bulk Whois policy...."
>>>
>>> I would recommend that any "auditing" be concentrated on this
>>> list FIRST.
>>>
>>> John, please provide the URL for this list and Ron can do his
>>> auditing on that.
>>
>> Ted - We're actively working on the automation to generate this
>> list.  I'll provide an ETA shortly. /John
>
> Ted -
>
> This functionality is available within ARIN Online to those that have
> a signed Bulk WHOIS Acceptable Use Policy (AUP) on file with ARIN.
> Through this feature, ARIN provides a list of resources with no valid
> Points of Contacts (POCs).  This report is available on the Downloads
> tab when logged in to ARIN Online.
>

Many thanks for what was probably stuck on someone's already overloaded
plate!

One thing that does concern me though is the following:

"... Distribution of derivative data is only permitted with the express 
written permission of ARIN and under the same terms as this AUP..."

Would summary totals be considered derivative data?  Meaning that if
I were to sign a bulk AUP, write an an awk script that counted the
numbers of networks in the no-valid-poc-resource-report.txt file
and typed in a numerical total in a post on PPML would I be in violation
of the AUP?

It seems to me that most people would merely be interested in the
totals anyway - would ARIN consider putting a "total number of
Number Resources Without Valid POCs is currently at XXXX" on the
download page?

Ted

> /John
>
> John Curran President and CEO 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 jcurran at arin.net  Wed Nov 10 07:15:15 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 10 Nov 2010 07:15:15 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re:
	Policy	Proposal	120: Protecting Number Resources
In-Reply-To: <20101109232911.GA65697@ussenterprise.ufp.org>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
Message-ID: <1CE9C359-6957-4881-8A50-4916E3CC3590@arin.net>

On Nov 9, 2010, at 6:29 PM, Leo Bicknell wrote:

> The actual number I was looking for was not the size of the space,
> but the NUMBER of netblocks.  I'm more curious if it's 500 or 5000
> defunct blocks per year because I suspect the staff time is more
> proportal to the number of blocks that must be investigated than
> the space.

Number of revocations due to non-payment:

2004: 171
2005: 151
2006: 110
2007: 209
2008: 65
2009: 124
2010*: 81 (*through Oct 31, 2010)

/John

John Curran 
President and CEO
ARIN



From jcurran at arin.net  Wed Nov 10 07:27:58 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 10 Nov 2010 07:27:58 -0500
Subject: [arin-ppml] audit tools and techniques
In-Reply-To: <4CDA5DA3.5050408@ipinc.net>
References: <46738.1288961816@tristatelogic.com>
	<F34108F3-1D71-4B46-8099-B8C000A6095A@arin.net>
	<4CD463CC.3090107@ipinc.net>
	<6ADA4C3D-8615-4F3E-8E0A-90A4F330274C@arin.net>
	<9BD1345A-DA50-4AF9-A2FA-5942EA96D4D0@arin.net>
	<4CDA5DA3.5050408@ipinc.net>
Message-ID: <8A2BB359-1B7A-49E5-8EB6-CC3382B7B2B8@arin.net>

On Nov 10, 2010, at 3:53 AM, Ted Mittelstaedt wrote:
> 
> One thing that does concern me though is the following:
> 
> "... Distribution of derivative data is only permitted with the express written permission of ARIN and under the same terms as this AUP..."
> 
> Would summary totals be considered derivative data?  Meaning that if
> I were to sign a bulk AUP, write an an awk script that counted the
> numbers of networks in the no-valid-poc-resource-report.txt file
> and typed in a numerical total in a post on PPML would I be in violation
> of the AUP?
> 
> It seems to me that most people would merely be interested in the
> totals anyway - would ARIN consider putting a "total number of
> Number Resources Without Valid POCs is currently at XXXX" on the
> download page?

Ted - 
 
  Please consider this express written permission to produce 
  summary totals and to distribute them to PPML as desired
  (and we'll work on adding invalid POC summary stats to the
  public number resources statistics reports)

/John

John Curran
President and CEO
ARIN


 

From cgrundemann at gmail.com  Wed Nov 10 12:03:23 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 10 Nov 2010 10:03:23 -0700
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <DBE59288-7635-45D3-A4FD-550E0B3E5EF4@delong.com>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<DBE59288-7635-45D3-A4FD-550E0B3E5EF4@delong.com>
Message-ID: <AANLkTimXH2r_0p95pb0bmXmgpsRjnjR-NJUVy3_L+Unw@mail.gmail.com>

On Tue, Nov 9, 2010 at 17:25, Owen DeLong <owen at delong.com> wrote:
>
> On Nov 9, 2010, at 2:31 PM, Stephen Sprunk wrote:
>
>> On 09 Nov 2010 14:03, Owen DeLong wrote:
>>> On Nov 9, 2010, at 11:50 AM, John Curran wrote:
>>>> 2004: ?29.00 /16s
>>>> 2005: ?14.61 /16s
>>>> 2006: ?14.01 /16s
>>>> 2007: ?30.50 /16s
>>>> 2008: ? 8.45 /16s
>>>> 2009: ? 8.37 /16s
>>>> 2010*: ?5.84 /16s ? (*through Oct 31, 2010)
>>>>
>>>> Total: 110.78 /16s
>>> So in almost 7 years, we've reclaimed less than we gave Comcast last week.
>>>
>>> Looks like a pretty small problem with minimal gain to me.
>>
>> Keep in mind that's how much ARIN has reclaimed passively, i.e. based on
>> reports of fraud, or due to non-payment of annual fees.
>>
> I believe John said that was the amount reclaimed due to non-payment
> of fees. I believe that's a fair representation of the abandonment rate.

I agree.

>> There seems to be a fairly strong consensus that the numbers would be
>> significantly larger if ARIN were actively looking for abandoned or
>> unjustified resources.
>>
> I'm not sure where this consensus comes from. I don't think addresses
> are getting abandoned any faster now.

Yes but you have to take into account both rate and time elapsed to
come up with a number. What I mean is that legacy resources, which
have no payment required, are probably abandoned at the same rate that
non-legacy/payment-required space is abandoned. BUT, there has been
little active reclamation of that space, so it has probably just built
up.

Again, I am sure there is not enough space to help runout but I am
also sure that there is enough abandoned space to cause havoc from a
spam/malware/misuse perspective.

~Chris

> Fraud and underutilization
> are a different matter, but, in terms of abandonment, I think the
> numbers show that there's not as much as some seem to be claiming.
>
>> Also, keep in mind that the goal is _not_ to reclaim a significant
>> amount of space, e.g. to extend the lifetime of IPv4, so how the
>> reclamation rate compares to the allocation/assignment rate is irrelevant.
>>
> Depends on who you talk to.
>
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>




-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From bill at herrin.us  Wed Nov 10 14:10:52 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 10 Nov 2010 14:10:52 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <20101109232911.GA65697@ussenterprise.ufp.org>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
Message-ID: <AANLkTi=Pc76hCjG82OG+X4Ag622kNauiKCpn73FCMHE+@mail.gmail.com>

On Tue, Nov 9, 2010 at 6:29 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> The actual number I was looking for was not the size of the space,
> but the NUMBER of netblocks. ?I'm more curious if it's 500 or 5000
> defunct blocks per year because I suspect the staff time is more
> proportal to the number of blocks that must be investigated than
> the space.

Hi Leo,

It occurred to me that would be the more interesting number for this
discussion. How many blocks, not total size, and only the ones
reclaimed for non-payment. I'd also like to see the minimum, median
and maximum length of time that the blocks were registered before
reclamation. With those numbers it should be possible to make a decent
SWAG as to how many blocks actually are abandoned down in the legacy
pools.


> But imagine how much spam could be sent, or malware distributed
> from a /16 of space someone was able to hijack because the original
> owner was no longer interested in it. ?I think finding this space and
> taking away the big "hijack me" sign on it could be a real benefit to
> the network as a whole.

You know, I don't buy that argument. Space that isn't presently being
announced for whatever reason is vulnerable this activity. The forged
documents that the ISP doesn't scrutinize too closely look exactly the
same. It doesn't really matter whether that's because its abandoned or
because it's merely in a use off the Internet.

In both cases it's really the same difference whether its space
someone brought in or space provided by the ISP. Either way the
complaint quickly finds its way to the ISP which either takes abuse
seriously or doesn't.

If you want *real* antispam value here, have ARIN establish an
RBL-style whitelist and delegate it to the registrants the same way
RDNS is. Let them flag in this DNS tree which servers they *intend* to
originate mail with a default result of "maybe." That'll clean up the
route hijacks for spamming that don't first gain control of the ARIN
record.

Regards.
Bill Herrin


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


From jcurran at arin.net  Wed Nov 10 15:55:03 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 10 Nov 2010 15:55:03 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <AANLkTi=Pc76hCjG82OG+X4Ag622kNauiKCpn73FCMHE+@mail.gmail.com>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
	<AANLkTi=Pc76hCjG82OG+X4Ag622kNauiKCpn73FCMHE+@mail.gmail.com>
Message-ID: <BA70292E-3CB4-47EE-932A-683F284B2222@arin.net>

On Nov 10, 2010, at 2:10 PM, William Herrin wrote:

> It occurred to me that would be the more interesting number for this
> discussion. How many blocks, not total size, and only the ones
> reclaimed for non-payment. I'd also like to see the minimum, median
> and maximum length of time that the blocks were registered before
> reclamation. With those numbers it should be possible to make a decent
> SWAG as to how many blocks actually are abandoned down in the legacy
> pools.

Bill - 
 
I've sent the number of blocks reclaimed, but do not believe that we
will be able to easily generate statistics about the length of time 
registered prior to reclamation (i.e. it may require manual collation
to generate.)  I will look into it.  

Thanks,
/John 

John Curran
President and CEO
ARIN




From bill at herrin.us  Wed Nov 10 17:46:07 2010
From: bill at herrin.us (William Herrin)
Date: Wed, 10 Nov 2010 17:46:07 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <BA70292E-3CB4-47EE-932A-683F284B2222@arin.net>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
	<AANLkTi=Pc76hCjG82OG+X4Ag622kNauiKCpn73FCMHE+@mail.gmail.com>
	<BA70292E-3CB4-47EE-932A-683F284B2222@arin.net>
Message-ID: <AANLkTik_KO1gu0HAXHQPnxwySEQUn_y4ZwA+NbSFTyAG@mail.gmail.com>

On Wed, Nov 10, 2010 at 3:55 PM, John Curran <jcurran at arin.net> wrote:
> On Nov 10, 2010, at 2:10 PM, William Herrin wrote:
>> It occurred to me that would be the more interesting number for this
>> discussion. How many blocks, not total size, and only the ones
>> reclaimed for non-payment. I'd also like to see the minimum, median
>> and maximum length of time that the blocks were registered before
>> reclamation. With those numbers it should be possible to make a decent
>> SWAG as to how many blocks actually are abandoned down in the legacy
>> pools.
>
> I've sent the number of blocks reclaimed, but do not believe that we
> will be able to easily generate statistics about the length of time
> registered prior to reclamation (i.e. it may require manual collation
> to generate.) ?I will look into it.

Hi John,

If you have an ability to publish the whois records as they existed
when the blocks were reclaimed, they should have the information. If
your database has an audit trail then they should still be there with
the addition of a deletion date.

Regards,
Bill Herrin


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


From jcurran at arin.net  Wed Nov 10 18:29:27 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 10 Nov 2010 18:29:27 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <AANLkTik_KO1gu0HAXHQPnxwySEQUn_y4ZwA+NbSFTyAG@mail.gmail.com>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
	<AANLkTi=Pc76hCjG82OG+X4Ag622kNauiKCpn73FCMHE+@mail.gmail.com>
	<BA70292E-3CB4-47EE-932A-683F284B2222@arin.net>
	<AANLkTik_KO1gu0HAXHQPnxwySEQUn_y4ZwA+NbSFTyAG@mail.gmail.com>
Message-ID: <8703BDB7-E417-4625-8240-5E944991F378@arin.net>

On Nov 10, 2010, at 5:46 PM, William Herrin wrote:
> On Wed, Nov 10, 2010 at 3:55 PM, John Curran <jcurran at arin.net> wrote:
>> On Nov 10, 2010, at 2:10 PM, William Herrin wrote:
>>> It occurred to me that would be the more interesting number for this
>>> discussion. How many blocks, not total size, and only the ones
>>> reclaimed for non-payment. I'd also like to see the minimum, median
>>> and maximum length of time that the blocks were registered before
>>> reclamation. With those numbers it should be possible to make a decent
>>> SWAG as to how many blocks actually are abandoned down in the legacy
>>> pools.
>> 
>> I've sent the number of blocks reclaimed, but do not believe that we
>> will be able to easily generate statistics about the length of time
>> registered prior to reclamation (i.e. it may require manual collation
>> to generate.)  I will look into it.
> 
> Hi John,
> 
> If you have an ability to publish the whois records as they existed
> when the blocks were reclaimed, they should have the information. If
> your database has an audit trail then they should still be there with
> the addition of a deletion date.

Bill - 
 
  I'm certain it is possible to generate, the question is level of effort
  to produce it (which I'll need to research in order to respond usefully)

  Note that those organizations that have signed LRSA's or RSA's and did
  pay for some period of time may not be at all similar to those who hold   
  legacy resources and have never entered into any agreement with ARIN. 
  For example, ARIN's accounts receivable practices have changed over 
  time, and there are surges in number of revocations and the apparent 
  "duration of resource use" in some years that can be attributed as a 
  result.  Those legacy holders who never entered into any agreement 
  with ARIN are unlikely to care about our billing practices, and their
  "abandonment" of a resource is more likely to be driven by particular 
  circumstances as opposed to ARIN reminding them of an overdue bill for 
  registration service fees.

/John

John Curran
President and CEO
ARIN


From jcurran at arin.net  Thu Nov 11 20:38:49 2010
From: jcurran at arin.net (John Curran)
Date: Thu, 11 Nov 2010 20:38:49 -0500
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
 120: Protecting Number Resources
In-Reply-To: <8703BDB7-E417-4625-8240-5E944991F378@arin.net>
References: <4CD55B73.9030104@arin.net>
	<20101109155001.GA34127@ussenterprise.ufp.org>
	<95CC7BD3-BE97-4725-A240-E68B62B1B9EB@arin.net>
	<AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
	<AANLkTi=Pc76hCjG82OG+X4Ag622kNauiKCpn73FCMHE+@mail.gmail.com>
	<BA70292E-3CB4-47EE-932A-683F284B2222@arin.net>
	<AANLkTik_KO1gu0HAXHQPnxwySEQUn_y4ZwA+NbSFTyAG@mail.gmail.com>
	<8703BDB7-E417-4625-8240-5E944991F378@arin.net>
Message-ID: <6C9C5FB8-9742-4609-8435-26CBB3A8D7DF@arin.net>

On Wed, Nov 10, 2010 at 3:55 PM, John Curran <jcurran at arin.net> wrote:
> On Nov 10, 2010, at 2:10 PM, William Herrin wrote:
>> It occurred to me that would be the more interesting number for this
>> discussion. How many blocks, not total size, and only the ones
>> reclaimed for non-payment. I'd also like to see the minimum, median
>> and maximum length of time that the blocks were registered before
>> reclamation. With those numbers it should be possible to make a decent
>> SWAG as to how many blocks actually are abandoned down in the legacy
>> pools.
> 
> I've sent the number of blocks reclaimed, but do not believe that we
> will be able to easily generate statistics about the length of time
> registered prior to reclamation (i.e. it may require manual collation
> to generate.)  I will look into it.

The minimum length of time from registration to revocation was a day and a
half.  

The median length of time from registration to revocation is 5 years, 225
days.

The mean length of time from registration to revocation is 6 years 192 days.

The maximum length of time from registration to revocation is 23 years 104
days (a legacy registration that came under RSA due to a transfer.)

The maximum length of time from registration to revocation for a non-legacy
block is 11 years, 187 days.

Hope this is helpful!
/John

John Curran
President and CEO
ARIN




From bicknell at ufp.org  Thu Nov 11 20:42:50 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 11 Nov 2010 17:42:50 -0800
Subject: [arin-ppml] REQUEST FOR ARIN STAFF Was: Re: Policy Proposal
	120: Protecting Number Resources
In-Reply-To: <6C9C5FB8-9742-4609-8435-26CBB3A8D7DF@arin.net>
References: <AANLkTinjWaPTaguF0TN1W8M5TsrjV=f-20bnuiidbmcT@mail.gmail.com>
	<24D87934-0379-4814-9A68-AC39BECF18A8@arin.net>
	<473D6290-F741-407D-8F6A-8E944E181FA0@delong.com>
	<4CD9CBAF.90901@sprunk.org>
	<20101109232911.GA65697@ussenterprise.ufp.org>
	<AANLkTi=Pc76hCjG82OG+X4Ag622kNauiKCpn73FCMHE+@mail.gmail.com>
	<BA70292E-3CB4-47EE-932A-683F284B2222@arin.net>
	<AANLkTik_KO1gu0HAXHQPnxwySEQUn_y4ZwA+NbSFTyAG@mail.gmail.com>
	<8703BDB7-E417-4625-8240-5E944991F378@arin.net>
	<6C9C5FB8-9742-4609-8435-26CBB3A8D7DF@arin.net>
Message-ID: <20101112014250.GB97649@ussenterprise.ufp.org>

In a message written on Thu, Nov 11, 2010 at 08:38:49PM -0500, John Curran wrote:
> The minimum length of time from registration to revocation was a day and a
> half.  
> 
> The median length of time from registration to revocation is 5 years, 225
> days.
> 
> The mean length of time from registration to revocation is 6 years 192 days.
> 
> The maximum length of time from registration to revocation is 23 years 104
> days (a legacy registration that came under RSA due to a transfer.)
> 
> The maximum length of time from registration to revocation for a non-legacy
> block is 11 years, 187 days.
> 
> Hope this is helpful!

I'm honestly not sure what to make of all that just yet, but in
terms of interesting statistics this is the most interesting set
I've seen from any ARIN policy in a LONG time. :)

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101111/c6b48b95/attachment.sig>

From owen at delong.com  Tue Nov 16 09:09:53 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 16 Nov 2010 06:09:53 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
References: <5669F273-ED2B-46E3-86F7-9E35E095C37A@delong.com>
Message-ID: <C30FB896-BD7C-4BB1-BD23-D08B06C8ACD7@delong.com>

 Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
   1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs
   2. Proposal Originators
         1. name: Owen DeLong
         2. e-mail: owen at delong.com
         3. telephone: 408-890-7992
         4. organization: Hurricane Electric
         1. name: David Farmer
         2. e-mail: farmer at umn.edu
         3. telephone: 612-812-9952
         4. organization: University of Minnesota
         1. name: Andrew Dul
         2. e-mail: andrew.dul at quark.net
         3. telephone: 206-395-4004
         4. organization: Cascadeo Corp.
         1. name: Chris Grundemann
         2. e-mail: christopher.grundemann at twtelecom.com
         3. telephone: 303.542.6524
         4. organization: TW Telecom
   3. Proposal Version: 0.8
   4. Date: 16 November, 2010
   5. Proposal type: M
   6. Policy term: Permanent
   7. Policy statement:
Amend section 2 as follows:
Delete section 2.9 (Obsolete)
Replace section 2.10 with the following:
	2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location).
Add the following:
	2.12 The term serving site shall mean a location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or local combinations thereof.
	2.13 The term provider assignment unit shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48).
	2.14 The term utilized shall have the following definitions:
		(i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site.
		(ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization)

Replace sections 6.5.1 through 6.5.3 with the following:
6.5.1	Terminology
	(a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings.
	(b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (a number X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.)
6.5.2	Initial Allocations to LIRs
	6.5.2.1	Size
	(a)	All allocations shall be made on nibble boundaries.
	(b)	In no case shall an LIR receive smaller than a /32 unless they specifically request a /36.
	(c)	The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses.

		This calculation can be summarized as /N where N = 48-(X+Y) and X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site.

	(d)	For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy.
	(e)	For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR.
	(f)	An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled.
	6.5.2.2	Qualifications
	An organization qualifies for an allocation under this policy if they meet any of the following criteria:
	(a)	Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria.
	(b)	Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number.
	(c)	Provide ARIN a reasonable technical justification, indicating why an allocation is necessary, including the intended purposes for the allocation, and describing the network infrastructure the allocation will be used to support. Justification must include a plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.
6.5.3	Subsequent Allocations to LIRs
	(a)	Where possible ARIN will make subsequent allocations by expanding the existing allocation.
	(b)	An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be entitled to a subsequent allocation.
	(c)	If ARIN can not expand one or more existing allocations, ARIN shall make a new allocation based on the initial allocation criteria above. The LIR is encouraged, but not required to renumber into the new allocation over time and return any allocations no longer in use.
Replace section 6.5.4 with the following
6.5.4 	Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply.
Add the following to 6.5.7
LIRs which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, ARIN will simply expand their existing allocation rather than requiring renumber and return.

   8. Rationale:
The current ISP policy for IPv6 allocations is both short-sighted and insufficient for rational deployments by most ISPs. We have gained significant operational experience with IPv6 in the time since it was written and it is clear that current policy is driving many ISPs to choices of excess conservatism that will eventually harm innovation in the consumer space.
Under the proposed policy, the entirety of the ARIN region can still be numbered in no more than 2 /12s (quite probably 1). There are still 506 /12s free within the current /3. It is unreasonable to shoot ourselves in the foot with address scarcity thinking so early into the IPv6 deployment. This policy seeks to strike a more reasonable and harmonious balance of the goals stated in NRPM 6.3.
The lower bound of /36 is intended to facilitate extremely small ISPs getting a smaller block if they do not need to support more than ~4000 customers. It is hoped that the board will take subsequent action to adjust the fee structure to eliminate the $1,000/year price hike for those extremely small ISPs. These ISPs can, of course, get a /32 if they wish.
The intent of section 6.5.4 is to create and preserve parity between the requirements for LIR->End User and ARIN->End User policies. This section presumes that 6.5.8 has already been modified as described in draft policy 2010-8.
Some examples of determining the size of block for which an organization is eligible:
Bill's Bait, Sushi, and IP Transit:
	Largest serving site:		200 end sites
	Number of serving sites:	5
	200 rounds up to 256 (nibble boundary, 8 bits). 200 > 192 (256 * 0.75), so, round up to 4096 (12 bits)
	5 rounds up to 16 (nibble boundary, 4 bits). 5 < 12 (16 * 0.75), so, no further round up. 16 (4 bits)
	48 - (12+4) = 32 -- This organization could receive up to a /32.
Lee's Rural Internet, Inc.
	Largest serving site:		1024 end sites
	Number of serving sites:	30
	1024 rounds up to 4096 (nibble boundary, 12 bits) 1024 < 3072 (4096 * 0.75), so 4096 (12 bits)
	30 rounds up to 256 (nibble boundary, 8 bits). 30 < 192 (256 * 0.75), so, 256 (8 bits)
	48 - (12+8) = 28 -- This organization could receive up to a /28.
Paul's Mega Metro ISP, LLC
	Largest serving site:		3,500 end sites
	Number of serving sites:	140
	3,500 rounds up to 4096 (nibble boundary, 12 bits). 3500 > 3072 (4096 * 0.75), so, round up to 65,536 (16 bits)
	140 rounds up to 256 (nibble boundary, 8 bits) 140 < 192 (256 * 0.75), so, 256 (8 bits)
	48 - (16+8) = 24 -- This organization could receive up to a /24
PON's CMTS mega DSL Corp.
	Largest serving site:		30,000 end sites
	Number of serving sites:	700
	30,000 rounds up to 65,536 (nibble boundary, 16 bits). 30,000 < 49,152 (65536 * 0.75), so, 65,536 (16 bits)
	700 rounds up to 4,096 (nibble boundary, 12 bits). 700 < 3072 (4096 * 0.75), so, 4,096 (12 bits)
	48 - (16+12) = 20 -- This organization could receive up to a /20.
Sizing table:
Units		Round-up	Bits
0-11		16		4
13-191		256		8
192-3,071	4,096		12
3,072-49,151	65,536		16
49,152-786,431	1,048,576	20
   9. Timetable for implementation: Immediate
END OF TEMPLATE 







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101116/70b4cb85/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IPv6 Allocation Sizer.xls
Type: application/vnd.ms-excel
Size: 17408 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101116/70b4cb85/attachment.xls>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101116/70b4cb85/attachment-0001.htm>

From charles at office.tcsn.net  Tue Nov 16 15:07:29 2010
From: charles at office.tcsn.net (Charles O'Hern)
Date: Tue, 16 Nov 2010 12:07:29 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
In-Reply-To: <C30FB896-BD7C-4BB1-BD23-D08B06C8ACD7@delong.com>
References: <5669F273-ED2B-46E3-86F7-9E35E095C37A@delong.com>
	<C30FB896-BD7C-4BB1-BD23-D08B06C8ACD7@delong.com>
Message-ID: <4CE2E481.8030809@office.tcsn.net>

I'd like to thank these gentlemen for including love for the x-small ISPs out there.  We love you guys.

Question, section 6.5.2.1 (d) dealing with End Sites larger than /48, says "(they shall) count as the appropriate number of /48s that would be assigned under that policy." is that
number to be counted towards the total number of End Sites that is then rounded up to the next nibble boundary?  Or should the End Site assignment be on the nibble boundary (16
/48's, 256 /48's, etc.) before adding to the total number of end sites per serving site?

Some minor language suggestions included inline below.  No change in meaning is intended.  The only intention is to make meaning more clear and language more precise.  Please let
me know publicly if my suggestions imply that I'm misunderstanding your meaning.  I noted my edits with pound (#) signs, hopefully facilitating visibility.

On 11/16/10 6:09 AM, Owen DeLong wrote:
>  Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
> 
>    1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs
>    2. Proposal Originators
> 
>          1. name: Owen DeLong
>          2. e-mail: owen at delong.com <mailto:owen at delong.com>
>          3. telephone: 408-890-7992
>          4. organization: Hurricane Electric
> 
>          1. name: David Farmer
>          2. e-mail: farmer at umn.edu <mailto:farmer at umn.edu>
>          3. telephone: 612-812-9952
>          4. organization: University of Minnesota
> 
>          1. name: Andrew Dul
>          2. e-mail: andrew.dul at quark.net <mailto:andrew.dul at quark.net>
>          3. telephone: 206-395-4004
>          4. organization: Cascadeo Corp.
> 
>          1. name: Chris Grundemann
>          2. e-mail: christopher.grundemann at twtelecom.com <mailto:christopher.grundemann at twtelecom.com>
>          3. telephone: 303.542.6524
>          4. organization: TW Telecom
> 
>    3. Proposal Version: 0.8
> 
>    4. Date: 16 November, 2010
>    5. Proposal type: M
>    6. Policy term: Permanent
>    7. Policy statement:
> 
> Amend section 2 as follows:
> 
> Delete section 2.9 (Obsolete)
> 
> Replace section 2.10 with the following:
> 
> 	2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location).
> 
> Add the following:
> 
> 	2.12 The term serving site shall mean a location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or local combinations thereof.
> 
> 	2.13 The term provider assignment unit shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48).
> 
> 	2.14 The term utilized shall have the following definitions:
> 
> 		(i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site.
> 
> 		(ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned ###from the containing block### by the total number of provider assignment units _contained in the larger block_. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization)
> 
> 
> Replace sections 6.5.1 through 6.5.3 with the following:
> 
> 6.5.1	Terminology
> 
> 	(a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings.
> 
> 	(b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (###in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities### of X such that 2^n=X , such as 16, 256, 4096, etc.)
> 
> 6.5.2	Initial Allocations to LIRs
> 
> 	6.5.2.1	Size
> 
> 	(a)	All allocations shall be made on nibble boundaries.
> 
> 	(b)	In no case shall an LIR receive smaller than a /32 unless they specifically request a /36.
> 
> 	(c)	The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses.
> 
> 		This calculation can be summarized as /N where N = 48-(X+Y) and X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site.
> 
> 	(d)	For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy.
> 
> 	(e)	For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR.
> 
> 	(f)	An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled.
> 
> 	6.5.2.2	Qualifications
> 
> 	An organization qualifies for an allocation under this policy if they meet any of the following criteria:
> 
> 	(a)	Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria.
> 
> 	(b)	Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number.
> 
> 	(c)	Provide ARIN a reasonable technical justification, indicating why an allocation is necessary, including the intended purposes for the allocation, and describing the network infrastructure the allocation will be used to support. Justification must include a plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.
> 
> 6.5.3	Subsequent Allocations to LIRs
> 
> 	(a)	Where possible ARIN will make subsequent allocations by expanding the existing allocation.
> 
> 	(b)	An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be entitled to a subsequent allocation.
> 
> 	(c)	If ARIN can not expand one or more existing allocations, ARIN shall make a new allocation based on the initial allocation criteria above. The LIR is encouraged, but not required to renumber into the new allocation over time and return any allocations no longer in use.
> 
> Replace section 6.5.4 with the following
> 
> 6.5.4 	Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply.
> 
> Add the following to 6.5.7
> 
> LIRs which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, ARIN will simply expand their existing allocation rather than requiring renumber and return.
> 
>    8. Rationale:
> 
> The current ISP policy for IPv6 allocations is both short-sighted and insufficient for rational deployments by most ISPs. We have gained significant operational experience with IPv6 in the time since it was written and it is clear that current policy is driving many ISPs to choices of excess conservatism that will eventually harm innovation in the consumer space.
> 
> Under the proposed policy, the entirety of the ARIN region can still be numbered in no more than 2 /12s (quite probably 1). There are still 506 /12s free within the current /3. It is unreasonable to shoot ourselves in the foot with address scarcity thinking so early into the IPv6 deployment. This policy seeks to strike a more reasonable and harmonious balance of the goals stated in NRPM 6.3.
> 
> The lower bound of /36 is intended to facilitate extremely small ISPs getting a smaller block if they do not need to support more than ~4000 customers. It is hoped that the board will take subsequent action to adjust the fee structure to eliminate the $1,000/year price hike for those extremely small ISPs. These ISPs can, of course, get a /32 if they wish.
> 
> The intent of section 6.5.4 is to create and preserve parity between the requirements for LIR->End User and ARIN->End User policies. This section presumes that 6.5.8 has already been modified as described in draft policy 2010-8.
> 
> Some examples of determining the size of block for which an organization is eligible:
> 
> Bill's Bait, Sushi, and IP Transit:
> 
> 	Largest serving site:		200 end sites
> 
> 	Number of serving sites:	5
> 
> 	200 rounds up to 256 (nibble boundary, 8 bits). 200 > 192 (256 * 0.75), so, round up to 4096 (12 bits)
> 
> 	5 rounds up to 16 (nibble boundary, 4 bits). 5 < 12 (16 * 0.75), so, no further round up. 16 (4 bits)
> 
> 	48 - (12+4) = 32 -- This organization could receive up to a /32.
> 
> Lee's Rural Internet, Inc.
> 
> 	Largest serving site:		1024 end sites
> 
> 	Number of serving sites:	30
> 
> 	1024 rounds up to 4096 (nibble boundary, 12 bits) 1024 < 3072 (4096 * 0.75), so 4096 (12 bits)
> 
> 	30 rounds up to 256 (nibble boundary, 8 bits). 30 < 192 (256 * 0.75), so, 256 (8 bits)
> 
> 	48 - (12+8) = 28 -- This organization could receive up to a /28.
> 
> Paul's Mega Metro ISP, LLC
> 
> 	Largest serving site:		3,500 end sites
> 
> 	Number of serving sites:	140
> 
> 	3,500 rounds up to 4096 (nibble boundary, 12 bits). 3500 > 3072 (4096 * 0.75), so, round up to 65,536 (16 bits)
> 
> 	140 rounds up to 256 (nibble boundary, 8 bits) 140 < 192 (256 * 0.75), so, 256 (8 bits)
> 
> 	48 - (16+8) = 24 -- This organization could receive up to a /24
> 
> PON's CMTS mega DSL Corp.
> 
> 	Largest serving site:		30,000 end sites
> 
> 	Number of serving sites:	700
> 
> 	30,000 rounds up to 65,536 (nibble boundary, 16 bits). 30,000 < 49,152 (65536 * 0.75), so, 65,536 (16 bits)
> 
> 	700 rounds up to 4,096 (nibble boundary, 12 bits). 700 < 3072 (4096 * 0.75), so, 4,096 (12 bits)
> 
> 	48 - (16+12) = 20 -- This organization could receive up to a /20.
> 
> Sizing table:
> 
> Units		Round-up	Bits
> 
> 0-11		16		4
> 
> 13-191		256		8
> 
> 192-3,071	4,096		12
> 
> 3,072-49,151	65,536		16
> 
> 49,152-786,431	1,048,576	20
> 
>    9. Timetable for implementation: Immediate
> 
> END OF TEMPLATE 
> 
> 
> 
> 
> 
> 
> =
> 
> 
> 
> 
> 
> _______________________________________________
> 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.


-- 
Charles O'Hern
Network Operations

TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net


From owen at delong.com  Tue Nov 16 15:38:15 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 16 Nov 2010 12:38:15 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
In-Reply-To: <4CE2E481.8030809@office.tcsn.net>
References: <5669F273-ED2B-46E3-86F7-9E35E095C37A@delong.com>
	<C30FB896-BD7C-4BB1-BD23-D08B06C8ACD7@delong.com>
	<4CE2E481.8030809@office.tcsn.net>
Message-ID: <44F64F8C-339D-4155-98A1-2B1B498977DE@delong.com>


On Nov 16, 2010, at 12:07 PM, Charles O'Hern wrote:

> I'd like to thank these gentlemen for including love for the x-small ISPs out there.  We love you guys.
> 
> Question, section 6.5.2.1 (d) dealing with End Sites larger than /48, says "(they shall) count as the appropriate number of /48s that would be assigned under that policy." is that
> number to be counted towards the total number of End Sites that is then rounded up to the next nibble boundary?  Or should the End Site assignment be on the nibble boundary (16
> /48's, 256 /48's, etc.) before adding to the total number of end sites per serving site?
> 
Assuming that 2010-8 is adopted as is, the end site would receive a nibble boundary assignment and that nibble
boundary would be counted for purposes of this policy. If, for example, such an end site received a /44, then, under
this policy they would count as 16 /48s fully utilized.

> Some minor language suggestions included inline below.  No change in meaning is intended.  The only intention is to make meaning more clear and language more precise.  Please let
> me know publicly if my suggestions imply that I'm misunderstanding your meaning.  I noted my edits with pound (#) signs, hopefully facilitating visibility.
> 
Thanks... Comments inline.

> On 11/16/10 6:09 AM, Owen DeLong wrote:
>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
>> 
>>   1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs
>>   2. Proposal Originators
>> 
>>         1. name: Owen DeLong
>>         2. e-mail: owen at delong.com <mailto:owen at delong.com>
>>         3. telephone: 408-890-7992
>>         4. organization: Hurricane Electric
>> 
>>         1. name: David Farmer
>>         2. e-mail: farmer at umn.edu <mailto:farmer at umn.edu>
>>         3. telephone: 612-812-9952
>>         4. organization: University of Minnesota
>> 
>>         1. name: Andrew Dul
>>         2. e-mail: andrew.dul at quark.net <mailto:andrew.dul at quark.net>
>>         3. telephone: 206-395-4004
>>         4. organization: Cascadeo Corp.
>> 
>>         1. name: Chris Grundemann
>>         2. e-mail: christopher.grundemann at twtelecom.com <mailto:christopher.grundemann at twtelecom.com>
>>         3. telephone: 303.542.6524
>>         4. organization: TW Telecom
>> 
>>   3. Proposal Version: 0.8
>> 
>>   4. Date: 16 November, 2010
>>   5. Proposal type: M
>>   6. Policy term: Permanent
>>   7. Policy statement:
>> 
>> Amend section 2 as follows:
>> 
>> Delete section 2.9 (Obsolete)
>> 
>> Replace section 2.10 with the following:
>> 
>> 	2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location).
>> 
>> Add the following:
>> 
>> 	2.12 The term serving site shall mean a location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or local combinations thereof.
>> 
>> 	2.13 The term provider assignment unit shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48).
>> 
>> 	2.14 The term utilized shall have the following definitions:
>> 
>> 		(i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site.
>> 
>> 		(ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned ###from the containing block### by the total number of provider assignment units _contained in the larger block_. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization)

OK... I'll incorporate that one in the next revision.

>> 
>> 
>> Replace sections 6.5.1 through 6.5.3 with the following:
>> 
>> 6.5.1	Terminology
>> 
>> 	(a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings.
>> 
>> 	(b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (###in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities### of X such that 2^n=X , such as 16, 256, 4096, etc.)

OK... I like this one to... I will incorporate it.
<snip>
(There weren't any changes suggested beyond this point).

Owen



From jbates at brightok.net  Tue Nov 16 15:50:09 2010
From: jbates at brightok.net (Jack Bates)
Date: Tue, 16 Nov 2010 14:50:09 -0600
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
In-Reply-To: <4CE2E481.8030809@office.tcsn.net>
References: <5669F273-ED2B-46E3-86F7-9E35E095C37A@delong.com>	<C30FB896-BD7C-4BB1-BD23-D08B06C8ACD7@delong.com>
	<4CE2E481.8030809@office.tcsn.net>
Message-ID: <4CE2EE81.9000209@brightok.net>

On 11/16/2010 2:07 PM, Charles O'Hern wrote:
> I'd like to thank these gentlemen for including love for the x-small ISPs out there.  We love you guys.

+1

I believe it is clear and removes many areas of ARINs conservative 
interpretations. It provides a proper justification for IPv6 for initial 
allocation without an IPv4 dependency, supports nibble alignments, 
future planning, and sub-delegated ISP space. It keeps initial 
allocations aligned with the same procedure as subsequent allocations. 
It stops provider assignment crunch which doesn't support growth. 
Finally, it gives providers a set of allocation/assignment rules which 
are aligned exactly with what ARIN will use (with a liberal enough 
allocation framework, that differing from the policy mechanisms is 
possible so long as it's within the space justified by the mechanism).


Jack


From rcarpen at network1.net  Tue Nov 16 16:03:17 2010
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 16 Nov 2010 16:03:17 -0500 (EST)
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
In-Reply-To: <44F64F8C-339D-4155-98A1-2B1B498977DE@delong.com>
Message-ID: <532350503.18268.1289941397374.JavaMail.root@zimbra.network1.net>


I think this is a great idea. One thing that concerns me is that the fee structure is going to make it so that IPv6 done in this fashion is going to be very much more expensive. Handing out larger blocks to the same number of LIRs shouldn't have any higher cost to ARIN. If we define all allocations at nibble boundaries, then the fees should be done similarly:

x-small = /36
small = /32
medium = /28
large = /24
x-large = /20
xx-large = /16 and larger

For the LIRs that I deal with, which would be mostly x-small to medium these fees would line up pretty exactly with their IPv4 fees currently.

One other concern is how do we handle non-nibble-boundary allocations that are already out there? Allow them to be returned for a new block?

-Randy

--
| Randy Carpenter
| Vice President, IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (419)739-9240, x1
----

----- Original Message -----
> On Nov 16, 2010, at 12:07 PM, Charles O'Hern wrote:
> 
> > I'd like to thank these gentlemen for including love for the x-small
> > ISPs out there. We love you guys.
> >
> > Question, section 6.5.2.1 (d) dealing with End Sites larger than
> > /48, says "(they shall) count as the appropriate number of /48s that
> > would be assigned under that policy." is that
> > number to be counted towards the total number of End Sites that is
> > then rounded up to the next nibble boundary? Or should the End Site
> > assignment be on the nibble boundary (16
> > /48's, 256 /48's, etc.) before adding to the total number of end
> > sites per serving site?
> >
> Assuming that 2010-8 is adopted as is, the end site would receive a
> nibble boundary assignment and that nibble
> boundary would be counted for purposes of this policy. If, for
> example, such an end site received a /44, then, under
> this policy they would count as 16 /48s fully utilized.
> 
> > Some minor language suggestions included inline below. No change in
> > meaning is intended. The only intention is to make meaning more
> > clear and language more precise. Please let
> > me know publicly if my suggestions imply that I'm misunderstanding
> > your meaning. I noted my edits with pound (#) signs, hopefully
> > facilitating visibility.
> >
> Thanks... Comments inline.
> 
> > On 11/16/10 6:09 AM, Owen DeLong wrote:
> >> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
> >>
> >>   1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs
> >>   2. Proposal Originators
> >>
> >>         1. name: Owen DeLong
> >>         2. e-mail: owen at delong.com <mailto:owen at delong.com>
> >>         3. telephone: 408-890-7992
> >>         4. organization: Hurricane Electric
> >>
> >>         1. name: David Farmer
> >>         2. e-mail: farmer at umn.edu <mailto:farmer at umn.edu>
> >>         3. telephone: 612-812-9952
> >>         4. organization: University of Minnesota
> >>
> >>         1. name: Andrew Dul
> >>         2. e-mail: andrew.dul at quark.net
> >>         <mailto:andrew.dul at quark.net>
> >>         3. telephone: 206-395-4004
> >>         4. organization: Cascadeo Corp.
> >>
> >>         1. name: Chris Grundemann
> >>         2. e-mail: christopher.grundemann at twtelecom.com
> >>         <mailto:christopher.grundemann at twtelecom.com>
> >>         3. telephone: 303.542.6524
> >>         4. organization: TW Telecom
> >>
> >>   3. Proposal Version: 0.8
> >>
> >>   4. Date: 16 November, 2010
> >>   5. Proposal type: M
> >>   6. Policy term: Permanent
> >>   7. Policy statement:
> >>
> >> Amend section 2 as follows:
> >>
> >> Delete section 2.9 (Obsolete)
> >>
> >> Replace section 2.10 with the following:
> >>
> >> 	2.10 The term End Site shall mean a single structure or service
> >> 	delivery address, or, in the case of a multi-tenant structure, a
> >> 	single tenant within said structure (a single customer location).
> >>
> >> Add the following:
> >>
> >> 	2.12 The term serving site shall mean a location where an ISP
> >> 	terminates or aggregates customer connections, including, but, not
> >> 	limited to Points of Presence (POPs), Datacenters, Central or
> >> 	Local switching office or regional or local combinations thereof.
> >>
> >> 	2.13 The term provider assignment unit shall mean the prefix of
> >> 	the smallest block a given ISP assigns to end sites (recommended
> >> 	/48).
> >>
> >> 	2.14 The term utilized shall have the following definitions:
> >>
> >> 		(i) A provider assignment unit shall be considered fully utilized
> >> 		when it is assigned to an end-site.
> >>
> >> 		(ii) Larger blocks shall have their utilization defined by
> >> 		dividing the number of provider assignment units assigned ###from
> >> 		the containing block### by the total number of provider
> >> 		assignment units _contained in the larger block_. This ratio will
> >> 		often be expressed as a percentage (e.g. a/t*100, for a /36
> >> 		3072/4096 * 100 = 75% utilization)
> 
> OK... I'll incorporate that one in the next revision.
> 
> >>
> >>
> >> Replace sections 6.5.1 through 6.5.3 with the following:
> >>
> >> 6.5.1 Terminology
> >>
> >> 	(a) The terms ISP and LIR are used interchangeably in this
> >> 	document and any use of either term shall be construed to include
> >> 	both meanings.
> >>
> >> 	(b) The term nibble boundary shall mean a network mask which
> >> 	aligns on a 4-bit boundary (###in slash notation, /n, where n is
> >> 	evenly divisible by 4, allowing unit quantities### of X such that
> >> 	2^n=X , such as 16, 256, 4096, etc.)
> 
> OK... I like this one to... I will incorporate it.
> <snip>
> (There weren't any changes suggested beyond this point).
> 
> Owen
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From jbates at brightok.net  Tue Nov 16 16:41:12 2010
From: jbates at brightok.net (Jack Bates)
Date: Tue, 16 Nov 2010 15:41:12 -0600
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
In-Reply-To: <532350503.18268.1289941397374.JavaMail.root@zimbra.network1.net>
References: <532350503.18268.1289941397374.JavaMail.root@zimbra.network1.net>
Message-ID: <4CE2FA78.70804@brightok.net>


On 11/16/2010 3:03 PM, Randy Carpenter wrote:
>
> I think this is a great idea. One thing that concerns me is that the fee structure is going to make it so that IPv6 done in this fashion is going to be very much more expensive. Handing out larger blocks to the same number of LIRs shouldn't have any higher cost to ARIN. If we define all allocations at nibble boundaries, then the fees should be done similarly:
>

This would definitely be a concern. As it is, a medium in IPv4 can 
easily find themselves as a Large in v6. What gets me is why an XX-Large 
was added.

> One other concern is how do we handle non-nibble-boundary allocations that are already out there? Allow them to be returned for a new block?
>

The policy change handled that, allowing for a renumber.


Jack


From charles at office.tcsn.net  Tue Nov 16 17:10:15 2010
From: charles at office.tcsn.net (Charles O'Hern)
Date: Tue, 16 Nov 2010 14:10:15 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
In-Reply-To: <44F64F8C-339D-4155-98A1-2B1B498977DE@delong.com>
References: <5669F273-ED2B-46E3-86F7-9E35E095C37A@delong.com>
	<C30FB896-BD7C-4BB1-BD23-D08B06C8ACD7@delong.com>
	<4CE2E481.8030809@office.tcsn.net>
	<44F64F8C-339D-4155-98A1-2B1B498977DE@delong.com>
Message-ID: <4CE30147.6020902@office.tcsn.net>

On 11/16/10 12:38 PM, Owen DeLong wrote:
> 
> On Nov 16, 2010, at 12:07 PM, Charles O'Hern wrote:
> 
>> I'd like to thank these gentlemen for including love for the x-small ISPs out there.  We love you guys.
>>
>> Question, section 6.5.2.1 (d) dealing with End Sites larger than /48, says "(they shall) count as the appropriate number of /48s that would be assigned under that policy." is that
>> number to be counted towards the total number of End Sites that is then rounded up to the next nibble boundary?  Or should the End Site assignment be on the nibble boundary (16
>> /48's, 256 /48's, etc.) before adding to the total number of end sites per serving site?
>>
> Assuming that 2010-8 is adopted as is, the end site would receive a nibble boundary assignment and that nibble
> boundary would be counted for purposes of this policy. If, for example, such an end site received a /44, then, under
> this policy they would count as 16 /48s fully utilized.

Because 6.5.8 doesn't seem to mention assignment on nibble boundaries (though I could have missed it), perhaps:
(d)	For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the least multiple of 4
that can contain the size of the assignment under that policy.

>> Some minor language suggestions included inline below.  No change in meaning is intended.  The only intention is to make meaning more clear and language more precise.  Please let
>> me know publicly if my suggestions imply that I'm misunderstanding your meaning.  I noted my edits with pound (#) signs, hopefully facilitating visibility.
>>
> Thanks... Comments inline.
> 
<snip>
> (There weren't any changes suggested beyond this point).

apologies, I should have snipped at that point myself and save you from having to scan for further edits.

> Owen
> 


-- 
Charles O'Hern
Network Operations

TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net


From owen at delong.com  Tue Nov 16 18:20:48 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 16 Nov 2010 15:20:48 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
In-Reply-To: <532350503.18268.1289941397374.JavaMail.root@zimbra.network1.net>
References: <532350503.18268.1289941397374.JavaMail.root@zimbra.network1.net>
Message-ID: <B80D0C4C-C6BD-40C4-A507-089959150C04@delong.com>


On Nov 16, 2010, at 1:03 PM, Randy Carpenter wrote:

> 
> I think this is a great idea. One thing that concerns me is that the fee structure is going to make it so that IPv6 done in this fashion is going to be very much more expensive. Handing out larger blocks to the same number of LIRs shouldn't have any higher cost to ARIN. If we define all allocations at nibble boundaries, then the fees should be done similarly:
> 
I agree and will encourage the BoT to consider this. However, fee structure is out of scope for policy discussions,
so, I did not include it in the policy proposal.

> x-small = /36
> small = /32
> medium = /28
> large = /24
> x-large = /20
> xx-large = /16 and larger
> 
This seems reasonable to me as well. However, any discussion of modifying the fee structure properly belongs
on the members list (arin-discuss).

> For the LIRs that I deal with, which would be mostly x-small to medium these fees would line up pretty exactly with their IPv4 fees currently.
> 
One thing to keep in mind is that even if the BoT does not change the fees, this policy only specifies the maximum
allocation you can obtain. You can choose to use something smaller to reduce your fees if that is useful in your
situation. I'm not encouraging that, just saying it is possible.

> One other concern is how do we handle non-nibble-boundary allocations that are already out there? Allow them to be returned for a new block?
> 
I believe this is covered in the policy proposal under the subsequent allocation clause. Basically, any LIR that had
a non-nibble-aligned block would have justification for a conforming subsequent allocation either by expanding
their current prefix or by receiving a new prefix. While it is not explicitly stated as a special case in the policy, I
believe it can be handled as the general case of subsequent allocation.

Owen

> -Randy
> 
> --
> | Randy Carpenter
> | Vice President, IT Services
> | Red Hat Certified Engineer
> | First Network Group, Inc.
> | (419)739-9240, x1
> ----
> 
> ----- Original Message -----
>> On Nov 16, 2010, at 12:07 PM, Charles O'Hern wrote:
>> 
>>> I'd like to thank these gentlemen for including love for the x-small
>>> ISPs out there. We love you guys.
>>> 
>>> Question, section 6.5.2.1 (d) dealing with End Sites larger than
>>> /48, says "(they shall) count as the appropriate number of /48s that
>>> would be assigned under that policy." is that
>>> number to be counted towards the total number of End Sites that is
>>> then rounded up to the next nibble boundary? Or should the End Site
>>> assignment be on the nibble boundary (16
>>> /48's, 256 /48's, etc.) before adding to the total number of end
>>> sites per serving site?
>>> 
>> Assuming that 2010-8 is adopted as is, the end site would receive a
>> nibble boundary assignment and that nibble
>> boundary would be counted for purposes of this policy. If, for
>> example, such an end site received a /44, then, under
>> this policy they would count as 16 /48s fully utilized.
>> 
>>> Some minor language suggestions included inline below. No change in
>>> meaning is intended. The only intention is to make meaning more
>>> clear and language more precise. Please let
>>> me know publicly if my suggestions imply that I'm misunderstanding
>>> your meaning. I noted my edits with pound (#) signs, hopefully
>>> facilitating visibility.
>>> 
>> Thanks... Comments inline.
>> 
>>> On 11/16/10 6:09 AM, Owen DeLong wrote:
>>>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
>>>> 
>>>>  1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs
>>>>  2. Proposal Originators
>>>> 
>>>>        1. name: Owen DeLong
>>>>        2. e-mail: owen at delong.com <mailto:owen at delong.com>
>>>>        3. telephone: 408-890-7992
>>>>        4. organization: Hurricane Electric
>>>> 
>>>>        1. name: David Farmer
>>>>        2. e-mail: farmer at umn.edu <mailto:farmer at umn.edu>
>>>>        3. telephone: 612-812-9952
>>>>        4. organization: University of Minnesota
>>>> 
>>>>        1. name: Andrew Dul
>>>>        2. e-mail: andrew.dul at quark.net
>>>>        <mailto:andrew.dul at quark.net>
>>>>        3. telephone: 206-395-4004
>>>>        4. organization: Cascadeo Corp.
>>>> 
>>>>        1. name: Chris Grundemann
>>>>        2. e-mail: christopher.grundemann at twtelecom.com
>>>>        <mailto:christopher.grundemann at twtelecom.com>
>>>>        3. telephone: 303.542.6524
>>>>        4. organization: TW Telecom
>>>> 
>>>>  3. Proposal Version: 0.8
>>>> 
>>>>  4. Date: 16 November, 2010
>>>>  5. Proposal type: M
>>>>  6. Policy term: Permanent
>>>>  7. Policy statement:
>>>> 
>>>> Amend section 2 as follows:
>>>> 
>>>> Delete section 2.9 (Obsolete)
>>>> 
>>>> Replace section 2.10 with the following:
>>>> 
>>>> 	2.10 The term End Site shall mean a single structure or service
>>>> 	delivery address, or, in the case of a multi-tenant structure, a
>>>> 	single tenant within said structure (a single customer location).
>>>> 
>>>> Add the following:
>>>> 
>>>> 	2.12 The term serving site shall mean a location where an ISP
>>>> 	terminates or aggregates customer connections, including, but, not
>>>> 	limited to Points of Presence (POPs), Datacenters, Central or
>>>> 	Local switching office or regional or local combinations thereof.
>>>> 
>>>> 	2.13 The term provider assignment unit shall mean the prefix of
>>>> 	the smallest block a given ISP assigns to end sites (recommended
>>>> 	/48).
>>>> 
>>>> 	2.14 The term utilized shall have the following definitions:
>>>> 
>>>> 		(i) A provider assignment unit shall be considered fully utilized
>>>> 		when it is assigned to an end-site.
>>>> 
>>>> 		(ii) Larger blocks shall have their utilization defined by
>>>> 		dividing the number of provider assignment units assigned ###from
>>>> 		the containing block### by the total number of provider
>>>> 		assignment units _contained in the larger block_. This ratio will
>>>> 		often be expressed as a percentage (e.g. a/t*100, for a /36
>>>> 		3072/4096 * 100 = 75% utilization)
>> 
>> OK... I'll incorporate that one in the next revision.
>> 
>>>> 
>>>> 
>>>> Replace sections 6.5.1 through 6.5.3 with the following:
>>>> 
>>>> 6.5.1 Terminology
>>>> 
>>>> 	(a) The terms ISP and LIR are used interchangeably in this
>>>> 	document and any use of either term shall be construed to include
>>>> 	both meanings.
>>>> 
>>>> 	(b) The term nibble boundary shall mean a network mask which
>>>> 	aligns on a 4-bit boundary (###in slash notation, /n, where n is
>>>> 	evenly divisible by 4, allowing unit quantities### of X such that
>>>> 	2^n=X , such as 16, 256, 4096, etc.)
>> 
>> OK... I like this one to... I will incorporate it.
>> <snip>
>> (There weren't any changes suggested beyond this point).
>> 
>> Owen
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Tue Nov 16 18:25:12 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 16 Nov 2010 15:25:12 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
In-Reply-To: <4CE30147.6020902@office.tcsn.net>
References: <5669F273-ED2B-46E3-86F7-9E35E095C37A@delong.com>
	<C30FB896-BD7C-4BB1-BD23-D08B06C8ACD7@delong.com>
	<4CE2E481.8030809@office.tcsn.net>
	<44F64F8C-339D-4155-98A1-2B1B498977DE@delong.com>
	<4CE30147.6020902@office.tcsn.net>
Message-ID: <0741A798-E7AF-4230-BE45-A347B822F2DF@delong.com>


On Nov 16, 2010, at 2:10 PM, Charles O'Hern wrote:

> On 11/16/10 12:38 PM, Owen DeLong wrote:
>> 
>> On Nov 16, 2010, at 12:07 PM, Charles O'Hern wrote:
>> 
>>> I'd like to thank these gentlemen for including love for the x-small ISPs out there.  We love you guys.
>>> 
>>> Question, section 6.5.2.1 (d) dealing with End Sites larger than /48, says "(they shall) count as the appropriate number of /48s that would be assigned under that policy." is that
>>> number to be counted towards the total number of End Sites that is then rounded up to the next nibble boundary?  Or should the End Site assignment be on the nibble boundary (16
>>> /48's, 256 /48's, etc.) before adding to the total number of end sites per serving site?
>>> 
>> Assuming that 2010-8 is adopted as is, the end site would receive a nibble boundary assignment and that nibble
>> boundary would be counted for purposes of this policy. If, for example, such an end site received a /44, then, under
>> this policy they would count as 16 /48s fully utilized.
> 
> Because 6.5.8 doesn't seem to mention assignment on nibble boundaries (though I could have missed it), perhaps:
> (d)	For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the least multiple of 4
> that can contain the size of the assignment under that policy.
> 
6.5.8 does not mention it. It depends, instead, on the end-user assignment policy. This is done to ensure that
ARIN and LIRs are assigning blocks to end users from identical policy, including future changes to that
policy. It allows for consistency of policy maintained in a single place.

2010-8 provides for nibble alignment in end-user policy. Current end-user policy does not provide for
nibble alignment. I support 2010-8 and hope that it will be sent to last call shortly.

I'd like to avoid putting end-user policy snippets in the ISP Allocation policy if possible because I think
it confuses matters. However, if you still think this is a concern, let me know and I will attempt to address
it.

>>> Some minor language suggestions included inline below.  No change in meaning is intended.  The only intention is to make meaning more clear and language more precise.  Please let
>>> me know publicly if my suggestions imply that I'm misunderstanding your meaning.  I noted my edits with pound (#) signs, hopefully facilitating visibility.
>>> 
>> Thanks... Comments inline.
>> 
> <snip>
>> (There weren't any changes suggested beyond this point).
> 
> apologies, I should have snipped at that point myself and save you from having to scan for further edits.
> 
No worries... The ### notation made it pretty easy to search. ;-)

Owen



From charles at office.tcsn.net  Tue Nov 16 19:32:02 2010
From: charles at office.tcsn.net (Charles O'Hern)
Date: Tue, 16 Nov 2010 16:32:02 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8
In-Reply-To: <0741A798-E7AF-4230-BE45-A347B822F2DF@delong.com>
References: <5669F273-ED2B-46E3-86F7-9E35E095C37A@delong.com>
	<C30FB896-BD7C-4BB1-BD23-D08B06C8ACD7@delong.com>
	<4CE2E481.8030809@office.tcsn.net>
	<44F64F8C-339D-4155-98A1-2B1B498977DE@delong.com>
	<4CE30147.6020902@office.tcsn.net>
	<0741A798-E7AF-4230-BE45-A347B822F2DF@delong.com>
Message-ID: <4CE32282.5060301@office.tcsn.net>

On 11/16/10 3:25 PM, Owen DeLong wrote:
> 
> On Nov 16, 2010, at 2:10 PM, Charles O'Hern wrote:
> 
>> On 11/16/10 12:38 PM, Owen DeLong wrote:
>>>
>>> On Nov 16, 2010, at 12:07 PM, Charles O'Hern wrote:
<snip>
>> Because 6.5.8 doesn't seem to mention assignment on nibble boundaries (though I could have missed it), perhaps:
>> (d)	For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the least multiple of 4
>> that can contain the size of the assignment under that policy.
>>
> 6.5.8 does not mention it. It depends, instead, on the end-user assignment policy. This is done to ensure that
> ARIN and LIRs are assigning blocks to end users from identical policy, including future changes to that
> policy. It allows for consistency of policy maintained in a single place.
> 
> 2010-8 provides for nibble alignment in end-user policy. Current end-user policy does not provide for
> nibble alignment. I support 2010-8 and hope that it will be sent to last call shortly.
> 
> I'd like to avoid putting end-user policy snippets in the ISP Allocation policy if possible because I think
> it confuses matters. However, if you still think this is a concern, let me know and I will attempt to address
> it.

*sheepishly* I hadn't reviewed 2010-8 for that, but agree that putting specifics for EU policy in ISP policy would muddle things.
Strike my last and thanks for the response.

-- 
Charles O'Hern
Network Operations

TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net


From info at arin.net  Wed Nov 17 11:20:32 2010
From: info at arin.net (ARIN)
Date: Wed, 17 Nov 2010 11:20:32 -0500
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CD55B73.9030104@arin.net>
References: <4CD55B73.9030104@arin.net>
Message-ID: <4CE400D0.4000103@arin.net>

Policy Proposal 121: Sensible IPv6 Allocation for ISPs

ARIN acknowledges receipt of the policy proposal that can be found below.

The ARIN Advisory Council (AC) will review the proposal at their next
regularly scheduled meeting (if the period before the next regularly
scheduled meeting is less than 10 days, then the period may be extended
to the subsequent regularly scheduled meeting). The AC will decide how
to utilize the proposal and announce the decision to the PPML.

The AC invites everyone to comment on the 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.

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


> -----Original Message-----

> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On

> Behalf Of Owen DeLong

> Sent: Tuesday, November 16, 2010 9:10 AM

> To: policy; ppml at arin.net PPML

> Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8

>

>  Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

>    1. Policy Proposal Name: Sensible IPv6 Allocation for ISPs

>    2. Proposal Originators

>          1. name: Owen DeLong

>          2. e-mail: owen at delong.com

>          3. telephone: 408-890-7992

>          4. organization: Hurricane Electric

>          1. name: David Farmer

>          2. e-mail: farmer at umn.edu

>          3. telephone: 612-812-9952

>          4. organization: University of Minnesota

>          1. name: Andrew Dul

>          2. e-mail: andrew.dul at quark.net

>          3. telephone: 206-395-4004

>          4. organization: Cascadeo Corp.

>          1. name: Chris Grundemann

>          2. e-mail: christopher.grundemann at twtelecom.com

>          3. telephone: 303.542.6524

>          4. organization: TW Telecom

> 3. Proposal Version: 0.8

> 4. Date: 16 November, 2010 5. Proposal type: M 6. Policy term:

> Permanent 7. Policy statement:

> Amend section 2 as follows:

> Delete section 2.9 (Obsolete)

> Replace section 2.10 with the following:

>     2.10 The term End Site shall mean a single structure or service

> delivery address, or, in the case of a multi-tenant structure, a single

> tenant within said structure (a single customer location).

> Add the following:

>     2.12 The term serving site shall mean a location where an ISP

> terminates or aggregates customer connections, including, but, not

> limited to Points of Presence (POPs), Datacenters, Central or Local

> switching office or regional or local combinations thereof.

>     2.13 The term provider assignment unit shall mean the prefix of

> the smallest block a given ISP assigns to end sites (recommended /48).

>     2.14 The term utilized shall have the following definitions:

>           (i) A provider assignment unit shall be considered fully

> utilized when it is assigned to an end-site.

>           (ii) Larger blocks shall have their utilization defined by

> dividing the number of provider assignment units assigned by the total

> number of provider assignment units. This ratio will often be expressed

> as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75%

> utilization)

>

>

> Replace sections 6.5.1 through 6.5.3 with the following:

> 6.5.1 Terminology

>     (a) The terms ISP and LIR are used interchangeably in this

> document and any use of either term shall be construed to include both

> meanings.

>     (b) The term nibble boundary shall mean a network mask which

> aligns on a 4-bit boundary (a number X such that 2^n=X where n is

> evenly divisible by 4, such as 16, 256, 4096, etc.)

> 6.5.2     Initial Allocations to LIRs

>     6.5.2.1     Size

>     (a)   All allocations shall be made on nibble boundaries.

>     (b)   In no case shall an LIR receive smaller than a /32 unless

> they specifically request a /36.

>     (c)   The maximum allowable allocation shall be the smallest

> nibble-boundary aligned block that can provide an equally sized nibble-

> boundary aligned block to each of the requesters serving sites large

> enough to satisfy the needs of the requesters largest single serving

> site using no more than 75% of the available addresses.

>

>           This calculation can be summarized as /N where N = 48-(X+Y)

> and X is a multiple of 4 greater than 4/3*serving sites and Y is a

> multiple of 4 greater than 4/3*end sites served by largest serving

> site.

>

>

>     (d)   For purposes of the calculation in (c), an end site which

> can justify more than a /48 under the end-user assignment criteria in

> 6.5.8 shall count as the appropriate number of /48s that would be

> assigned under that policy.

>     (e)   For purposes of the calculation in (c), an LIR which has

> subordinate LIRs shall make such allocations according to the same

> policies and criteria as ARIN. In such a case, the prefixes necessary

> for such an allocation should be treated as fully utilized in

> determining the block sizing for the parent LIR.

>     (f)   An LIR is not required to design or deploy their network

> according to this structure. It is strictly a mechanism to determine

> the largest IP address block to which the LIR is entitled.

>     6.5.2.2     Qualifications

>     An organization qualifies for an allocation under this policy if

> they meet any of the following criteria:

>     (a)   Have a previously justified IPv4 ISP allocation from ARIN

> or one of its predecessor registries or can qualify for an IPv4 ISP

> allocation under current criteria.

>     (b)   Are currently multihomed for IPv6 or will immediately

> become multihomed for IPv6 using a valid assigned global AS number.

>     (c)   Provide ARIN a reasonable technical justification,

> indicating why an allocation is necessary, including the intended

> purposes for the allocation, and describing the network infrastructure

> the allocation will be used to support. Justification must include a

> plan detailing assignments to other organizations or customers for one,

> two and five year periods, with a minimum of 50 assignments within 5

> years.

> 6.5.3     Subsequent Allocations to LIRs

>     (a)   Where possible ARIN will make subsequent allocations by

> expanding the existing allocation.

>     (b)   An LIR which can show utilization of 75% or more of their

> total address space, or more than 90% of any serving site shall be

> entitled to a subsequent allocation.

>     (c)   If ARIN can not expand one or more existing allocations,

> ARIN shall make a new allocation based on the initial allocation

> criteria above. The LIR is encouraged, but not required to renumber

> into the new allocation over time and return any allocations no longer

> in use.

> Replace section 6.5.4 with the following

> 6.5.4     Assignments to end users shall be governed by the same

> practices adopted by the community in section 6.5.8 except that the

> requirements in 6.5.8.1 do not apply.

> Add the following to 6.5.7

> LIRs which received an allocation under previous policies which is

> smaller than what they are entitled to under this policy may receive a

> new initial allocation under this policy provided that they agree to

> renumber into that new allocation and return their prior allocation(s)

> within 5 years. If possible, ARIN will simply expand their existing

> allocation rather than requiring renumber and return.

>    8. Rationale:

> The current ISP policy for IPv6 allocations is both short-sighted and

> insufficient for rational deployments by most ISPs. We have gained

> significant operational experience with IPv6 in the time since it was

> written and it is clear that current policy is driving many ISPs to

> choices of excess conservatism that will eventually harm innovation in

> the consumer space.

> Under the proposed policy, the entirety of the ARIN region can still be

> numbered in no more than 2 /12s (quite probably 1). There are still 506

> /12s free within the current /3. It is unreasonable to shoot ourselves

> in the foot with address scarcity thinking so early into the IPv6

> deployment. This policy seeks to strike a more reasonable and

> harmonious balance of the goals stated in NRPM 6.3.

> The lower bound of /36 is intended to facilitate extremely small ISPs

> getting a smaller block if they do not need to support more than ~4000

> customers. It is hoped that the board will take subsequent action to

> adjust the fee structure to eliminate the $1,000/year price hike for

> those extremely small ISPs. These ISPs can, of course, get a /32 if

> they wish.

> The intent of section 6.5.4 is to create and preserve parity between

> the requirements for LIR->End User and ARIN->End User policies. This

> section presumes that 6.5.8 has already been modified as described in

> draft policy 2010-8.

> Some examples of determining the size of block for which an

> organization is eligible:

> Bill's Bait, Sushi, and IP Transit:

>     Largest serving site:         200 end sites

>     Number of serving sites:      5

>     200 rounds up to 256 (nibble boundary, 8 bits). 200 > 192 (256 *

> 0.75), so, round up to 4096 (12 bits)

>     5 rounds up to 16 (nibble boundary, 4 bits). 5 < 12 (16 * 0.75),

> so, no further round up. 16 (4 bits)

>     48 - (12+4) = 32 -- This organization could receive up to a /32.

> Lee's Rural Internet, Inc.

>     Largest serving site:         1024 end sites

>     Number of serving sites:      30

>     1024 rounds up to 4096 (nibble boundary, 12 bits) 1024 < 3072

> (4096 * 0.75), so 4096 (12 bits)

>     30 rounds up to 256 (nibble boundary, 8 bits). 30 < 192 (256 *

> 0.75), so, 256 (8 bits)

>     48 - (12+8) = 28 -- This organization could receive up to a /28.

> Paul's Mega Metro ISP, LLC

>     Largest serving site:         3,500 end sites

>     Number of serving sites:      140

>     3,500 rounds up to 4096 (nibble boundary, 12 bits). 3500 > 3072

> (4096 * 0.75), so, round up to 65,536 (16 bits)

>     140 rounds up to 256 (nibble boundary, 8 bits) 140 < 192 (256 *

> 0.75), so, 256 (8 bits)

>     48 - (16+8) = 24 -- This organization could receive up to a /24

> PON's CMTS mega DSL Corp.

>     Largest serving site:         30,000 end sites

>     Number of serving sites:      700

>     30,000 rounds up to 65,536 (nibble boundary, 16 bits). 30,000 <

> 49,152 (65536 * 0.75), so, 65,536 (16 bits)

>     700 rounds up to 4,096 (nibble boundary, 12 bits). 700 < 3072

> (4096 * 0.75), so, 4,096 (12 bits)

>     48 - (16+12) = 20 -- This organization could receive up to a /20.

> Sizing table:

> Units           Round-up    Bits

> 0-11            16          4

> 13-191          256         8

> 192-3,071 4,096       12

> 3,072-49,151    65,536            16

> 49,152-786,431  1,048,576   20

>    9. Timetable for implementation: Immediate

>

> END OF TEMPLATE

>

>

>

>







From tedm at ipinc.net  Wed Nov 17 12:47:45 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 17 Nov 2010 09:47:45 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CE400D0.4000103@arin.net>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
Message-ID: <4CE41541.30101@ipinc.net>

On 11/17/2010 8:20 AM, ARIN wrote:
> Policy Proposal 121: Sensible IPv6 Allocation for ISPs
>
> ARIN acknowledges receipt of the policy proposal that can be found below.
>
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
>
> The AC invites everyone to comment on the 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 Rationale section is missing a discussion of the impact of this
policy change on DFZ growth.

Ted


From owen at delong.com  Wed Nov 17 13:10:10 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 17 Nov 2010 10:10:10 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CE41541.30101@ipinc.net>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<4CE41541.30101@ipinc.net>
Message-ID: <6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>


On Nov 17, 2010, at 9:47 AM, Ted Mittelstaedt wrote:

> On 11/17/2010 8:20 AM, ARIN wrote:
>> Policy Proposal 121: Sensible IPv6 Allocation for ISPs
>> 
>> ARIN acknowledges receipt of the policy proposal that can be found below.
>> 
>> The ARIN Advisory Council (AC) will review the proposal at their next
>> regularly scheduled meeting (if the period before the next regularly
>> scheduled meeting is less than 10 days, then the period may be extended
>> to the subsequent regularly scheduled meeting). The AC will decide how
>> to utilize the proposal and announce the decision to the PPML.
>> 
>> The AC invites everyone to comment on the 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 Rationale section is missing a discussion of the impact of this
> policy change on DFZ growth.
> 
I believe that if anything, it would reduce DFZ growth, but, expect it
to be mostly neutral. I left this out of the rationale section because
I didn't think the impact one way or another would be enough to
be particularly relevant to the discussion.

Do you have reason to believe otherwise?

Owen



From tedm at ipinc.net  Wed Nov 17 13:46:27 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 17 Nov 2010 10:46:27 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<4CE41541.30101@ipinc.net>
	<6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>
Message-ID: <4CE42303.1000700@ipinc.net>

On 11/17/2010 10:10 AM, Owen DeLong wrote:
>
> On Nov 17, 2010, at 9:47 AM, Ted Mittelstaedt wrote:
>
>> On 11/17/2010 8:20 AM, ARIN wrote:
>>> Policy Proposal 121: Sensible IPv6 Allocation for ISPs
>>>
>>> ARIN acknowledges receipt of the policy proposal that can be found below.
>>>
>>> The ARIN Advisory Council (AC) will review the proposal at their next
>>> regularly scheduled meeting (if the period before the next regularly
>>> scheduled meeting is less than 10 days, then the period may be extended
>>> to the subsequent regularly scheduled meeting). The AC will decide how
>>> to utilize the proposal and announce the decision to the PPML.
>>>
>>> The AC invites everyone to comment on the 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 Rationale section is missing a discussion of the impact of this
>> policy change on DFZ growth.
>>
> I believe that if anything, it would reduce DFZ growth, but, expect it
> to be mostly neutral. I left this out of the rationale section because
> I didn't think the impact one way or another would be enough to
> be particularly relevant to the discussion.
>
> Do you have reason to believe otherwise?
>

I think it is important to put into the Rationale the statement that
this is DFZ-growth neutral, that is, if you believe that it IS 
DFZ-growth neutral.

By inserting the statement that you feel it's DFZ-growth-neutral into
the Rationale you are showing that you have responsibly considered the
impact of modifying the qualification criteria on the DFZ.
That makes all the difference in the world.  Lacking that it makes the
reader wonder if this proposal has really been well thought out.

Ted

> Owen
>



From owen at delong.com  Wed Nov 17 15:07:14 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 17 Nov 2010 12:07:14 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CE42303.1000700@ipinc.net>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<4CE41541.30101@ipinc.net>
	<6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>
	<4CE42303.1000700@ipinc.net>
Message-ID: <9147F1E5-D0C3-4CF4-843B-ED39C6670B69@delong.com>


On Nov 17, 2010, at 10:46 AM, Ted Mittelstaedt wrote:

> On 11/17/2010 10:10 AM, Owen DeLong wrote:
>> 
>> On Nov 17, 2010, at 9:47 AM, Ted Mittelstaedt wrote:
>> 
>>> On 11/17/2010 8:20 AM, ARIN wrote:
>>>> Policy Proposal 121: Sensible IPv6 Allocation for ISPs
>>>> 
>>>> ARIN acknowledges receipt of the policy proposal that can be found below.
>>>> 
>>>> The ARIN Advisory Council (AC) will review the proposal at their next
>>>> regularly scheduled meeting (if the period before the next regularly
>>>> scheduled meeting is less than 10 days, then the period may be extended
>>>> to the subsequent regularly scheduled meeting). The AC will decide how
>>>> to utilize the proposal and announce the decision to the PPML.
>>>> 
>>>> The AC invites everyone to comment on the 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 Rationale section is missing a discussion of the impact of this
>>> policy change on DFZ growth.
>>> 
>> I believe that if anything, it would reduce DFZ growth, but, expect it
>> to be mostly neutral. I left this out of the rationale section because
>> I didn't think the impact one way or another would be enough to
>> be particularly relevant to the discussion.
>> 
>> Do you have reason to believe otherwise?
>> 
> 
> I think it is important to put into the Rationale the statement that
> this is DFZ-growth neutral, that is, if you believe that it IS DFZ-growth neutral.
> 
> By inserting the statement that you feel it's DFZ-growth-neutral into
> the Rationale you are showing that you have responsibly considered the
> impact of modifying the qualification criteria on the DFZ.
> That makes all the difference in the world.  Lacking that it makes the
> reader wonder if this proposal has really been well thought out.
> 
I don't believe I am changing the qualifying criteria. At least not significantly.

What I am changing is the amount of space a qualifying entity can get.

By increasing the maximum amount of space allowed (possibly dramatically),
if anything, this should reduce the impact on the DFZ.

However, I really don't think that the IPv6 DFZ size is of tremendous concern.
I think that the DFZ size is much more of an IPv4 issue. The IPv6 DFZ, even
when IPv6 is fully deployed is likely to be less than 20% of the current
IPv4 DFZ.

I think that excessive focus on DFZ size has flawed ARIN policy for years
and including it in the rationale for this policy would only serve to further
that practice.

Owen



From tedm at ipinc.net  Wed Nov 17 15:34:35 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 17 Nov 2010 12:34:35 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <9147F1E5-D0C3-4CF4-843B-ED39C6670B69@delong.com>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<4CE41541.30101@ipinc.net>
	<6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>
	<4CE42303.1000700@ipinc.net>
	<9147F1E5-D0C3-4CF4-843B-ED39C6670B69@delong.com>
Message-ID: <4CE43C5B.2060906@ipinc.net>

On 11/17/2010 12:07 PM, Owen DeLong wrote:
>
> On Nov 17, 2010, at 10:46 AM, Ted Mittelstaedt wrote:
>
>> On 11/17/2010 10:10 AM, Owen DeLong wrote:
>>>
>>> On Nov 17, 2010, at 9:47 AM, Ted Mittelstaedt wrote:
>>>
>>>> On 11/17/2010 8:20 AM, ARIN wrote:
>>>>> Policy Proposal 121: Sensible IPv6 Allocation for ISPs
>>>>>
>>>>> ARIN acknowledges receipt of the policy proposal that can be found below.
>>>>>
>>>>> The ARIN Advisory Council (AC) will review the proposal at their next
>>>>> regularly scheduled meeting (if the period before the next regularly
>>>>> scheduled meeting is less than 10 days, then the period may be extended
>>>>> to the subsequent regularly scheduled meeting). The AC will decide how
>>>>> to utilize the proposal and announce the decision to the PPML.
>>>>>
>>>>> The AC invites everyone to comment on the 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 Rationale section is missing a discussion of the impact of this
>>>> policy change on DFZ growth.
>>>>
>>> I believe that if anything, it would reduce DFZ growth, but, expect it
>>> to be mostly neutral. I left this out of the rationale section because
>>> I didn't think the impact one way or another would be enough to
>>> be particularly relevant to the discussion.
>>>
>>> Do you have reason to believe otherwise?
>>>
>>
>> I think it is important to put into the Rationale the statement that
>> this is DFZ-growth neutral, that is, if you believe that it IS DFZ-growth neutral.
>>
>> By inserting the statement that you feel it's DFZ-growth-neutral into
>> the Rationale you are showing that you have responsibly considered the
>> impact of modifying the qualification criteria on the DFZ.
>> That makes all the difference in the world.  Lacking that it makes the
>> reader wonder if this proposal has really been well thought out.
>>
> I don't believe I am changing the qualifying criteria. At least not significantly.
>
> What I am changing is the amount of space a qualifying entity can get.
>

You said in the Rationale that you want ARIN to lower prices for the 
smaller orgs.  I think that right there would encourage more of them to
get their own numbers, thus increasing the DFZ

> By increasing the maximum amount of space allowed (possibly dramatically),
> if anything, this should reduce the impact on the DFZ.
>

And the logical reason for this is....

> However, I really don't think that the IPv6 DFZ size is of tremendous concern.
> I think that the DFZ size is much more of an IPv4 issue. The IPv6 DFZ, even
> when IPv6 is fully deployed is likely to be less than 20% of the current
> IPv4 DFZ.
>
> I think that excessive focus on DFZ size has flawed ARIN policy for years

I don't agree and I think such a statement is very snobbish.  Not 
everyone has as much money as you so they can run out and buy more ram
for their routers every year.  Especially the smaller orgs who your 
purporting to help with this.  People who are concerned over DFZ bloat
are not flawed and obsessive.  If anything is obsessive it is this
proposal of yours that is obsessed with straightening up loose ends in
the NRPM.

> and including it in the rationale for this policy would only serve to further
> that practice.
>

Ah, now the real reason comes out.  It's not a logical decision it's
an illogical, emotional one.  So I wonder now if this policy proposal of 
yours is also not logical, but more emotional.  Do you spend your
free time obsessively straightening up around the house?  Do frayed 
carpets drive you insane?

Deliberately ignoring it only serves to make people think your trying to 
avoid the issue because you have something to hide.  And when you know 
others are concerned, not confronting the issue straight on and dealing 
with it is cowardly.  Espically since all it would take is a single line 
in the Rationale to indicate you had considered it.  You spent gobs of 
space in the mathematics section.  Why don't you put the single line 
after that?  Most people will have fallen asleep in the
reading of that, so few would read it and affect your "sensibilities"

As I see it, sticking one sentence in the Rationale saying that the
lowering the bar that the criteria change makes should not cause DFZ
bloat because of X is no skin off your nose.  So your refusal to do
it is self-defeating.  Which is more important, getting the proposal
accepted or maintaing your personal paradigm that even speaking about 
DFZ bloat is flawed?

Ted

> Owen
>
>



From owen at delong.com  Wed Nov 17 16:30:17 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 17 Nov 2010 13:30:17 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CE43C5B.2060906@ipinc.net>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<4CE41541.30101@ipinc.net>
	<6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>
	<4CE42303.1000700@ipinc.net>
	<9147F1E5-D0C3-4CF4-843B-ED39C6670B69@delong.com>
	<4CE43C5B.2060906@ipinc.net>
Message-ID: <D1A27D7D-AEED-47AA-8A0A-62412888F902@delong.com>

Ignoring the personal attacks, I've answered Ted at length in private email.

Publicly, I will state:

1.	In IPv4, address policy and routing policy got tied together because
	of the need to manage the tradeoff between scarcity and table
	growth. In IPv6, scarcity is no longer an issue.

2.	An ARIN allocation is not guaranteed to be routable and address
	policy should focus on good stewardship of the address space
	leaving the routing issues for groups of operators to coordinate
	in a more operational forum.

3.	The fee recommendation in the rationale is not a fee reduction.
	It focuses on making it possible for the board to eliminate the
	disparity of IPv4 and IPv6 fees at the very small end. This is
	not likely to increase the number of smaller ISPs that multihome,
	but, is intended to decrease the number of smaller ISPs that
	procrastinate IPv6 deployment as long as possible since
	they will no longer be facing a $1,000 disincentive to do so.

4.	If there are others who feel that explaining that this policy
	will reduce DFZ growth if it has any impact on the DFZ
	is an important element in the rationale, please let me know.
	If there is significant support for this, I will include it.

Owen




From tedm at ipinc.net  Wed Nov 17 17:10:41 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 17 Nov 2010 14:10:41 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <D1A27D7D-AEED-47AA-8A0A-62412888F902@delong.com>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<4CE41541.30101@ipinc.net>
	<6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>
	<4CE42303.1000700@ipinc.net>
	<9147F1E5-D0C3-4CF4-843B-ED39C6670B69@delong.com>
	<4CE43C5B.2060906@ipinc.net>
	<D1A27D7D-AEED-47AA-8A0A-62412888F902@delong.com>
Message-ID: <4CE452E1.5050304@ipinc.net>

On 11/17/2010 1:30 PM, Owen DeLong wrote:
> Ignoring the personal attacks, I've answered Ted at length in private email.
>

Owen has indeed responded to the DFZ issue to me via private e-mail.  It 
is a logical, concrete response that really has nothing at all with the 
items listed here.  I wish that he would have included it in his 
response here.

Ted

> Publicly, I will state:
>
> 1.	In IPv4, address policy and routing policy got tied together because
> 	of the need to manage the tradeoff between scarcity and table
> 	growth. In IPv6, scarcity is no longer an issue.
>
> 2.	An ARIN allocation is not guaranteed to be routable and address
> 	policy should focus on good stewardship of the address space
> 	leaving the routing issues for groups of operators to coordinate
> 	in a more operational forum.
>
> 3.	The fee recommendation in the rationale is not a fee reduction.
> 	It focuses on making it possible for the board to eliminate the
> 	disparity of IPv4 and IPv6 fees at the very small end. This is
> 	not likely to increase the number of smaller ISPs that multihome,
> 	but, is intended to decrease the number of smaller ISPs that
> 	procrastinate IPv6 deployment as long as possible since
> 	they will no longer be facing a $1,000 disincentive to do so.
>
> 4.	If there are others who feel that explaining that this policy
> 	will reduce DFZ growth if it has any impact on the DFZ
> 	is an important element in the rationale, please let me know.
> 	If there is significant support for this, I will include it.
>



From owen at delong.com  Wed Nov 17 17:16:59 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 17 Nov 2010 14:16:59 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CE452E1.5050304@ipinc.net>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<4CE41541.30101@ipinc.net>
	<6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>
	<4CE42303.1000700@ipinc.net>
	<9147F1E5-D0C3-4CF4-843B-ED39C6670B69@delong.com>
	<4CE43C5B.2060906@ipinc.net>
	<D1A27D7D-AEED-47AA-8A0A-62412888F902@delong.com>
	<4CE452E1.5050304@ipinc.net>
Message-ID: <B591D8EF-A8E5-46C2-AB93-2E514A606BEE@delong.com>


On Nov 17, 2010, at 2:10 PM, Ted Mittelstaedt wrote:

> On 11/17/2010 1:30 PM, Owen DeLong wrote:
>> Ignoring the personal attacks, I've answered Ted at length in private email.
>> 
> 
> Owen has indeed responded to the DFZ issue to me via private e-mail.  It is a logical, concrete response that really has nothing at all with the items listed here.  I wish that he would have included it in his response here.
> 
> Ted
> 
>> 

I consider it pretty well related, but, at Ted's request, I will saddle
you all with that piece of my response to him:

>>> By increasing the maximum amount of space allowed (possibly dramatically),
>>> if anything, this should reduce the impact on the DFZ.
>>> 
>> 
>> And the logical reason for this is....
>> 
> Because it will reduce the number of organizations that come, get a /32, discover
> that isn't enough, come back, get a /31, fill that up, come back, get a /30... Which
> is one of two possible outcomes of current policy. The other possible outcome
> is that LIRs will be assigning end sites blocks smaller than /48 in order to have
> the ability to support more than ~60,000 customers which, while not harmful
> to the DFZ is harmful to innovation on the internet in general.
> 
> We have already seen this harmful behavior in Europe (Free.fr is giving
> customers /60s), Asia (many ISPs are squeezing their customers into
> prefixes of /56 and /64 in order to squeeze their entire networks into
> a /32), and North America (several IPv6 trials have involved prefix sizes
> ranging from /52 to /60).



Owen

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

From jbates at brightok.net  Wed Nov 17 19:05:56 2010
From: jbates at brightok.net (Jack Bates)
Date: Wed, 17 Nov 2010 18:05:56 -0600
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CE43C5B.2060906@ipinc.net>
References: <4CD55B73.9030104@arin.net>
	<4CE400D0.4000103@arin.net>	<4CE41541.30101@ipinc.net>	<6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>	<4CE42303.1000700@ipinc.net>	<9147F1E5-D0C3-4CF4-843B-ED39C6670B69@delong.com>
	<4CE43C5B.2060906@ipinc.net>
Message-ID: <4CE46DE4.3070802@brightok.net>

I know Owen responded, but I wanted to expand on some points.

On 11/17/2010 2:34 PM, Ted Mittelstaedt wrote:
> You said in the Rationale that you want ARIN to lower prices for the 
> smaller orgs.  I think that right there would encourage more of them to
> get their own numbers, thus increasing the DFZ
>
There is a strong reason not to block on RIR PA minimums. PA allocations 
do not always match ASN assignments, and there will be people 
multihoming using longer than /32 prefixes. It is our hope that this 
will be at a minimum with v6 as newer technologies support multihoming 
with multiple prefixes instead of the current method. This, however, is 
not an allocation policy concern.


>> By increasing the maximum amount of space allowed (possibly 
>> dramatically),
>> if anything, this should reduce the impact on the DFZ.
>>
>
> And the logical reason for this is....
>

The reason, as Owen stated separately, is that if I have to keep 
returning for allocations, they will end up getting divided, and as a 
provider I will have multiple networks I must advertise. However, this 
is actually unlikely, as I suspect most ISPs with 3+ transit peers will 
need a granularity of up to 16 networks advertised to properly balance 
traffic, as natural BGP balancing doesn't work at certain bandwidth 
ranges. In v6, it is unlikely that you will receive 16 separate 
allocations. In v4, you often could end up with many more allocations 
that exceeded the number of prefixes you'd need for granular balancing.


> As I see it, sticking one sentence in the Rationale saying that the
> lowering the bar that the criteria change makes should not cause DFZ
> bloat because of X is no skin off your nose.  So your refusal to do
> it is self-defeating.  Which is more important, getting the proposal
> accepted or maintaing your personal paradigm that even speaking about 
> DFZ bloat is flawed?
>

I think the issue is that we would even consider it as a DFZ bloat 
issue. Smaller allocations force DFZ bloat, but there is an expectation 
that even large allocations will be divided to help BGP with policies 
and balancing. It would be hoped that this would be done with as little 
granularity as necessary, but in IPv4 it has often been shown not to. 
That being said, in IPv4, I have way more networks advertised than 
necessary to balance my traffic and it is because of how restrictive the 
allocations are.

Policy, I believe, already and will continue to state that the recipient 
of an allocation should advertise the aggregate. If they advertise 
longer prefixes for balancing, this allows the aggregate to handle those 
cases where people's routers can't handle the longer prefixes. 
Allocation Policy != Routing Policy, and I suspect it never will.


Jack




From Daniel_Alexander at Cable.Comcast.com  Wed Nov 17 22:34:35 2010
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Thu, 18 Nov 2010 03:34:35 +0000
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <B591D8EF-A8E5-46C2-AB93-2E514A606BEE@delong.com>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<4CE41541.30101@ipinc.net>	<6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com>
	<4CE42303.1000700@ipinc.net>
	<9147F1E5-D0C3-4CF4-843B-ED39C6670B69@delong.com>
	<4CE43C5B.2060906@ipinc.net>
	<D1A27D7D-AEED-47AA-8A0A-62412888F902@delong.com>
	<4CE452E1.5050304@ipinc.net>,
	<B591D8EF-A8E5-46C2-AB93-2E514A606BEE@delong.com>
Message-ID: <B64177493F39BA4A81233AA84B50049E0546EE@PACDCEXMB12.cable.comcast.com>

Owen,

Can you expand on your thought below? Why do you think giving a customer a /56 is harmful to innovation on the Internet?

-Dan

________________________________
From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] on behalf of Owen DeLong [owen at delong.com]
Sent: Wednesday, November 17, 2010 5:16 PM
To: Ted Mittelstaedt
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)


On Nov 17, 2010, at 2:10 PM, Ted Mittelstaedt wrote:

On 11/17/2010 1:30 PM, Owen DeLong wrote:
Ignoring the personal attacks, I've answered Ted at length in private email.


Owen has indeed responded to the DFZ issue to me via private e-mail.  It is a logical, concrete response that really has nothing at all with the items listed here.  I wish that he would have included it in his response here.

Ted



I consider it pretty well related, but, at Ted's request, I will saddle
you all with that piece of my response to him:

By increasing the maximum amount of space allowed (possibly dramatically),
if anything, this should reduce the impact on the DFZ.


And the logical reason for this is....

Because it will reduce the number of organizations that come, get a /32, discover
that isn't enough, come back, get a /31, fill that up, come back, get a /30... Which
is one of two possible outcomes of current policy. The other possible outcome
is that LIRs will be assigning end sites blocks smaller than /48 in order to have
the ability to support more than ~60,000 customers which, while not harmful
to the DFZ is harmful to innovation on the internet in general.

We have already seen this harmful behavior in Europe (Free.fr<http://Free.fr/> is giving
customers /60s), Asia (many ISPs are squeezing their customers into
prefixes of /56 and /64 in order to squeeze their entire networks into
a /32), and North America (several IPv6 trials have involved prefix sizes
ranging from /52 to /60).


Owen

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

From gbonser at seven.com  Thu Nov 18 12:54:36 2010
From: gbonser at seven.com (George Bonser)
Date: Thu, 18 Nov 2010 09:54:36 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CE43C5B.2060906@ipinc.net>
References: <4CD55B73.9030104@arin.net>
	<4CE400D0.4000103@arin.net><4CE41541.30101@ipinc.net><6CA8425D-831E-464B-AE99-4D2B780CA8A1@delong.com><4CE42303.1000700@ipinc.net><9147F1E5-D0C3-4CF4-843B-ED39C6670B69@delong.com>
	<4CE43C5B.2060906@ipinc.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14CA1F@RWC-EX1.corp.seven.com>

> > However, I really don't think that the IPv6 DFZ size is of
tremendous
> concern.
> > I think that the DFZ size is much more of an IPv4 issue. The IPv6
> DFZ, even
> > when IPv6 is fully deployed is likely to be less than 20% of the
> current
> > IPv4 DFZ.

Larger allocations should allow for better aggregation, but not always.
Aggregation is possible where all subnets are connected and share access
to the DFZ.  In the case of facilities not directly connected, it is not
always possible to aggregate.

So, overall I would expect that the impact of this would, as Owen said,
be neutral or possibly reduce the DFZ routing table somewhat by allowing
greater aggregation in many cases, rather than having several smaller
blocks.

George



From gbonser at seven.com  Thu Nov 18 12:55:34 2010
From: gbonser at seven.com (George Bonser)
Date: Thu, 18 Nov 2010 09:55:34 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CE400D0.4000103@arin.net>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14CA20@RWC-EX1.corp.seven.com>



> 
> The AC invites everyone to comment on the 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.

Support.


From lar at mwtcorp.net  Thu Nov 18 14:15:13 2010
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Thu, 18 Nov 2010 12:15:13 -0700
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <4CE400D0.4000103@arin.net>
References: <4CD55B73.9030104@arin.net>
 <4CE400D0.4000103@arin.net>
Message-ID: <web-2537520@be1.mail.trib.com>

I strongly support.
> 
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
> 
> The AC invites everyone to comment on the 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.
> 
  
  While a /32 at first glance looked like way more addresses than we needed,
when I started engineering the network into my locations it quickly
became clear that /48 was out for all but my largest business
customers. /56 or /60's are all I could manage for SOHO and residential 
customers
and still have a reasonably manageable network.

>>    8. Rationale:
> 
>> The current ISP policy for IPv6 allocations is both short-sighted and
>> insufficient for rational deployments by most ISPs. We have gained
>> significant operational experience with IPv6 in the time since it was
>> written and it is clear that current policy is driving many ISPs to
>> choices of excess conservatism that will eventually harm innovation in
>> the consumer space.

Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387


From rcarpen at network1.net  Thu Nov 18 14:49:02 2010
From: rcarpen at network1.net (Randy Carpenter)
Date: Thu, 18 Nov 2010 14:49:02 -0500 (EST)
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <web-2537520@be1.mail.trib.com>
Message-ID: <1061993448.18878.1290109742660.JavaMail.root@zimbra.network1.net>


I also very strongly support this.

-Randy

--
| Randy Carpenter
| Vice President, IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (419)739-9240, x1
----

----- Original Message -----
> I strongly support.
> >
> > The ARIN Advisory Council (AC) will review the proposal at their
> > next
> > regularly scheduled meeting (if the period before the next regularly
> > scheduled meeting is less than 10 days, then the period may be
> > extended
> > to the subsequent regularly scheduled meeting). The AC will decide
> > how
> > to utilize the proposal and announce the decision to the PPML.
> >
> > The AC invites everyone to comment on the 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.
> >
> 
> While a /32 at first glance looked like way more addresses than we
> needed,
> when I started engineering the network into my locations it quickly
> became clear that /48 was out for all but my largest business
> customers. /56 or /60's are all I could manage for SOHO and
> residential
> customers
> and still have a reasonably manageable network.
> 
> >>    8. Rationale:
> >
> >> The current ISP policy for IPv6 allocations is both short-sighted
> >> and
> >> insufficient for rational deployments by most ISPs. We have gained
> >> significant operational experience with IPv6 in the time since it
> >> was
> >> written and it is clear that current policy is driving many ISPs to
> >> choices of excess conservatism that will eventually harm innovation
> >> in
> >> the consumer space.
> 
> Larry Ash
> Network Administrator
> Mountain West Telephone
> 123 W 1st St.
> Casper, WY 82601
> Office 307 233-8387
> _______________________________________________
> 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 jbates at brightok.net  Thu Nov 18 14:50:27 2010
From: jbates at brightok.net (Jack Bates)
Date: Thu, 18 Nov 2010 13:50:27 -0600
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <web-2537520@be1.mail.trib.com>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<web-2537520@be1.mail.trib.com>
Message-ID: <4CE58383.2020001@brightok.net>

I strongly support (in case I wasn't clear previously).

On 11/18/2010 1:15 PM, lar at mwtcorp.net wrote:
>
> While a /32 at first glance looked like way more addresses than we needed,
> when I started engineering the network into my locations it quickly
> became clear that /48 was out for all but my largest business
> customers. /56 or /60's are all I could manage for SOHO and residential
> customers
> and still have a reasonably manageable network.
>

We had the same problem. While you can do a do-over and get larger than 
/32 easy enough now, there are many other gaping holes in the existing 
policy. I believe that this policy does well to try and keep ARIN from 
having to create interpretations (policy doesn't really state, so we 
don't do it).


Jack


From charles at office.tcsn.net  Thu Nov 18 15:58:14 2010
From: charles at office.tcsn.net (Charles O'Hern)
Date: Thu, 18 Nov 2010 12:58:14 -0800
Subject: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14CA20@RWC-EX1.corp.seven.com>
References: <4CD55B73.9030104@arin.net> <4CE400D0.4000103@arin.net>
	<5A6D953473350C4B9995546AFE9939EE0B14CA20@RWC-EX1.corp.seven.com>
Message-ID: <4CE59366.6090305@office.tcsn.net>

Strongly support

> The AC invites everyone to comment on the 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.

-- 
Charles O'Hern
Network Operations

TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net


From info at arin.net  Thu Nov 18 18:09:06 2010
From: info at arin.net (ARIN)
Date: Thu, 18 Nov 2010 18:09:06 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future Policy
	Development
Message-ID: <4CE5B212.5060908@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

The ARIN Advisory Council (AC) will review the proposal at their next
regularly scheduled meeting (if the period before the next regularly
scheduled meeting is less than 10 days, then the period may be extended
to the subsequent regularly scheduled meeting). The AC will decide how
to utilize the proposal and announce the decision to the PPML.

The AC invites everyone to comment on the 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.

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 122: Reserved Pool for Future Policy Development

Proposal Originator: Martin Hannigan

Proposal Version: 1.0

Date: 18 Nov 2010

Proposal type: Delete, Temporary

Policy term: October 20, 2011 00:00 UTC

Policy statement:

Upon receipt of the last /8 that the IANA will allocate to ARIN per the
Global Policy for the Allocation of the Remaining IPv4 Address Space,
ARIN will place a contiguous /10 in a reserved pool for a use to be
determined at a later date. If adopted, this proposal will delete
Section 4.10 permanently and then expire per the policy term.

Rationale:

During the attempted fix of Section 4.10 we had consensus that 4.10 was
insufficient and potentially damaging and unbalanced with respect to
transition efforts.  This will provide for time to review  our current
depletion strategy and improve upon it to the benefit of the entire
community.

Timetable for implementation: Immediate




From owen at delong.com  Thu Nov 18 18:27:47 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 18 Nov 2010 15:27:47 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <4CE5B212.5060908@arin.net>
References: <4CE5B212.5060908@arin.net>
Message-ID: <39038A59-18AA-459C-99C1-68192B432C40@delong.com>

I oppose this policy. I do not agree that there was consensus that the
existing 4.10 was potentially damaging. There was consensus that
the proposal in question which attempted to carve off a little piece of
pony for all the various stakeholders was not an improvement over
the existing 4.10.

This proposal is far too little far too late.

Owen

On Nov 18, 2010, at 3:09 PM, ARIN wrote:

> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
> 
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
> 
> The AC invites everyone to comment on the 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.
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal 122: Reserved Pool for Future Policy Development
> 
> Proposal Originator: Martin Hannigan
> 
> Proposal Version: 1.0
> 
> Date: 18 Nov 2010
> 
> Proposal type: Delete, Temporary
> 
> Policy term: October 20, 2011 00:00 UTC
> 
> Policy statement:
> 
> Upon receipt of the last /8 that the IANA will allocate to ARIN per the
> Global Policy for the Allocation of the Remaining IPv4 Address Space,
> ARIN will place a contiguous /10 in a reserved pool for a use to be
> determined at a later date. If adopted, this proposal will delete
> Section 4.10 permanently and then expire per the policy term.
> 
> Rationale:
> 
> During the attempted fix of Section 4.10 we had consensus that 4.10 was
> insufficient and potentially damaging and unbalanced with respect to
> transition efforts.  This will provide for time to review  our current
> depletion strategy and improve upon it to the benefit of the entire
> community.
> 
> 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 gary.buhrmaster at gmail.com  Thu Nov 18 19:20:07 2010
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 19 Nov 2010 00:20:07 +0000
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <4CE5B212.5060908@arin.net>
References: <4CE5B212.5060908@arin.net>
Message-ID: <AANLkTinSLCcD5d8NHRAEiZZ88ssGhBea0KN+h8d+40xa@mail.gmail.com>

On Thu, Nov 18, 2010 at 23:09, ARIN <info at arin.net> wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
...
> Policy Proposal 122: Reserved Pool for Future Policy Development

While I can see the appeal of saving the last space "just in case",
I would only consider supporting a reserved pool if it came with
a (not too far out) sunset date after which any reserved pool would
return to (unreserved) normal status if no follow up policy proposal
could achieve consensus.  One should not get unlimited trips
(and time) to the trough while others have a documented need
for the resources.

Gary


From marty at akamai.com  Thu Nov 18 19:36:34 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 18 Nov 2010 19:36:34 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <AANLkTinSLCcD5d8NHRAEiZZ88ssGhBea0KN+h8d+40xa@mail.gmail.com>
Message-ID: <C90B8522.17F17%marty@akamai.com>



Gary,

Agreed, I set an expiration on the proposal of 20 OCT 2011. If no work was
done on it and we didn't reach consensus, it would expire and the addresses
would go back into the free pool.

I also want to note that this would be an emergency request due to the fact
that exhaustion is now. We are _not_ going to make it to the next meeting.


Steve Ryan, ARIN Counsel:

"The date, frankly, is about to hit you in the head, and it's in January.
And in all likelihood that's when the trigger will occur. You know right now
when the date is. And it could come faster, by the way. It could come very
much faster, depending on the drawdown rate. The drawdown rate is
increasing, not slowing. And, therefore, I don't think we should spend any
energy."




On 11/19/10 1:20 AM, "Gary Buhrmaster" <gary.buhrmaster at gmail.com> wrote:

> On Thu, Nov 18, 2010 at 23:09, ARIN <info at arin.net> wrote:
>> ARIN received the following policy proposal and is posting it to the
>> Public Policy Mailing List (PPML) in accordance with the Policy
>> Development Process.
> ...
>> Policy Proposal 122: Reserved Pool for Future Policy Development
> 
> While I can see the appeal of saving the last space "just in case",
> I would only consider supporting a reserved pool if it came with
> a (not too far out) sunset date after which any reserved pool would
> return to (unreserved) normal status if no follow up policy proposal
> could achieve consensus.  One should not get unlimited trips
> (and time) to the trough while others have a documented need
> for the resources.
> 
> Gary
> _______________________________________________
> 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 Nov 18 19:46:39 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 18 Nov 2010 16:46:39 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <AANLkTinSLCcD5d8NHRAEiZZ88ssGhBea0KN+h8d+40xa@mail.gmail.com>
References: <4CE5B212.5060908@arin.net>
	<AANLkTinSLCcD5d8NHRAEiZZ88ssGhBea0KN+h8d+40xa@mail.gmail.com>
Message-ID: <20101119004639.GA88752@ussenterprise.ufp.org>

In a message written on Fri, Nov 19, 2010 at 12:20:07AM +0000, Gary Buhrmaster wrote:
> While I can see the appeal of saving the last space "just in case",
> I would only consider supporting a reserved pool if it came with
> a (not too far out) sunset date after which any reserved pool would
> return to (unreserved) normal status if no follow up policy proposal
> could achieve consensus.  One should not get unlimited trips
> (and time) to the trough while others have a documented need
> for the resources.

I realize that there is more than one can of worms behind "worthy
uses" for the space.  I can see and make arguments for all sorts
of different boundaries on both the pro and con side.

That said, we alrady have one boundry set in policy, and I think
it is a useful one.  "Critical internet infrastructure", namely
exchange points and root name servers have special policy today
because in several ways they are unique animals.

They are growing, but both sets at a fairly small rate of space.
The inability to turn up new instances of either will mean a reduced
level of service for the IPv4 Internet.

I oppose this policy and think we should keep the /10 sitting around
because something will come up, and I think we'll be glad we did.  That
said, I might be able to get onboard with making the block reserved
smaller, but I feel we need to at least hold something in reserve for
critical infrastructure.

Disclaimer, I work for a company that uses the critical infrastructure
policy to deploy a root name server.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101118/f8d2f176/attachment.sig>

From marty at akamai.com  Thu Nov 18 20:21:37 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 18 Nov 2010 20:21:37 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <20101119004639.GA88752@ussenterprise.ufp.org>
Message-ID: <C90B8FB1.17F2B%marty@akamai.com>




On 11/19/10 1:46 AM, "Leo Bicknell" <bicknell at ufp.org> wrote:


[ snip ]

> I oppose this policy and think we should keep the /10 sitting around
> because something will come up, and I think we'll be glad we did.  That
> said, I might be able to get onboard with making the block reserved
> smaller, but I feel we need to at least hold something in reserve for
> critical infrastructure.


I agree, but the way that this is written incents [you] to participate and
to become a part of the solution. Right now, I see [you] as part of the
problem. You have a comfortable landing, more so than the rest of us. I
think this is another demonstration of how broken this is.

Best,

-M<

 



From bicknell at ufp.org  Thu Nov 18 20:40:49 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 18 Nov 2010 17:40:49 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C90B8FB1.17F2B%marty@akamai.com>
References: <20101119004639.GA88752@ussenterprise.ufp.org>
	<C90B8FB1.17F2B%marty@akamai.com>
Message-ID: <20101119014049.GA91450@ussenterprise.ufp.org>

In a message written on Thu, Nov 18, 2010 at 08:21:37PM -0500, Hannigan, Martin wrote:
> I agree, but the way that this is written incents [you] to participate and
> to become a part of the solution. Right now, I see [you] as part of the
> problem. You have a comfortable landing, more so than the rest of us. I
> think this is another demonstration of how broken this is.

You're implying there is some pain to me, but that is not the case.

If we can't get IPv4 space to deploy more sites we will deploy IPv6
only instances.  That doesn't cause me any pain, indeed it cuts my
work in half.  If anything it makes my life easier.  There are
already plenty of root servers (not just ours) to handle the load
well into the future, what is being limited here is the ability to
reduce latency to root servers (in my case, or the nearest exchange
point).

What it does mean is that there will be less incentive for our
partners and sponsors to deploy more root nodes.  You might think
that was "pain" for us, but we don't sell instances and many end
up costing us money.

So the folks that are being hurt here are folks in areas that are
under-served by root servers or exchange points.

Now with all that said, the main reason we need the /10 is not
critical infrastructure.  The real reason is I'm sure somewhere in
this transition mess there will be a new problem.  I don't know if
it will be needed for transition technology or some form of critical
infrastructure, or what.

Now, if you want my input, here it is:

- We keep the /10 "off limits" to everyone through "run out", as
  is I believe already the current policy.

- We wait a minimum of 6 months, and probably more like 12-18 months to
  see what unforseen problems occur around run-out, and if they need
  space.

- If after that time there are critical issues, we write policy to
  allocate the space in ways that solve the problems.

  If thre are no unforseen problems we set aside a very small amount
  for critical infrastructure (on the order of a /18-/20 would be my
  guess) and hand out the rest via normal mechanisms.

I will admit I'm biased here, but I'm trying hard to be objective and
work in the best interest of the community, and I feel pretty strongly
the plan I've outlined above does that.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101118/674ccea5/attachment.sig>

From marty at akamai.com  Thu Nov 18 21:14:11 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 18 Nov 2010 21:14:11 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <20101119014049.GA91450@ussenterprise.ufp.org>
Message-ID: <C90B9C03.17F54%marty@akamai.com>




On 11/19/10 2:40 AM, "Leo Bicknell" <bicknell at ufp.org> wrote:

> In a message written on Thu, Nov 18, 2010 at 08:21:37PM -0500, Hannigan,
> Martin wrote:


[ clip ]
 
> Now, if you want my input, here it is:
> 
> - We keep the /10 "off limits" to everyone through "run out", as
>   is I believe already the current policy.
> 

> - We wait a minimum of 6 months, and probably more like 12-18 months to
>   see what unforseen problems occur around run-out, and if they need
>   space.

The term on this is some number of months away. I doubt that we'll have
something worked out before the next meeting that will reset the expiration.
I think it's important to start the discussion and don't see why we can't do
that with this. 20 OCT 2011 is ~11 months away.

> 
> - If after that time there are critical issues, we write policy to
>   allocate the space in ways that solve the problems.

[ .. ] 

>   If thre are no unforseen problems we set aside a very small amount
>   for critical infrastructure (on the order of a /18-/20 would be my
>   guess) and hand out the rest via normal mechanisms.

OK.


Best,

-M<




From owen at delong.com  Fri Nov 19 02:30:20 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 18 Nov 2010 23:30:20 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <AANLkTinSLCcD5d8NHRAEiZZ88ssGhBea0KN+h8d+40xa@mail.gmail.com>
References: <4CE5B212.5060908@arin.net>
	<AANLkTinSLCcD5d8NHRAEiZZ88ssGhBea0KN+h8d+40xa@mail.gmail.com>
Message-ID: <A93FAD9F-E082-45F7-8E24-5DC24B84E140@delong.com>


On Nov 18, 2010, at 4:20 PM, Gary Buhrmaster wrote:

> On Thu, Nov 18, 2010 at 23:09, ARIN <info at arin.net> wrote:
>> ARIN received the following policy proposal and is posting it to the
>> Public Policy Mailing List (PPML) in accordance with the Policy
>> Development Process.
> ...
>> Policy Proposal 122: Reserved Pool for Future Policy Development
> 
> While I can see the appeal of saving the last space "just in case",
> I would only consider supporting a reserved pool if it came with
> a (not too far out) sunset date after which any reserved pool would
> return to (unreserved) normal status if no follow up policy proposal
> could achieve consensus.  One should not get unlimited trips
> (and time) to the trough while others have a documented need
> for the resources.
> 
This policy proposal provides for that to happen in 2011 (although
understanding this requires a careful reading of the proposal).

What this policy also does is prevent anyone from using the 4.10
reserved space as it was intended in the 4.10 policy and requires
a full additional policy cycle to create new terms under which it
can be used.

I think that reserving space for IPv6 transitional mechanisms makes
sense. I think that translating that into the need for new policy
to be rushed through the policy process or the space reverts
to general usage is short sighted and harmful.

Owen



From gbonser at seven.com  Fri Nov 19 02:39:43 2010
From: gbonser at seven.com (George Bonser)
Date: Thu, 18 Nov 2010 23:39:43 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C90B9C03.17F54%marty@akamai.com>
References: <20101119014049.GA91450@ussenterprise.ufp.org>
	<C90B9C03.17F54%marty@akamai.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14CA71@RWC-EX1.corp.seven.com>


> 
> The term on this is some number of months away. I doubt that we'll
have
> something worked out before the next meeting that will reset the
> expiration.
> I think it's important to start the discussion and don't see why we
> can't do
> that with this. 20 OCT 2011 is ~11 months away.

That whole Class E thing looks kinda silly now, doesn't it?

I wonder how much utility a "strategic IP reserve" would be considering
that there are bazillions of IPs available in v6 space.  I think I would
favor more of a "tough love" approach and when they are gone, they are
just plain gone.

Having those addresses in reserve is going to be nothing but a drama
generator, I think.  It is like storing up one truck load of grain for a
city the size of NY in the middle of a scarcity.  It is going to start a
fight and bickering and people demanding some of that space and each one
of them believing they are justified in having some of it.

I would lean against any "special" reserve.






From owen at delong.com  Fri Nov 19 03:00:48 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 19 Nov 2010 00:00:48 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14CA71@RWC-EX1.corp.seven.com>
References: <20101119014049.GA91450@ussenterprise.ufp.org>
	<C90B9C03.17F54%marty@akamai.com>
	<5A6D953473350C4B9995546AFE9939EE0B14CA71@RWC-EX1.corp.seven.com>
Message-ID: <80A12D62-F0A1-48C9-BA18-9CDC93ECE5FD@delong.com>


On Nov 18, 2010, at 11:39 PM, George Bonser wrote:

> 
>> 
>> The term on this is some number of months away. I doubt that we'll
> have
>> something worked out before the next meeting that will reset the
>> expiration.
>> I think it's important to start the discussion and don't see why we
>> can't do
>> that with this. 20 OCT 2011 is ~11 months away.
> 
> That whole Class E thing looks kinda silly now, doesn't it?
> 
> I wonder how much utility a "strategic IP reserve" would be considering
> that there are bazillions of IPs available in v6 space.  I think I would
> favor more of a "tough love" approach and when they are gone, they are
> just plain gone.
> 
> Having those addresses in reserve is going to be nothing but a drama
> generator, I think.  It is like storing up one truck load of grain for a
> city the size of NY in the middle of a scarcity.  It is going to start a
> fight and bickering and people demanding some of that space and each one
> of them believing they are justified in having some of it.
> 
> I would lean against any "special" reserve.
> 

George, a point of clarification:

1.	Current status: There is a /10 reserved for IPv6 transitional
	technologies. Essentially this is intended to provide numbers
	for things like NAT64 gateways and the like.

2.	This proposal would take away the ability to use the /10 for
	transitional technologies. It would not establish criteria in
	there place. It would hold the /10 in reserve until October, 2011
	and then put it back into the normal free pool.

The theory offered by the proposer is that this creates an
opportunity for us to develop policy over the next 11 months
to better address the best use of that reserved space.

In my opinion, we have done spectacularly poorly when we
have attempted to rush policy changes in the best of
circumstances and this would create a need to rush a
contentious policy forward to consensus against a tight
deadline or return the reservation to the general free pool.

I cannot speak to the author's intent, but, in my opinion, this
will effectively be a way to back-door a removal of the
reservation and return the 4.10 space to the general
free pool with an 11 month delay.

Owen



From gbonser at seven.com  Fri Nov 19 05:27:23 2010
From: gbonser at seven.com (George Bonser)
Date: Fri, 19 Nov 2010 02:27:23 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <80A12D62-F0A1-48C9-BA18-9CDC93ECE5FD@delong.com>
References: <20101119014049.GA91450@ussenterprise.ufp.org>
	<C90B9C03.17F54%marty@akamai.com>
	<5A6D953473350C4B9995546AFE9939EE0B14CA71@RWC-EX1.corp.seven.com>
	<80A12D62-F0A1-48C9-BA18-9CDC93ECE5FD@delong.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14CA78@RWC-EX1.corp.seven.com>

> >
> 
> George, a point of clarification:
> 
> 1.	Current status: There is a /10 reserved for IPv6 transitional
> 	technologies. Essentially this is intended to provide numbers
> 	for things like NAT64 gateways and the like.

How small of a chunk do you give to someone with a NAT64 gateway?  Is it
given to providers and aggregated or is it issued to end users?  If the
latter, how is that going to get routed?  If the former, that must then
assume that the end user's upstream has no more IPs to assign for such a
purpose (not even one v4 IP tunneled over v6!) out of their aggregate.

I imagine the way it is going to shake out is that the ISP is going to
say "here is your block of IPv6 addresses and here is ONE v4 IP you can
use to talk to the Obsonet."

That could become a big mess.

> 2.	This proposal would take away the ability to use the /10 for
> 	transitional technologies. It would not establish criteria in
> 	there place. It would hold the /10 in reserve until October,
2011
> 	and then put it back into the normal free pool.

Yeah, this is all going to be somewhat of a mess.  My little table clock
that gives me the weather and connects over the wireless in the house
doesn't know from v6.  When my provider changes to v6, my little weather
clock stops giving me the weather. A lot of little embedded gadgets
(picture frames?) are going to stop working when that happens.

Are any "transitional technologies" being developed?  I have an idea ...
how about "wholesale abandonment" as a transitional technology!  Now if
only I could get Cisco to support IPv6 in OSPF on my ASA5550 so I could
announce v6 VPN routes into my network ...

> The theory offered by the proposer is that this creates an
> opportunity for us to develop policy over the next 11 months
> to better address the best use of that reserved space.

I can understand that.  It sort of lights a fire under people to get
something done. But that can backfire if getting "something" done just
for the sake of it is the goal.

> 
> In my opinion, we have done spectacularly poorly when we
> have attempted to rush policy changes in the best of
> circumstances and this would create a need to rush a
> contentious policy forward to consensus against a tight
> deadline or return the reservation to the general free pool.

Agreed, make it 2012 and I might be more inclined to support it.  

> I cannot speak to the author's intent, but, in my opinion, this
> will effectively be a way to back-door a removal of the
> reservation and return the 4.10 space to the general
> free pool with an 11 month delay.
> 
> Owen

Yes, it would effectively throw that segment back into the pool
regardless of intent, of course that date could always be changed.

I am leaning against still.



From marty at akamai.com  Fri Nov 19 08:02:00 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 19 Nov 2010 08:02:00 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14CA71@RWC-EX1.corp.seven.com>
Message-ID: <C90C33D8.17FDC%marty@akamai.com>




On 11/19/10 8:39 AM, "George Bonser" <gbonser at seven.com> wrote:

> 
>> 
>> The term on this is some number of months away. I doubt that we'll
> have
>> something worked out before the next meeting that will reset the
>> expiration.
>> I think it's important to start the discussion and don't see why we
>> can't do
>> that with this. 20 OCT 2011 is ~11 months away.
> 
> That whole Class E thing looks kinda silly now, doesn't it?
> 
> I wonder how much utility a "strategic IP reserve" would be considering
> that there are bazillions of IPs available in v6 space.  I think I would
> favor more of a "tough love" approach and when they are gone, they are
> just plain gone.
> 


George, 

Have you read Section 4.10 of the NRPM?

    https://www.arin.net/policy/nrpm.html#four10

There's already a pool established. The mechanism for it's distribution is
what is in question. If we don't kill that before the last 5 /8's are
allocated from the IANA, it will be formally established and available.


Best,

-M<



From farmer at umn.edu  Fri Nov 19 08:54:11 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 19 Nov 2010 07:54:11 -0600
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <39038A59-18AA-459C-99C1-68192B432C40@delong.com>
References: <4CE5B212.5060908@arin.net>
	<39038A59-18AA-459C-99C1-68192B432C40@delong.com>
Message-ID: <4CE68183.7070108@umn.edu>

I also question the statement regarding the nature of the consensus that 
was reached regarding the current 4.10.  I will agree that there was 
consensus that the current 4.10 is "insufficient" and needs additional 
guidance provided to staff regarding what the community thinks is 
appropriate use of this reserved block.

But, I did not hear a consensus that the rational for 2008-5, which is 
now 4.10, was fundamentally wrong.  Or that we do not need to reserve a 
block of IPv4 for deployment of IPv6 by those that will not have any 
other IPv4 in the future.

https://www.arin.net/policy/proposals/2008_5.html

Therefore, I not sure there was a consensus that the current 4.10 is 
"potentially damaging and unbalanced with respect to transition efforts."

However, I would like the author of this proposal to further explain his 
view of the consensus that was reached, and how the current 4.10 is 
"potentially damaging and unbalanced with respect to transition efforts."

Do others support the author's view regarding the consensus that was 
reached or that the current 4.10 is damaging?

If we are going to revisit this issue again at this late date in terms 
of IPv4 run-out I would like to see a very strong show of support from 
the community to do so.  Without a strong show of support from the 
community to revisit this issue again, I believe that we should simply 
leave 4.10 as it is until staff has some implementation experience to 
report.


On 11/18/10 17:27 CST, Owen DeLong wrote:
> I oppose this policy. I do not agree that there was consensus that the
> existing 4.10 was potentially damaging. There was consensus that
> the proposal in question which attempted to carve off a little piece of
> pony for all the various stakeholders was not an improvement over
> the existing 4.10.
>
> This proposal is far too little far too late.
>
> Owen
>
> On Nov 18, 2010, at 3:09 PM, ARIN wrote:
...
>> Policy Proposal 122: Reserved Pool for Future Policy Development
>>
>> Proposal Originator: Martin Hannigan
>>
>> Proposal Version: 1.0
>>
>> Date: 18 Nov 2010
>>
>> Proposal type: Delete, Temporary
>>
>> Policy term: October 20, 2011 00:00 UTC
>>
>> Policy statement:
>>
>> Upon receipt of the last /8 that the IANA will allocate to ARIN per the
>> Global Policy for the Allocation of the Remaining IPv4 Address Space,
>> ARIN will place a contiguous /10 in a reserved pool for a use to be
>> determined at a later date. If adopted, this proposal will delete
>> Section 4.10 permanently and then expire per the policy term.
>>
>> Rationale:
>>
>> During the attempted fix of Section 4.10 we had consensus that 4.10 was
>> insufficient and potentially damaging and unbalanced with respect to
>> transition efforts.  This will provide for time to review  our current
>> depletion strategy and improve upon it to the benefit of the entire
>> community.
>>
>> Timetable for implementation: Immediate


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


From BillD at cait.wustl.edu  Fri Nov 19 09:30:56 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 19 Nov 2010 08:30:56 -0600
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <4CE68183.7070108@umn.edu>
References: <4CE5B212.5060908@arin.net><39038A59-18AA-459C-99C1-68192B432C40@delong.com>
	<4CE68183.7070108@umn.edu>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087B8DF7C@ex1.cait.wustl.edu>

+1 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
> Sent: Friday, November 19, 2010 7:54 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool 
> for Future Policy Development
> 
> I also question the statement regarding the nature of the 
> consensus that was reached regarding the current 4.10.  I 
> will agree that there was consensus that the current 4.10 is 
> "insufficient" and needs additional guidance provided to 
> staff regarding what the community thinks is appropriate use 
> of this reserved block.
> 
> But, I did not hear a consensus that the rational for 2008-5, 
> which is now 4.10, was fundamentally wrong.  Or that we do 
> not need to reserve a block of IPv4 for deployment of IPv6 by 
> those that will not have any other IPv4 in the future.
> 
> https://www.arin.net/policy/proposals/2008_5.html
> 
> Therefore, I not sure there was a consensus that the current 
> 4.10 is "potentially damaging and unbalanced with respect to 
> transition efforts."
> 
> However, I would like the author of this proposal to further 
> explain his view of the consensus that was reached, and how 
> the current 4.10 is "potentially damaging and unbalanced with 
> respect to transition efforts."
> 
> Do others support the author's view regarding the consensus 
> that was reached or that the current 4.10 is damaging?
> 
> If we are going to revisit this issue again at this late date 
> in terms of IPv4 run-out I would like to see a very strong 
> show of support from the community to do so.  Without a 
> strong show of support from the community to revisit this 
> issue again, I believe that we should simply leave 4.10 as it 
> is until staff has some implementation experience to report.
> 
> 
> On 11/18/10 17:27 CST, Owen DeLong wrote:
> > I oppose this policy. I do not agree that there was 
> consensus that the 
> > existing 4.10 was potentially damaging. There was consensus 
> that the 
> > proposal in question which attempted to carve off a little piece of 
> > pony for all the various stakeholders was not an 
> improvement over the 
> > existing 4.10.
> >
> > This proposal is far too little far too late.
> >
> > Owen
> >
> > On Nov 18, 2010, at 3:09 PM, ARIN wrote:
> ...
> >> Policy Proposal 122: Reserved Pool for Future Policy Development
> >>
> >> Proposal Originator: Martin Hannigan
> >>
> >> Proposal Version: 1.0
> >>
> >> Date: 18 Nov 2010
> >>
> >> Proposal type: Delete, Temporary
> >>
> >> Policy term: October 20, 2011 00:00 UTC
> >>
> >> Policy statement:
> >>
> >> Upon receipt of the last /8 that the IANA will allocate to 
> ARIN per 
> >> the Global Policy for the Allocation of the Remaining IPv4 Address 
> >> Space, ARIN will place a contiguous /10 in a reserved pool 
> for a use 
> >> to be determined at a later date. If adopted, this proposal will 
> >> delete Section 4.10 permanently and then expire per the 
> policy term.
> >>
> >> Rationale:
> >>
> >> During the attempted fix of Section 4.10 we had consensus 
> that 4.10 
> >> was insufficient and potentially damaging and unbalanced 
> with respect 
> >> to transition efforts.  This will provide for time to review  our 
> >> current depletion strategy and improve upon it to the 
> benefit of the 
> >> entire community.
> >>
> >> Timetable for implementation: Immediate
> 
> 
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota	
> 2218 University Ave SE	    Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> 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 Nov 19 10:47:29 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 19 Nov 2010 07:47:29 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C90C33D8.17FDC%marty@akamai.com>
References: <5A6D953473350C4B9995546AFE9939EE0B14CA71@RWC-EX1.corp.seven.com>
	<C90C33D8.17FDC%marty@akamai.com>
Message-ID: <20101119154729.GA50100@ussenterprise.ufp.org>

In a message written on Fri, Nov 19, 2010 at 08:02:00AM -0500, Hannigan, Martin wrote:
> There's already a pool established. The mechanism for it's distribution is
> what is in question. If we don't kill that before the last 5 /8's are
> allocated from the IANA, it will be formally established and available.

So basically this policy conflates two issues:

1) We may not want to use this space for transitional technologies after
   all, but some folks feel when the last 5 /8's trigger it we are
   "locked in".

2) If we don't use this space we want to return it to the free pool.

#2 is entirely premature.  We can't evauate if we need this space
for transition technlogies or any other IPv4->IPv6 transition
purposes until after runout and we see what happens.  Any discussion
before that is speculation.

I might accept that the first part is a problem, particularly to
the extent that we haven't (as far as I know) defined which "transition
technologies" qualify and to a lesser extent that we don't know for sure
that we want to use the space in that way.

Back to my comments from yesterday, if we want to fix #1 by changing
4.10 to hold the /10 in reserve with no way to allocate it for the time
being I would be ok with that, we can make the decision on how to
allocate it (including return to the free pool) after run out.

To the extent #2 sticks around, immediately, with a date, or whatever
it's a deal breaker for me, and kills this 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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101119/6cd85241/attachment.sig>

From info at arin.net  Fri Nov 19 10:47:48 2010
From: info at arin.net (ARIN)
Date: Fri, 19 Nov 2010 10:47:48 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure
Message-ID: <4CE69C24.9040807@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

The ARIN Advisory Council (AC) will review the proposal at their next
regularly scheduled meeting (if the period before the next regularly
scheduled meeting is less than 10 days, then the period may be extended
to the subsequent regularly scheduled meeting). The AC will decide how
to utilize the proposal and announce the decision to the PPML.

The AC invites everyone to comment on the 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.

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 123: Reserved Pool for Critical Infrastructure

Proposal Originator: Martin Hannigan

Proposal Version: 1.0

Date: 19 Nov 2010

Proposal type: Temporary

Policy term: October 20, 2011 00:00 UTC

Policy statement:

Upon receipt of the last /8 that the IANA will allocate to ARIN per the
Global Policy for the Allocation of the Remaining IPv4 Address Space,
ARIN will place a contiguous /20 in reserve for Critical Infrastructure.

Rationale:

During the attempted fix of Section 4.10 we had consensus that 4.10 was
insufficient and potentially damaging and unbalanced with respect to
transition efforts. In order to enable the community to work to fix this
problem in a responsible manner, we need to insure that we do not break
the Internet or cause unnecessary hardship or cost to underserved
markets. This policy will protect those resources with a reasonable
amount of reserved v4 address space.

This proposal should be considered an emergency proposal. IANA
exhaustion is likely to occur prior to the next ARIN meeting.

Timetable for implementation: Immediate





From bicknell at ufp.org  Fri Nov 19 11:01:31 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 19 Nov 2010 08:01:31 -0800
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure
In-Reply-To: <4CE69C24.9040807@arin.net>
References: <4CE69C24.9040807@arin.net>
Message-ID: <20101119160131.GA52309@ussenterprise.ufp.org>


Marty is coming out firing! :)

In a message written on Fri, Nov 19, 2010 at 10:47:48AM -0500, ARIN wrote:
> Upon receipt of the last /8 that the IANA will allocate to ARIN per the
> Global Policy for the Allocation of the Remaining IPv4 Address Space,
> ARIN will place a contiguous /20 in reserve for Critical Infrastructure.

It should be no surprise I support this policy in general, but I
have no idea if a /20 is the right size or not.

I'm wondering if ARIN staff can tell us how much space was allocated
under the critical infrastructure policy by year for the last 5
years?  Assuming the block wouldn't be huge, I'd like to try and
hit a target of at least 5 more years worth of space for critical
infrastructure.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101119/225ea683/attachment.sig>

From bill at herrin.us  Fri Nov 19 12:09:25 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 19 Nov 2010 12:09:25 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <4CE68183.7070108@umn.edu>
References: <4CE5B212.5060908@arin.net>
	<39038A59-18AA-459C-99C1-68192B432C40@delong.com>
	<4CE68183.7070108@umn.edu>
Message-ID: <AANLkTi=L0jY=XCxY-=GARMi63fmYYBi-YZEv2z5Gst7n@mail.gmail.com>

On Fri, Nov 19, 2010 at 8:54 AM, David Farmer <farmer at umn.edu> wrote:
> I also question the statement regarding the nature of the consensus that was
> reached regarding the current 4.10. ?I will agree that there was consensus
> that the current 4.10 is "insufficient" and needs additional guidance
> provided to staff regarding what the community thinks is appropriate use of
> this reserved block.

Hi David,

>From what I saw, opinion coalesced around two major points of view:

A. 4.10 as written will carelessly obstruct useful consumption of the
addresses. Just give the addresses out honestly until they're gone.

B. 4.10 as written will carelessly consume the reserved addresses.
These are the last ones. We should very carefully and very stingily
parcel them out.


I think Marty's proposal does an excellent job of balancing these two
points of view and I'm wholeheartedly for it. The vast majority of us
seem to agree that 4.10 doesn't get the job done, there's no point
trying to figure out how to parcel out addresses unless we make sure
there are addresses to parcel out, and if we can't come to a
conclusion on how to parcel them out within a reasonable amount of
time then we shouldn't continue sitting on them.


On Thu, Nov 18, 2010 at 7:36 PM, Hannigan, Martin <marty at akamai.com> wrote:
> I set an expiration on the proposal of 20 OCT 2011.

You missed a stitch here. Leave enough time following the October 2011
meeting for the proposal to go through last call and board adoption.
Maybe something like 1/1/2012 as the expiration date.

Regards,
Bill Herrin



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


From ndavis at arin.net  Fri Nov 19 14:33:17 2010
From: ndavis at arin.net (Nate Davis)
Date: Fri, 19 Nov 2010 14:33:17 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for
	Critical	Infrastructure
In-Reply-To: <20101119160131.GA52309@ussenterprise.ufp.org>
References: <4CE69C24.9040807@arin.net>
	<20101119160131.GA52309@ussenterprise.ufp.org>
Message-ID: <FEA070315E40A3489D38398C35FE7BB279DF55F49B@EDAMAME.arin.net>

As requested, here are the total /24s issued under the critical infrastructure policy for the last 5 years.

2004	8
2005	12
2006	16
2007	29
2008	57
2009	11
2010	70 (year to date)

Regards,

Nate Davis

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell
Sent: Friday, November 19, 2010 11:02 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical Infrastructure


Marty is coming out firing! :)

In a message written on Fri, Nov 19, 2010 at 10:47:48AM -0500, ARIN wrote:
> Upon receipt of the last /8 that the IANA will allocate to ARIN per 
> the Global Policy for the Allocation of the Remaining IPv4 Address 
> Space, ARIN will place a contiguous /20 in reserve for Critical Infrastructure.

It should be no surprise I support this policy in general, but I have no idea if a /20 is the right size or not.

I'm wondering if ARIN staff can tell us how much space was allocated under the critical infrastructure policy by year for the last 5 years?  Assuming the block wouldn't be huge, I'd like to try and hit a target of at least 5 more years worth of space for critical infrastructure.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/


From bill at herrin.us  Fri Nov 19 15:13:56 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 19 Nov 2010 15:13:56 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure
In-Reply-To: <FEA070315E40A3489D38398C35FE7BB279DF55F49B@EDAMAME.arin.net>
References: <4CE69C24.9040807@arin.net>
	<20101119160131.GA52309@ussenterprise.ufp.org>
	<FEA070315E40A3489D38398C35FE7BB279DF55F49B@EDAMAME.arin.net>
Message-ID: <AANLkTin2v9Qu=yruGJsYG4Pn4NmXGfhym+KsM_Sxsj_B@mail.gmail.com>

On Fri, Nov 19, 2010 at 2:33 PM, Nate Davis <ndavis at arin.net> wrote:
> As requested, here are the total /24s issued under the critical
> infrastructure policy for the last 5 years.
>
> 2004 ? ?8
> 2005 ? ?12
> 2006 ? ?16
> 2007 ? ?29
> 2008 ? ?57
> 2009 ? ?11
> 2010 ? ?70 (year to date)
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell
>
> I'm wondering if ARIN staff can tell us how much space was
> allocated under the critical infrastructure policy by year for
> the last 5 years? ?Assuming the block wouldn't be huge, I'd
> like to try and hit a target of at least 5 more years worth of space for critical infrastructure.


Thanks Nate. So if I'm reading this right, a 5-year supply would be a
/16 plus whatever buffer we want to add to accommodate folks who
qualify under critical infrastructure now but just use a regular /24
rather than bother with the ARIN process. Bump it up to a /15 or /14
in other words. A /20 could be as little as a 3 month supply.

Regards,
Bill Herrin




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


From bicknell at ufp.org  Fri Nov 19 15:30:49 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 19 Nov 2010 12:30:49 -0800
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure
In-Reply-To: <AANLkTin2v9Qu=yruGJsYG4Pn4NmXGfhym+KsM_Sxsj_B@mail.gmail.com>
References: <4CE69C24.9040807@arin.net>
	<20101119160131.GA52309@ussenterprise.ufp.org>
	<FEA070315E40A3489D38398C35FE7BB279DF55F49B@EDAMAME.arin.net>
	<AANLkTin2v9Qu=yruGJsYG4Pn4NmXGfhym+KsM_Sxsj_B@mail.gmail.com>
Message-ID: <20101119203049.GA73760@ussenterprise.ufp.org>

In a message written on Fri, Nov 19, 2010 at 03:13:56PM -0500, William Herrin wrote:
> On Fri, Nov 19, 2010 at 2:33 PM, Nate Davis <ndavis at arin.net> wrote:
> > 2004 ? ?8
> > 2005 ? ?12
> > 2006 ? ?16
> > 2007 ? ?29
> > 2008 ? ?57
> > 2009 ? ?11
> > 2010 ? ?70 (year to date)
> 
> Thanks Nate. So if I'm reading this right, a 5-year supply would be a
> /16 plus whatever buffer we want to add to accommodate folks who
> qualify under critical infrastructure now but just use a regular /24
> rather than bother with the ARIN process. Bump it up to a /15 or /14
> in other words. A /20 could be as little as a 3 month supply.

On straight math, you're right...

(8 + 12 + 16 + 29 + 57 + 11 + 70) / 7 = 29 per year, average.  5
years worth is 145 /24's.  A /16 is 256, the next amount larger.

But a /17 (128 /24's) would translate to four and a half years, so
going to a /15 or /14 seems a bit uncalled for to me.

To me a 16 or 17 would be the right number, but could probably
support anything from a 15 to an 18 without too much fuss.

We also need to be sure the wording here allows for discontiguous
space, we don't need a /16 all together.  If ARIN has dribs and
drabs of /24's this is a /perfect/ use for them, while not all
micro-allocations are /24's I think that's by far the largest number
and they are generally used in non-aggregatable ways.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101119/0625e044/attachment.sig>

From bill at herrin.us  Fri Nov 19 15:58:36 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 19 Nov 2010 15:58:36 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure
In-Reply-To: <20101119203049.GA73760@ussenterprise.ufp.org>
References: <4CE69C24.9040807@arin.net>
	<20101119160131.GA52309@ussenterprise.ufp.org>
	<FEA070315E40A3489D38398C35FE7BB279DF55F49B@EDAMAME.arin.net>
	<AANLkTin2v9Qu=yruGJsYG4Pn4NmXGfhym+KsM_Sxsj_B@mail.gmail.com>
	<20101119203049.GA73760@ussenterprise.ufp.org>
Message-ID: <AANLkTinLye7AVLaHP_0pbJmUywJ-6U6DcVZTtEgEHBs6@mail.gmail.com>

On Fri, Nov 19, 2010 at 3:30 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> We also need to be sure the wording here allows for discontiguous
> space, we don't need a /16 all together. ?If ARIN has dribs and
> drabs of /24's this is a /perfect/ use for them, while not all
> micro-allocations are /24's I think that's by far the largest number
> and they are generally used in non-aggregatable ways.

Hi Leo,

I concur, but if you'll pardon me waxing a tad pedantic there are some
arguments for the other side of that coin: If someone decided they
wanted to filtering on /22 and /23 boundaries for some reason,
grouping critical infrastructure together would allow that individual
to avoid dropping routes for networks considered critical
infrastructure.

Practically speaking, though, nobody is going to start filtering IPv4
on boundaries other than /24. Tried it. Didn't work out.

Regards,
Bill Herrin



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


From marty at akamai.com  Fri Nov 19 17:42:37 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 19 Nov 2010 17:42:37 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087B8DF7C@ex1.cait.wustl.edu>
Message-ID: <C90CBBED.180C7%marty@akamai.com>




On 11/19/10 3:30 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:

> +1 

  I 
>> will agree that there was consensus that the current 4.10 is
>> "insufficient" 

Thank you, Bill. And if you think that this is out of context, let me know.

-M<



From marty at akamai.com  Fri Nov 19 17:46:28 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 19 Nov 2010 17:46:28 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <20101119154729.GA50100@ussenterprise.ufp.org>
Message-ID: <C90CBCD4.180CC%marty@akamai.com>




On 11/19/10 4:47 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:

> In a message written on Fri, Nov 19, 2010 at 08:02:00AM -0500, Hannigan,
> Martin wrote:
>> There's already a pool established. The mechanism for it's distribution is
>> what is in question. If we don't kill that before the last 5 /8's are
>> allocated from the IANA, it will be formally established and available.
> 
> So basically this policy conflates two issues:
> 
> 1) We may not want to use this space for transitional technologies after
>    all, but some folks feel when the last 5 /8's trigger it we are
>    "locked in".

Well, sorta. We want to use this for transition.

> 
> 2) If we don't use this space we want to return it to the free pool.


No. We want to use it for transition. I made this temporary so that there
was an implied pressure to do something rational _and_ to cooperate. The
expiration would hopefully make everyone have an "oh heck" moment and work
together. At least I hope. We should be able to [wo]man up and find a
methodology that is not "insufficient".


Best,

-M<





From marty at akamai.com  Fri Nov 19 17:52:06 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 19 Nov 2010 17:52:06 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
 Infrastructure
In-Reply-To: <20101119160131.GA52309@ussenterprise.ufp.org>
Message-ID: <C90CBE26.180D3%marty@akamai.com>




On 11/19/10 5:01 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:

> 
> Marty is coming out firing! :)
> 
> In a message written on Fri, Nov 19, 2010 at 10:47:48AM -0500, ARIN wrote:
>> Upon receipt of the last /8 that the IANA will allocate to ARIN per the
>> Global Policy for the Allocation of the Remaining IPv4 Address Space,
>> ARIN will place a contiguous /20 in reserve for Critical Infrastructure.
> 
> It should be no surprise I support this policy in general, but I
> have no idea if a /20 is the right size or not.

Two additional thoughts. First, does this need to be contiguous? Second, we
should probably make this permanent. There's a risk that CI needs will be
overrun if 4.10 survives or if we fail to act by 20 OCT 2011 on Prop 122.

Best,

-M< 



From marty at akamai.com  Fri Nov 19 18:00:18 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 19 Nov 2010 18:00:18 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <AANLkTi=L0jY=XCxY-=GARMi63fmYYBi-YZEv2z5Gst7n@mail.gmail.com>
Message-ID: <C90CC012.180D8%marty@akamai.com>




On 11/19/10 6:09 PM, "William Herrin" <bill at herrin.us> wrote:


[ clip ]

> On Thu, Nov 18, 2010 at 7:36 PM, Hannigan, Martin <marty at akamai.com> wrote:
>> I set an expiration on the proposal of 20 OCT 2011.
> 
> You missed a stitch here. Leave enough time following the October 2011
> meeting for the proposal to go through last call and board adoption.
> Maybe something like 1/1/2012 as the expiration date.


Hi Bill,

I made it 20 OCT since the ARIN Philly meeting is 12-14 October 2011. My
intention is to make sure that the pressure is on the AC and the BoT to make
this happen. Soon, we lose control of the proposal and have little sway over
what happens to it. I don't see another way to make sure that we get
something done. 

I'm open to modifications.


Best Regards,

-M<



From bill at herrin.us  Fri Nov 19 18:19:43 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 19 Nov 2010 18:19:43 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C90CC012.180D8%marty@akamai.com>
References: <AANLkTi=L0jY=XCxY-=GARMi63fmYYBi-YZEv2z5Gst7n@mail.gmail.com>
	<C90CC012.180D8%marty@akamai.com>
Message-ID: <AANLkTinKxxw4K4t9FY=VDXG0XPqxWbZDn1z+Cah39cuX@mail.gmail.com>

On Fri, Nov 19, 2010 at 6:00 PM, Hannigan, Martin <marty at akamai.com> wrote:
> On 11/19/10 6:09 PM, "William Herrin" <bill at herrin.us> wrote:
>> On Thu, Nov 18, 2010 at 7:36 PM, Hannigan, Martin <marty at akamai.com> wrote:
>>> I set an expiration on the proposal of 20 OCT 2011.
>>
>> You missed a stitch here. Leave enough time following the October 2011
>> meeting for the proposal to go through last call and board adoption.
>> Maybe something like 1/1/2012 as the expiration date.
>
> I made it 20 OCT since the ARIN Philly meeting is 12-14 October 2011.

Exactly my point. Assuming we have consensus at Philly, it isn't
possible to do a last call and board ratification in 6 days. First the
AC has to meet and vote to move it to last call. Then it has to be
posted to last call. Then we wait for folks to comment. Then the AC
has to meet again and vote to recommend the draft to the board. Then
the board has to meet and actually ratify the policy.

If the timer runs out before the board ratifies the replacement
policy, you've created a process problem we didn't need to have where
the board has to enact some sort of emergency extension in the middle
of folks commenting on last call. So if you want Philly to be the last
chance to select a use policy for the reserved addresses, pick a date
far enough after Philly for the process to run to conclusion.

Like 1/1/2012.

Regards,
Bill Herrin



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


From marty at akamai.com  Fri Nov 19 19:07:14 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Fri, 19 Nov 2010 19:07:14 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <AANLkTinKxxw4K4t9FY=VDXG0XPqxWbZDn1z+Cah39cuX@mail.gmail.com>
Message-ID: <C90CCFC2.180FA%marty@akamai.com>




On 11/20/10 12:19 AM, "William Herrin" <bill at herrin.us> wrote:

> On Fri, Nov 19, 2010 at 6:00 PM, Hannigan, Martin <marty at akamai.com> wrote:
>> On 11/19/10 6:09 PM, "William Herrin" <bill at herrin.us> wrote:
>>> On Thu, Nov 18, 2010 at 7:36 PM, Hannigan, Martin <marty at akamai.com> wrote:
>>>> I set an expiration on the proposal of 20 OCT 2011.
>>> 
>>> You missed a stitch here. Leave enough time following the October 2011
>>> meeting for the proposal to go through last call and board adoption.
>>> Maybe something like 1/1/2012 as the expiration date.
>> 
>> I made it 20 OCT since the ARIN Philly meeting is 12-14 October 2011.
> 
> Exactly my point. Assuming we have consensus at Philly, it isn't
> possible to do a last call and board ratification in 6 days. First the
> AC has to meet and vote to move it to last call. Then it has to be
> posted to last call. Then we wait for folks to comment. Then the AC
> has to meet again and vote to recommend the draft to the board. Then
> the board has to meet and actually ratify the policy.


I agree. My date was deliberate though. I don't want to drag this out to
Philly as we risk being exhausted by then. It would be bad to have addresses
being held and have need in the region. I'm certain that we'd be exposed
legally if we were to have that condition. Still, I am willing to modify
this date if people feel strongly about it. How about pulling it into Puerto
Rico plus adequate process time and making proposal 123 separate and
permanent?


Best,

-M<




From bill at herrin.us  Fri Nov 19 19:27:05 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 19 Nov 2010 19:27:05 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C90CCFC2.180FA%marty@akamai.com>
References: <AANLkTinKxxw4K4t9FY=VDXG0XPqxWbZDn1z+Cah39cuX@mail.gmail.com>
	<C90CCFC2.180FA%marty@akamai.com>
Message-ID: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com>

On Fri, Nov 19, 2010 at 7:07 PM, Hannigan, Martin <marty at akamai.com> wrote:
> I agree. My date was deliberate though. I don't want to drag this out to
> Philly as we risk being exhausted by then.

Then don't. Close the window in August, well before Philly. Pick which
meeting you want to be the last chance for community consensus and
close the window just enough time later for a draft policy to have
gone through last call and ratification. Don't drag the deadline out
to the close of the following meeting.

Regards,
Bill




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


From warren at wholesaleinternet.com  Fri Nov 19 21:40:38 2010
From: warren at wholesaleinternet.com (Warren Johnson)
Date: Fri, 19 Nov 2010 20:40:38 -0600
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for
	Future	Policy Development
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14CA78@RWC-EX1.corp.seven.com>
References: <20101119014049.GA91450@ussenterprise.ufp.org>	<C90B9C03.17F54%marty@akamai.com>	<5A6D953473350C4B9995546AFE9939EE0B14CA71@RWC-EX1.corp.seven.com>	<80A12D62-F0A1-48C9-BA18-9CDC93ECE5FD@delong.com>
	<5A6D953473350C4B9995546AFE9939EE0B14CA78@RWC-EX1.corp.seven.com>
Message-ID: <0a0501cb885c$52a93220$f7fb9660$@com>

It seems to me that when there is no longer any IP addresses, we have the
potential for a lot of wrangling over the "proper" usage of that reserve.
Consequently, we could end up with a long protracted debate and not pass
proper policy before the expiration date.  At which point, they go back into
the pool and get distributed in one day to the expected backlog, making the
whole thing a pointless exercise.  There is also the potential for abuse in
that an interested party or parties on the waiting-list could stall the
whole process in order to let the addresses expire and be returned to the
pool.  I would recommend adding a provision worded something like this:

In absence of policy dictating "proper" usage for the reserve pool, the
expiration date for reserve pool shall be automatically renewed each month,
for a period of one month, starting at its expiration date as defined in
this proposal.






> I cannot speak to the author's intent, but, in my opinion, this
> will effectively be a way to back-door a removal of the
> reservation and return the 4.10 space to the general
> free pool with an 11 month delay.
> 
> Owen

Yes, it would effectively throw that segment back into the pool
regardless of intent, of course that date could always be changed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3414 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101119/0aa4ae93/attachment.bin>

From info at arin.net  Sat Nov 20 15:04:46 2010
From: info at arin.net (ARIN)
Date: Sat, 20 Nov 2010 15:04:46 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
 Infrastructure - revised
Message-ID: <4CE829DE.5090608@arin.net>

The proposal originator submitted revised text.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 123: Reserved Pool for Critical Infrastructure

Proposal Originator: Martin Hannigan

Proposal Version: 2.0

Date: 20 Nov 2010

Proposal type: Modify

Policy term: 36 Months from Implementation

Policy statement:

Upon receipt of the last /8 that the IANA will allocate to ARIN per the
Global Policy for the Allocation of the Remaining IPv4 Address Space,
ARIN will place a contiguous /16 in reserve for Critical Infrastructure.
If at the end of the policy term there is unused address space remaining
in this pool, ARIN staff is authorized to utilize this space in a manner
consistent with community expectations.

Rationale:

During the recent attempted fix of Section 4.10 we had consensus that
4.10 was insufficient and potentially damaging and unbalanced with
respect to transition efforts. In order to enable the community to work
to fix this problem in a responsible manner, we need to insure that we
do not break the Internet or cause unnecessary hardship and cost. This
policy will protect those resources with a reasonable amount of reserved
v4 address space and prevent a possible overrun of CI needs by NRPM
Section 4.10 or any succesor. The intent is to separate CI needs and
make a distinct pool available to insure v4 continuity for CI for at
least 36 months.

This proposal should be considered an emergency proposal. IANA
exhaustion is likely to occur prior to the next ARIN meeting.

Timetable for implementation: Immediate









From bill at herrin.us  Sat Nov 20 15:18:13 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 20 Nov 2010 15:18:13 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
 Infrastructure - revised
In-Reply-To: <4CE829DE.5090608@arin.net>
References: <4CE829DE.5090608@arin.net>
Message-ID: <AANLkTi=rvL+wGVHTyROj08jzUWPKooKgYjYTO1HYLrj9@mail.gmail.com>

On Sat, Nov 20, 2010 at 3:04 PM, ARIN <info at arin.net> wrote:
> Policy Proposal 123: Reserved Pool for Critical Infrastructure
>
> Policy term: 36 Months from Implementation

Nitpick: For 36 months following implementation.

The other way could be misunderstood to mean "starts 36 months later."


> Upon receipt of the last /8 that the IANA will allocate to ARIN per the
> Global Policy for the Allocation of the Remaining IPv4 Address Space,
> ARIN will place a contiguous /16 in reserve for Critical Infrastructure.
> If at the end of the policy term there is unused address space remaining
> in this pool, ARIN staff is authorized to utilize this space in a manner
> consistent with community expectations.

I'm not sure its necessary to have a contiguous reserve, but I SUPPORT
the policy proposal as written anyway.

Regards,
Bill Herrin





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


From marty at akamai.com  Sun Nov 21 14:07:55 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Sun, 21 Nov 2010 14:07:55 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
 Infrastructure - revised
In-Reply-To: <AANLkTi=rvL+wGVHTyROj08jzUWPKooKgYjYTO1HYLrj9@mail.gmail.com>
Message-ID: <C90F2C9B.181FE%marty@akamai.com>




On 11/20/10 9:18 PM, "William Herrin" <bill at herrin.us> wrote:

> On Sat, Nov 20, 2010 at 3:04 PM, ARIN <info at arin.net> wrote:
>> Policy Proposal 123: Reserved Pool for Critical Infrastructure
>> 
>> Policy term: 36 Months from Implementation
> 
> Nitpick: For 36 months following implementation.
> 
> The other way could be misunderstood to mean "starts 36 months later."

Ok.

>> Upon receipt of the last /8 that the IANA will allocate to ARIN per the
>> Global Policy for the Allocation of the Remaining IPv4 Address Space,
>> ARIN will place a contiguous /16 in reserve for Critical Infrastructure.
>> If at the end of the policy term there is unused address space remaining
>> in this pool, ARIN staff is authorized to utilize this space in a manner
>> consistent with community expectations.
> 
> I'm not sure its necessary to have a contiguous reserve, but I SUPPORT
> the policy proposal as written anyway.


I thought about this and then saw Leo's post. Removing the word contiguous
should be good enough.

I can't think of any other requirements with respect to CI and leaving this
fairly open will leave the staff a healthy amount of discretion.

Anything else need to be done with this? Any disagreement with respect to
this being pushed forward as an emergency proposal?

 
Best,

-M<





From scottleibrand at gmail.com  Sun Nov 21 14:53:35 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Sun, 21 Nov 2010 11:53:35 -0800
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure - revised
In-Reply-To: <C90F2C9B.181FE%marty@akamai.com>
References: <C90F2C9B.181FE%marty@akamai.com>
Message-ID: <82D2C600-7FB9-4E9A-BE22-A0D346A1D594@gmail.com>

Is this policy is only really needed if we pass 122? As I read it, CI needs can be met under 4.10. 

I agree this is needed if we pass 122, but wondering if there's reason to pass 123 as a standalone policy (as it seems a lot less controversial). 

Thanks,
Scott

On Nov 21, 2010, at 11:07 AM, "Hannigan, Martin" <marty at akamai.com> wrote:

> 
> 
> 
> On 11/20/10 9:18 PM, "William Herrin" <bill at herrin.us> wrote:
> 
>> On Sat, Nov 20, 2010 at 3:04 PM, ARIN <info at arin.net> wrote:
>>> Policy Proposal 123: Reserved Pool for Critical Infrastructure
>>> 
>>> Policy term: 36 Months from Implementation
>> 
>> Nitpick: For 36 months following implementation.
>> 
>> The other way could be misunderstood to mean "starts 36 months later."
> 
> Ok.
> 
>>> Upon receipt of the last /8 that the IANA will allocate to ARIN per the
>>> Global Policy for the Allocation of the Remaining IPv4 Address Space,
>>> ARIN will place a contiguous /16 in reserve for Critical Infrastructure.
>>> If at the end of the policy term there is unused address space remaining
>>> in this pool, ARIN staff is authorized to utilize this space in a manner
>>> consistent with community expectations.
>> 
>> I'm not sure its necessary to have a contiguous reserve, but I SUPPORT
>> the policy proposal as written anyway.
> 
> 
> I thought about this and then saw Leo's post. Removing the word contiguous
> should be good enough.
> 
> I can't think of any other requirements with respect to CI and leaving this
> fairly open will leave the staff a healthy amount of discretion.
> 
> Anything else need to be done with this? Any disagreement with respect to
> this being pushed forward as an emergency proposal?
> 
> 
> Best,
> 
> -M<
> 
> 
> 
> _______________________________________________
> 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 marty at akamai.com  Sun Nov 21 16:11:53 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Sun, 21 Nov 2010 16:11:53 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
 Infrastructure - revised
In-Reply-To: <82D2C600-7FB9-4E9A-BE22-A0D346A1D594@gmail.com>
Message-ID: <C90F49A9.1821D%marty@akamai.com>




On 11/21/10 8:53 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:

> Is this policy is only really needed if we pass 122?

No.

>As I read it, CI needs can be met under 4.10.

A /10 even under the broken conditions of 4.10 is not a lot of ipv4 address
space. It's risky to assume that CI needs will be met under 4.10. This seems
like a perfectly reasonable risk to at least help near-zero the risk to CI
from an addressing needs perspective. At least theoretically.

> I agree this is needed if we pass 122,

Ditto. 

> but wondering if there's reason to pass
> 123 as a standalone policy (as it seems a lot less controversial).

I think we should pass it regardless of 122.

With respect to your comment re: 122 being controversial, you ought to
discuss that in the thread related to 122.


Best,

-M<



From owen at delong.com  Sun Nov 21 17:22:25 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 21 Nov 2010 14:22:25 -0800
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure - revised
In-Reply-To: <C90F2C9B.181FE%marty@akamai.com>
References: <C90F2C9B.181FE%marty@akamai.com>
Message-ID: <369841EF-E0A3-4AB2-9A8D-01EEC76CAA14@delong.com>


On Nov 21, 2010, at 11:07 AM, Hannigan, Martin wrote:

> 
> 
> 
> On 11/20/10 9:18 PM, "William Herrin" <bill at herrin.us> wrote:
> 
>> On Sat, Nov 20, 2010 at 3:04 PM, ARIN <info at arin.net> wrote:
>>> Policy Proposal 123: Reserved Pool for Critical Infrastructure
>>> 
>>> Policy term: 36 Months from Implementation
>> 
>> Nitpick: For 36 months following implementation.
>> 
>> The other way could be misunderstood to mean "starts 36 months later."
> 
> Ok.
> 
>>> Upon receipt of the last /8 that the IANA will allocate to ARIN per the
>>> Global Policy for the Allocation of the Remaining IPv4 Address Space,
>>> ARIN will place a contiguous /16 in reserve for Critical Infrastructure.
>>> If at the end of the policy term there is unused address space remaining
>>> in this pool, ARIN staff is authorized to utilize this space in a manner
>>> consistent with community expectations.
>> 
>> I'm not sure its necessary to have a contiguous reserve, but I SUPPORT
>> the policy proposal as written anyway.
> 
> 
> I thought about this and then saw Leo's post. Removing the word contiguous
> should be good enough.
> 
Actually I would argue that you should rewrite it as:

ARIN will place space totaling the equivalent of a /16 in reserve...

If you just remove the word contiguous, it becomes ambiguous whether
you want a real /16 (contiguous) or space equivalent to a /16 (doesn't
matter if it's contiguous).

Unlike proposal 122 which is dangerous and harmful, I have no
objection to moving this forward and would encourage the board
to consider moving it through the emergency process with the
modification suggested above.

Owen



From owen at delong.com  Sun Nov 21 17:24:10 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 21 Nov 2010 14:24:10 -0800
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure - revised
In-Reply-To: <82D2C600-7FB9-4E9A-BE22-A0D346A1D594@gmail.com>
References: <C90F2C9B.181FE%marty@akamai.com>
	<82D2C600-7FB9-4E9A-BE22-A0D346A1D594@gmail.com>
Message-ID: <018E217C-808F-4E15-88E0-FE3E67595904@delong.com>


On Nov 21, 2010, at 11:53 AM, Scott Leibrand wrote:

> Is this policy is only really needed if we pass 122? As I read it, CI needs can be met under 4.10. 
> 
No, this policy is needed regardless. It will expand the reserved space regardless of the state of 122.

> I agree this is needed if we pass 122, but wondering if there's reason to pass 123 as a standalone policy (as it seems a lot less controversial). 
> 
If we don't pass 122, this is merely useful and probably necessary. If we do pass 122, this becomes vital and urgent.

Owen

> Thanks,
> Scott
> 
> On Nov 21, 2010, at 11:07 AM, "Hannigan, Martin" <marty at akamai.com> wrote:
> 
>> 
>> 
>> 
>> On 11/20/10 9:18 PM, "William Herrin" <bill at herrin.us> wrote:
>> 
>>> On Sat, Nov 20, 2010 at 3:04 PM, ARIN <info at arin.net> wrote:
>>>> Policy Proposal 123: Reserved Pool for Critical Infrastructure
>>>> 
>>>> Policy term: 36 Months from Implementation
>>> 
>>> Nitpick: For 36 months following implementation.
>>> 
>>> The other way could be misunderstood to mean "starts 36 months later."
>> 
>> Ok.
>> 
>>>> Upon receipt of the last /8 that the IANA will allocate to ARIN per the
>>>> Global Policy for the Allocation of the Remaining IPv4 Address Space,
>>>> ARIN will place a contiguous /16 in reserve for Critical Infrastructure.
>>>> If at the end of the policy term there is unused address space remaining
>>>> in this pool, ARIN staff is authorized to utilize this space in a manner
>>>> consistent with community expectations.
>>> 
>>> I'm not sure its necessary to have a contiguous reserve, but I SUPPORT
>>> the policy proposal as written anyway.
>> 
>> 
>> I thought about this and then saw Leo's post. Removing the word contiguous
>> should be good enough.
>> 
>> I can't think of any other requirements with respect to CI and leaving this
>> fairly open will leave the staff a healthy amount of discretion.
>> 
>> Anything else need to be done with this? Any disagreement with respect to
>> this being pushed forward as an emergency proposal?
>> 
>> 
>> Best,
>> 
>> -M<
>> 
>> 
>> 
>> _______________________________________________
>> 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  Sun Nov 21 17:54:19 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Sun, 21 Nov 2010 14:54:19 -0800
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure - revised
In-Reply-To: <82D2C600-7FB9-4E9A-BE22-A0D346A1D594@gmail.com>
References: <C90F2C9B.181FE%marty@akamai.com>
	<82D2C600-7FB9-4E9A-BE22-A0D346A1D594@gmail.com>
Message-ID: <20101121225419.GA59420@ussenterprise.ufp.org>

In a message written on Sun, Nov 21, 2010 at 11:53:35AM -0800, Scott Leibrand wrote:
> Is this policy is only really needed if we pass 122? As I read it, CI needs can be met under 4.10. 

I re-read 4.10 trying to be as liberal as possible with respect to
Critical Infrastructure needs, but I believe CI will likely fail
points 1 and 5, and 3 could be an issue depending on how it was
interpreted.

I'm fairly sure CI wasn't intended to be in 4.10, to quote " a
contiguous /10 IPv4 block will be set aside and dedicated to
facilitate IPv6 deployment."  I have a hard time arguing CI IPv4
is necessary to facilitate IPv6 deployment, CI IPv4 is needed because
it is /critical/ to operating the IPv4 network.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101121/0f24016c/attachment.sig>

From gbonser at seven.com  Sun Nov 21 19:28:57 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 21 Nov 2010 16:28:57 -0800
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for
	CriticalInfrastructure - revised
In-Reply-To: <20101121225419.GA59420@ussenterprise.ufp.org>
References: <C90F2C9B.181FE%marty@akamai.com><82D2C600-7FB9-4E9A-BE22-A0D346A1D594@gmail.com>
	<20101121225419.GA59420@ussenterprise.ufp.org>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14CAD0@RWC-EX1.corp.seven.com>

> 
> I'm fairly sure CI wasn't intended to be in 4.10, to quote " a
> contiguous /10 IPv4 block will be set aside and dedicated to
facilitate
> IPv6 deployment."  I have a hard time arguing CI IPv4 is necessary to
> facilitate IPv6 deployment, CI IPv4 is needed because it is /critical/
> to operating the IPv4 network.

I agree that v6 facilitation is not CI.  

That we are even having this discussion is proof that the entire thing
is about to be severely broken.  The only process that is really going
to work is wholesale abandonment of v4, treating v6 as the "standard"
path, and treating v4 as the "special case".

How many providers have actively polled their customers on their v6
plans?  I have connectivity with two major providers who *still* don't
provide native v6 on my link to them.

This is going to break.  The whole thing is going to break. People have
waited too long to deploy v6.  It is really already too late, in my
opinion.  People should not have waited until v4 runout to deploy v6 but
that is what is going to happen and it is going to be a giant
clusterfark.




From owen at delong.com  Sun Nov 21 20:53:32 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 21 Nov 2010 17:53:32 -0800
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
	Infrastructure - revised
In-Reply-To: <20101121225419.GA59420@ussenterprise.ufp.org>
References: <C90F2C9B.181FE%marty@akamai.com>
	<82D2C600-7FB9-4E9A-BE22-A0D346A1D594@gmail.com>
	<20101121225419.GA59420@ussenterprise.ufp.org>
Message-ID: <B77C269D-BD28-413E-BC0C-CD9D4E904499@delong.com>


On Nov 21, 2010, at 2:54 PM, Leo Bicknell wrote:

> In a message written on Sun, Nov 21, 2010 at 11:53:35AM -0800, Scott Leibrand wrote:
>> Is this policy is only really needed if we pass 122? As I read it, CI needs can be met under 4.10. 
> 
> I re-read 4.10 trying to be as liberal as possible with respect to
> Critical Infrastructure needs, but I believe CI will likely fail
> points 1 and 5, and 3 could be an issue depending on how it was
> interpreted.
> 
> I'm fairly sure CI wasn't intended to be in 4.10, to quote " a
> contiguous /10 IPv4 block will be set aside and dedicated to
> facilitate IPv6 deployment."  I have a hard time arguing CI IPv4
> is necessary to facilitate IPv6 deployment, CI IPv4 is needed because
> it is /critical/ to operating the IPv4 network.
> 
I agree... CI is definitely outside the intended scope of 4.10 and 123 is
needed.

Owen



From frnkblk at iname.com  Sun Nov 21 22:33:09 2010
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Sun, 21 Nov 2010 21:33:09 -0600
Subject: [arin-ppml] Comcast
In-Reply-To: <20101109140119.GA24194@ussenterprise.ufp.org>
References: <47240.1289269565@tristatelogic.com>
	<4CD8C582.9070002@ipinc.net>	<AANLkTikZQVS4WR8Fe+nZxc6BZZ7v3pXEaBeMe90vWpxm@mail.gmail.com>	<4CD8D2D7.6020008@ipinc.net>
	<20101109140119.GA24194@ussenterprise.ufp.org>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAABoPXZwLOCEQZjdFuOkWlg3AQAAAAA=@iname.com>

http://www.google.com/url?sa=t&source=web&cd=2&ved=0CBcQFjAB&url=http%3A%2F%
2Fwww.apricot.net%2Fapricot2006%2Fslides%2Fconf%2Fwednesday%2FAlain_Durand-A
rchitecture-external.ppt&ei=zuPpTMG3JarvnQeln6DvDQ&usg=AFQjCNEmQfhz5kVPBqSf7
eRR4GX2ZlR2OA

Slide 4 talks about Comcast's IP usage.

Frank

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Leo Bicknell
Sent: Tuesday, November 09, 2010 8:01 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Comcast

In a message written on Mon, Nov 08, 2010 at 08:49:27PM -0800, Ted
Mittelstaedt wrote:
> Interesting, I didn't realize that they had all of their allocation
> under a single /9

They have more than one OrgID.  Lots of the largest folks do, usually
the result of various mergers or operating companies.

They have several dozen blocks across a half dozen OrgID's, one of
them is a /8, 73/8, which was obtained from ARIN.  Interestingly
it wasn't obtained all at once, when ARIN issued it they got a /10
and /9, IIRC, then later qualified for the other /10 to make it a
whole /8.

All together I would not be surprised that they had 3-4 /8's worth
of space if you added up all of their blocks.  If you believe
http://en.wikipedia.org/wiki/Comcast they have around 16 million
high speed internet residential users.  They do have other services
that eat IP's, for instance business users (not business cable,
actual GigE over fiber business users) who get larger blocks, and
some of their video and voice services also use IP's.

At a quick glance I don't see any significant blocks of legacy
space, I think they have gotten almost all of their space under
various ARIN policies.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/



From marty at akamai.com  Mon Nov 22 07:02:21 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 22 Nov 2010 07:02:21 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
 Infrastructure - revised
In-Reply-To: <20101121225419.GA59420@ussenterprise.ufp.org>
Message-ID: <C9101A5D.182FF%marty@akamai.com>




On 11/21/10 11:54 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:

> In a message written on Sun, Nov 21, 2010 at 11:53:35AM -0800, Scott Leibrand
> wrote:
>> Is this policy is only really needed if we pass 122? As I read it, CI needs
>> can be met under 4.10.
> 
> I re-read 4.10 trying to be as liberal as possible with respect to
> Critical Infrastructure needs, but I believe CI will likely fail
> points 1 and 5, and 3 could be an issue depending on how it was
> interpreted.
> 
> I'm fairly sure CI wasn't intended to be in 4.10, to quote " a
> contiguous /10 IPv4 block will be set aside and dedicated to
> facilitate IPv6 deployment."  I have a hard time arguing CI IPv4
> is necessary to facilitate IPv6 deployment, CI IPv4 is needed because
> it is /critical/ to operating the IPv4 network.


Agreed. I'd like to keep the proposal temporary and expiring in 36 months
with the balance of addresses being returned to whatever we have in place. I
figure that if this is going to be a problem someone will intercept this
problem and change it.

Anymore considerations before I submit a final update?

-M<



From marty at akamai.com  Mon Nov 22 07:17:28 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 22 Nov 2010 07:17:28 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com>
Message-ID: <C9101DE8.1830C%marty@akamai.com>




On 11/20/10 1:27 AM, "William Herrin" <bill at herrin.us> wrote:

> On Fri, Nov 19, 2010 at 7:07 PM, Hannigan, Martin <marty at akamai.com> wrote:
>> I agree. My date was deliberate though. I don't want to drag this out to
>> Philly as we risk being exhausted by then.
> 
> Then don't. Close the window in August, well before Philly. Pick which
> meeting you want to be the last chance for community consensus and
> close the window just enough time later for a draft policy to have
> gone through last call and ratification. Don't drag the deadline out
> to the close of the following meeting.
> 


That makes sense. It coincides with AC and BoT elections too which I think
is a good thing with respect to this.

On a higher level, I've read two points that have little substance with
regards to why this proposal shouldn't move forward.

1. 122 backdoors this to the freepool! Dangerous! Harmful! [handwave]

I had hoped that it would be clear that something has to be done to preserve
this in a manner that works for most if not all of us. The implication that
some would seem intent to actually battle this out to the point where we
would lose transition addresses is egregious. I think timing this to
coincide with AC elections is probably better. See below.

2. What about the rationale in 2008-5?

What about it? That was over a year ago and several AC members have noted
that the policy is insufficient. Are we really going to let something this
important go forward in a half-baked manner?

Three people seem to be fixated on the expiration. I removed the CI argument
and I'm willing to remove that argument as well.

I could rewrite this to suspend 4.10 and upon expiry, re-implement. That
would seem to address all objections and allow for this to be fully
addressed at election time if need be.

 
Best,

-M<






From owen at delong.com  Mon Nov 22 10:39:33 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 22 Nov 2010 07:39:33 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C9101DE8.1830C%marty@akamai.com>
References: <C9101DE8.1830C%marty@akamai.com>
Message-ID: <5256B010-963D-4EF3-9ED9-E1875E81654A@delong.com>


On Nov 22, 2010, at 4:17 AM, Hannigan, Martin wrote:

> 
> 
> 
> On 11/20/10 1:27 AM, "William Herrin" <bill at herrin.us> wrote:
> 
>> On Fri, Nov 19, 2010 at 7:07 PM, Hannigan, Martin <marty at akamai.com> wrote:
>>> I agree. My date was deliberate though. I don't want to drag this out to
>>> Philly as we risk being exhausted by then.
>> 
>> Then don't. Close the window in August, well before Philly. Pick which
>> meeting you want to be the last chance for community consensus and
>> close the window just enough time later for a draft policy to have
>> gone through last call and ratification. Don't drag the deadline out
>> to the close of the following meeting.
>> 
> 
> 
> That makes sense. It coincides with AC and BoT elections too which I think
> is a good thing with respect to this.
> 
> On a higher level, I've read two points that have little substance with
> regards to why this proposal shouldn't move forward.
> 
Really? Ad hominum already?

> 1. 122 backdoors this to the freepool! Dangerous! Harmful! [handwave]
> 
> I had hoped that it would be clear that something has to be done to preserve
> this in a manner that works for most if not all of us. The implication that
> some would seem intent to actually battle this out to the point where we
> would lose transition addresses is egregious. I think timing this to
> coincide with AC elections is probably better. See below.
> 

The problem is that you are changing the default. The current default if we
don't come to consensus on something else is to keep the addresses in
a transition pool used for certain high-user-ratio transitional technologies.

If we enact proposal 122, the default becomes to toss these addresses back
into the free pool unless we somehow pass a policy which is likely to be
very contentious in nature. Since a policy won't pass unless it has relatively
broad consensus, it virtually guarantees that something this contentious
will fall back to the non-consensus default behavior, especially on such
a tight deadline.

For example, I expect this to be no less contentious than the idea of making
end user assignments as small as /24 available. Look at the number of
different proposals that were submitted and the number of years that it
took to finally arrive at a policy which reached consensus.

I'm sorry, but, I do not think it is without substance to say that consensus
on a new policy in the timeframe you have specified is unlikely and
changing the default to try and force the community to accept whatever
is the least objectionable option available in that short window or
toss things back to the free pool is, IMHO, dangerous and far from
good stewardship.

Timing it to coincide with the AC and BoT election cycle is even more
cynically manipulative of the process IMHO.

> 2. What about the rationale in 2008-5?
> 
> What about it? That was over a year ago and several AC members have noted
> that the policy is insufficient. Are we really going to let something this
> important go forward in a half-baked manner?
> 
If you have a better concrete proposal to improve 4.10, please present it
and let's discuss it. However, tossing 4.10 out for something non-baked
in order to try and drive a new process is a giant leap in the wrong direction.

> Three people seem to be fixated on the expiration. I removed the CI argument
> and I'm willing to remove that argument as well.
> 
> I could rewrite this to suspend 4.10 and upon expiry, re-implement. That
> would seem to address all objections and allow for this to be fully
> addressed at election time if need be.
> 
What about people who need transitional space for that intended purpose 
in the meantime?

If you want to do this, how about setting aside an additional /10 for that
TBD purpose and returning it to the free pool upon expiry instead?

Owen



From BillD at cait.wustl.edu  Mon Nov 22 10:59:58 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Mon, 22 Nov 2010 09:59:58 -0600
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
	Development
In-Reply-To: <5256B010-963D-4EF3-9ED9-E1875E81654A@delong.com>
References: <C9101DE8.1830C%marty@akamai.com>
	<5256B010-963D-4EF3-9ED9-E1875E81654A@delong.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087B8DFE2@ex1.cait.wustl.edu>

Or one could simply require a periodic review of the utility being
served by 4.10 and redirect use of those addresses as befits the current
'on the ground' reality.

bd 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Monday, November 22, 2010 9:40 AM
> To: Hannigan, Martin
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool 
> for FuturePolicy Development
> 
> 
> On Nov 22, 2010, at 4:17 AM, Hannigan, Martin wrote:
> 
> > 
> > 
> > 
> > On 11/20/10 1:27 AM, "William Herrin" <bill at herrin.us> wrote:
> > 
> >> On Fri, Nov 19, 2010 at 7:07 PM, Hannigan, Martin 
> <marty at akamai.com> wrote:
> >>> I agree. My date was deliberate though. I don't want to drag this 
> >>> out to Philly as we risk being exhausted by then.
> >> 
> >> Then don't. Close the window in August, well before Philly. Pick 
> >> which meeting you want to be the last chance for community 
> consensus 
> >> and close the window just enough time later for a draft policy to 
> >> have gone through last call and ratification. Don't drag 
> the deadline 
> >> out to the close of the following meeting.
> >> 
> > 
> > 
> > That makes sense. It coincides with AC and BoT elections 
> too which I 
> > think is a good thing with respect to this.
> > 
> > On a higher level, I've read two points that have little substance 
> > with regards to why this proposal shouldn't move forward.
> > 
> Really? Ad hominum already?
> 
> > 1. 122 backdoors this to the freepool! Dangerous! Harmful! 
> [handwave]
> > 
> > I had hoped that it would be clear that something has to be done to 
> > preserve this in a manner that works for most if not all of us. The 
> > implication that some would seem intent to actually battle 
> this out to 
> > the point where we would lose transition addresses is egregious. I 
> > think timing this to coincide with AC elections is probably 
> better. See below.
> > 
> 
> The problem is that you are changing the default. The current 
> default if we don't come to consensus on something else is to 
> keep the addresses in a transition pool used for certain 
> high-user-ratio transitional technologies.
> 
> If we enact proposal 122, the default becomes to toss these 
> addresses back into the free pool unless we somehow pass a 
> policy which is likely to be very contentious in nature. 
> Since a policy won't pass unless it has relatively broad 
> consensus, it virtually guarantees that something this 
> contentious will fall back to the non-consensus default 
> behavior, especially on such a tight deadline.
> 
> For example, I expect this to be no less contentious than the 
> idea of making end user assignments as small as /24 
> available. Look at the number of different proposals that 
> were submitted and the number of years that it took to 
> finally arrive at a policy which reached consensus.
> 
> I'm sorry, but, I do not think it is without substance to say 
> that consensus on a new policy in the timeframe you have 
> specified is unlikely and changing the default to try and 
> force the community to accept whatever is the least 
> objectionable option available in that short window or toss 
> things back to the free pool is, IMHO, dangerous and far from 
> good stewardship.
> 
> Timing it to coincide with the AC and BoT election cycle is 
> even more cynically manipulative of the process IMHO.
> 
> > 2. What about the rationale in 2008-5?
> > 
> > What about it? That was over a year ago and several AC members have 
> > noted that the policy is insufficient. Are we really going to let 
> > something this important go forward in a half-baked manner?
> > 
> If you have a better concrete proposal to improve 4.10, 
> please present it and let's discuss it. However, tossing 4.10 
> out for something non-baked in order to try and drive a new 
> process is a giant leap in the wrong direction.
> 
> > Three people seem to be fixated on the expiration. I removed the CI 
> > argument and I'm willing to remove that argument as well.
> > 
> > I could rewrite this to suspend 4.10 and upon expiry, re-implement. 
> > That would seem to address all objections and allow for this to be 
> > fully addressed at election time if need be.
> > 
> What about people who need transitional space for that 
> intended purpose in the meantime?
> 
> If you want to do this, how about setting aside an additional 
> /10 for that TBD purpose and returning it to the free pool 
> upon expiry instead?
> 
> Owen
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From gbonser at seven.com  Mon Nov 22 13:16:32 2010
From: gbonser at seven.com (George Bonser)
Date: Mon, 22 Nov 2010 10:16:32 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for
	FuturePolicyDevelopment
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087B8DFE2@ex1.cait.wustl.edu>
References: <C9101DE8.1830C%marty@akamai.com><5256B010-963D-4EF3-9ED9-E1875E81654A@delong.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087B8DFE2@ex1.cait.wustl.edu>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14CAEF@RWC-EX1.corp.seven.com>


> 
> Or one could simply require a periodic review of the utility being
> served by 4.10 and redirect use of those addresses as befits the
> current 'on the ground' reality.

I like that idea. Don't make the reviews so frequent that they are a
pain but frequent enough where it must be periodically re-evaluated.
The idea is to avoid the "Class E" problem where a block of addresses is
held in reserve in perpetuity and never actually used for anything.




From marty at akamai.com  Mon Nov 22 16:40:57 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 22 Nov 2010 16:40:57 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
 Development
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087B8DFE2@ex1.cait.wustl.edu>
Message-ID: <C910A1F9.184A3%marty@akamai.com>




On 11/22/10 4:59 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:

> Or one could simply require a periodic review of the utility being
> served by 4.10 and redirect use of those addresses as befits the current
> 'on the ground' reality.
> 
> bd 


Interesting, but that doesn't need to be codified. We've almost all agreed
that this policy is insufficient, and previously a large group of members
supported an effort to modifiy it though petition.

I'm going to make some adjustments to proposal 122 that will remove the fear
mongering with respect to allowing these addresses to lapse into the free
pool and the AC can take it up. The precedent has already been set. Change
was already petitioned once. The fact that exhaustion is on the door step
changes little IMHO.

Best,

-M<



From owen at delong.com  Mon Nov 22 17:26:01 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 22 Nov 2010 14:26:01 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
	Development
In-Reply-To: <C910A1F9.184A3%marty@akamai.com>
References: <C910A1F9.184A3%marty@akamai.com>
Message-ID: <30412BFC-4841-404D-A011-09867CE51257@delong.com>


On Nov 22, 2010, at 1:40 PM, Hannigan, Martin wrote:

> 
> 
> 
> On 11/22/10 4:59 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:
> 
>> Or one could simply require a periodic review of the utility being
>> served by 4.10 and redirect use of those addresses as befits the current
>> 'on the ground' reality.
>> 
>> bd 
> 
> 
> Interesting, but that doesn't need to be codified. We've almost all agreed
> that this policy is insufficient, and previously a large group of members
> supported an effort to modifiy it though petition.
> 
Which I will point out after we tried to give everyone their piece of a poiny
resulted in a policy that nobody liked.

The proposal that was actually petitioned sought merely to codify the intended
usage of 4.10 space. We'll never know if that policy would have succeeded,
but, it's quite clear that coming to consensus on something better than what
we have should not be attempted under a deadline.

> I'm going to make some adjustments to proposal 122 that will remove the fear
> mongering with respect to allowing these addresses to lapse into the free
> pool and the AC can take it up. The precedent has already been set. Change
> was already petitioned once. The fact that exhaustion is on the door step
> changes little IMHO.
> 
You call it fear mongering, I call it prudence. Be that as it may, yes, removing
the back-door-route to the free pool will make the idea far more acceptable.

Owen



From scottleibrand at gmail.com  Mon Nov 22 23:25:38 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 22 Nov 2010 20:25:38 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C9101DE8.1830C%marty@akamai.com>
References: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com>
	<C9101DE8.1830C%marty@akamai.com>
Message-ID: <AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com>

It seems we have a couple of issues/questions around NRPM 4.10.  To
help me (and hopefully others) think through the issue, let me see if
I can identify several of them:

Q1: Should a reserved pool of addresses be reserved, and made
available after free pool exhaustion, to support IPv6 transition?
My answer would be yes, and I believe we have a strong consensus
(expressed through the original adoption of 4.10, and in subsequent
discussions) for this.

Q2: Does NRPM 4.10 need to be updated at some point?
Again, I think the answer is yes, and it seems we have quite a bit of
community support for some kind of revisions.

Q3: Can we agree on how to update 4.10?
Perhaps.  We seemed to have some points of general agreement, but the
last proposal attempting a comprehensive rewrite of 4.10 failed.
Perhaps smaller tweaks would do better, or new policy proposals (like
123).

Q4: What should happen if we fail to reach consensus on any
modifications to 4.10?  Should it expire at some point?
This is where I think proposal 122 comes in:

IMO the solution proposed by 122, which is to revoke 4.10, reserve an
equivalently sized block for one more policy cycle, and then return it
to the free pool if nothing can be agreed upon, is a less desirable
solution than the status quo.

I seem to recall some people doing the math on demand for space under
4.10, but I don't remember the results, so I'll give it another try.
If we assume that every organization requesting space today will find
a way to request space under 4.10, and somehow manages to qualify for
the maximum number of space allowed under the policy, we can figure
out how quickly the 4.10 reserved pool could be used up.  According to
https://www.arin.net/knowledge/statistics/index.html, ARIN is
currently processing <200 IPv4 address space requests per month.  So
let's assume 2400 requests/year.  Since ISPs can get 1 year of space
at a time today, let's assume that's ~2500 orgs actively requesting
space, and let's assume that number doubles after exhaustion, to say
5000 orgs.  If each such org qualifies for a /24 every 6 months under
4.10, then it would take approximately 3 years to assign all of the
space from the /10 reserved under 4.10.

So IMO our best course of action is to get together a number of minor
tweaks that we think should be made to 4.10, and get them into the
policy process ASAP.  If any of them get consensus, we should be able
to adopt them before more than a small fraction of the 4.10 pool is
used up.

I don't think it would be a good idea to put a near-term expiration
date on the /10 reservation currently defined under 4.10.  I would be
less opposed to simply suspending 4.10 for a few months while we
discuss alternatives, but IMO that isn't really necessary given 4.10's
/24 maximum allocation and one-allocation-every-6-months restriction.
IMO it would actually be better to start using 4.10 upon exhaustion
and use our implementation experience to inform future tweaks to the
rules for using its reserved pool.

-Scott

On Mon, Nov 22, 2010 at 4:17 AM, Hannigan, Martin <marty at akamai.com> wrote:
>
>
>
> On 11/20/10 1:27 AM, "William Herrin" <bill at herrin.us> wrote:
>
>> On Fri, Nov 19, 2010 at 7:07 PM, Hannigan, Martin <marty at akamai.com> wrote:
>>> I agree. My date was deliberate though. I don't want to drag this out to
>>> Philly as we risk being exhausted by then.
>>
>> Then don't. Close the window in August, well before Philly. Pick which
>> meeting you want to be the last chance for community consensus and
>> close the window just enough time later for a draft policy to have
>> gone through last call and ratification. Don't drag the deadline out
>> to the close of the following meeting.
>>
>
>
> That makes sense. It coincides with AC and BoT elections too which I think
> is a good thing with respect to this.
>
> On a higher level, I've read two points that have little substance with
> regards to why this proposal shouldn't move forward.
>
> 1. 122 backdoors this to the freepool! Dangerous! Harmful! [handwave]
>
> I had hoped that it would be clear that something has to be done to preserve
> this in a manner that works for most if not all of us. The implication that
> some would seem intent to actually battle this out to the point where we
> would lose transition addresses is egregious. I think timing this to
> coincide with AC elections is probably better. See below.
>
> 2. What about the rationale in 2008-5?
>
> What about it? That was over a year ago and several AC members have noted
> that the policy is insufficient. Are we really going to let something this
> important go forward in a half-baked manner?
>
> Three people seem to be fixated on the expiration. I removed the CI argument
> and I'm willing to remove that argument as well.
>
> I could rewrite this to suspend 4.10 and upon expiry, re-implement. That
> would seem to address all objections and allow for this to be fully
> addressed at election time if need be.
>
>
> Best,
>
> -M<
>
>
>
>
> _______________________________________________
> 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 Nov 23 01:36:42 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 22 Nov 2010 22:36:42 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com>
References: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com>
	<C9101DE8.1830C%marty@akamai.com>
	<AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com>
Message-ID: <796F94E9-2035-4A78-B454-2FF7BCA1F050@delong.com>


On Nov 22, 2010, at 8:25 PM, Scott Leibrand wrote:

> It seems we have a couple of issues/questions around NRPM 4.10.  To
> help me (and hopefully others) think through the issue, let me see if
> I can identify several of them:
> 
> Q1: Should a reserved pool of addresses be reserved, and made
> available after free pool exhaustion, to support IPv6 transition?
> My answer would be yes, and I believe we have a strong consensus
> (expressed through the original adoption of 4.10, and in subsequent
> discussions) for this.
> 
Yes on both counts.


> Q2: Does NRPM 4.10 need to be updated at some point?
> Again, I think the answer is yes, and it seems we have quite a bit of
> community support for some kind of revisions.
> 
Yes, but, I think finding consensus on what kind of revisions will be quite
hard.

> Q3: Can we agree on how to update 4.10?
> Perhaps.  We seemed to have some points of general agreement, but the
> last proposal attempting a comprehensive rewrite of 4.10 failed.
> Perhaps smaller tweaks would do better, or new policy proposals (like
> 123).
> 
Agreed. In hindsight, I wish I had resisted the kitchen sink of ponies
approach that was advocated for that proposal by others, who
ended up opposing the proposal as a result.

> Q4: What should happen if we fail to reach consensus on any
> modifications to 4.10?  Should it expire at some point?

Probably not for a very long time, IMHO.

Certainly not within 5 years. And it shouldn't be unavailable to transitional
technologies during that time.

> This is where I think proposal 122 comes in:
> 
> IMO the solution proposed by 122, which is to revoke 4.10, reserve an
> equivalently sized block for one more policy cycle, and then return it
> to the free pool if nothing can be agreed upon, is a less desirable
> solution than the status quo.
> 
Agreed.

> I seem to recall some people doing the math on demand for space under
> 4.10, but I don't remember the results, so I'll give it another try.
> If we assume that every organization requesting space today will find
> a way to request space under 4.10, and somehow manages to qualify for
> the maximum number of space allowed under the policy, we can figure
> out how quickly the 4.10 reserved pool could be used up.  According to
> https://www.arin.net/knowledge/statistics/index.html, ARIN is
> currently processing <200 IPv4 address space requests per month.  So
> let's assume 2400 requests/year.  Since ISPs can get 1 year of space
> at a time today, let's assume that's ~2500 orgs actively requesting
> space, and let's assume that number doubles after exhaustion, to say
> 5000 orgs.  If each such org qualifies for a /24 every 6 months under
> 4.10, then it would take approximately 3 years to assign all of the
> space from the /10 reserved under 4.10.
> 
That's probably as good a guess as any and seems like about the right
target timeframe.

> So IMO our best course of action is to get together a number of minor
> tweaks that we think should be made to 4.10, and get them into the
> policy process ASAP.  If any of them get consensus, we should be able
> to adopt them before more than a small fraction of the 4.10 pool is
> used up.
> 
Works for me.

> I don't think it would be a good idea to put a near-term expiration
> date on the /10 reservation currently defined under 4.10.  I would be
> less opposed to simply suspending 4.10 for a few months while we
> discuss alternatives, but IMO that isn't really necessary given 4.10's
> /24 maximum allocation and one-allocation-every-6-months restriction.
> IMO it would actually be better to start using 4.10 upon exhaustion
> and use our implementation experience to inform future tweaks to the
> rules for using its reserved pool.
> 
Agreed.

Owen

> -Scott
> 
> On Mon, Nov 22, 2010 at 4:17 AM, Hannigan, Martin <marty at akamai.com> wrote:
>> 
>> 
>> 
>> On 11/20/10 1:27 AM, "William Herrin" <bill at herrin.us> wrote:
>> 
>>> On Fri, Nov 19, 2010 at 7:07 PM, Hannigan, Martin <marty at akamai.com> wrote:
>>>> I agree. My date was deliberate though. I don't want to drag this out to
>>>> Philly as we risk being exhausted by then.
>>> 
>>> Then don't. Close the window in August, well before Philly. Pick which
>>> meeting you want to be the last chance for community consensus and
>>> close the window just enough time later for a draft policy to have
>>> gone through last call and ratification. Don't drag the deadline out
>>> to the close of the following meeting.
>>> 
>> 
>> 
>> That makes sense. It coincides with AC and BoT elections too which I think
>> is a good thing with respect to this.
>> 
>> On a higher level, I've read two points that have little substance with
>> regards to why this proposal shouldn't move forward.
>> 
>> 1. 122 backdoors this to the freepool! Dangerous! Harmful! [handwave]
>> 
>> I had hoped that it would be clear that something has to be done to preserve
>> this in a manner that works for most if not all of us. The implication that
>> some would seem intent to actually battle this out to the point where we
>> would lose transition addresses is egregious. I think timing this to
>> coincide with AC elections is probably better. See below.
>> 
>> 2. What about the rationale in 2008-5?
>> 
>> What about it? That was over a year ago and several AC members have noted
>> that the policy is insufficient. Are we really going to let something this
>> important go forward in a half-baked manner?
>> 
>> Three people seem to be fixated on the expiration. I removed the CI argument
>> and I'm willing to remove that argument as well.
>> 
>> I could rewrite this to suspend 4.10 and upon expiry, re-implement. That
>> would seem to address all objections and allow for this to be fully
>> addressed at election time if need be.
>> 
>> 
>> Best,
>> 
>> -M<
>> 
>> 
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From BillD at cait.wustl.edu  Tue Nov 23 08:38:48 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Tue, 23 Nov 2010 07:38:48 -0600
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
	Development
References: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com><C9101DE8.1830C%marty@akamai.com><AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com>
	<796F94E9-2035-4A78-B454-2FF7BCA1F050@delong.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D0308791548B@ex1.cait.wustl.edu>


+1 on these comments and crumbs suggestion.


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Owen DeLong
Sent: Tue 11/23/2010 12:36 AM
To: Scott Leibrand
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy Development
 

On Nov 22, 2010, at 8:25 PM, Scott Leibrand wrote:

> It seems we have a couple of issues/questions around NRPM 4.10.  To
> help me (and hopefully others) think through the issue, let me see if
> I can identify several of them:
> 
> Q1: Should a reserved pool of addresses be reserved, and made
> available after free pool exhaustion, to support IPv6 transition?
> My answer would be yes, and I believe we have a strong consensus
> (expressed through the original adoption of 4.10, and in subsequent
> discussions) for this.
> 
Yes on both counts.


> Q2: Does NRPM 4.10 need to be updated at some point?
> Again, I think the answer is yes, and it seems we have quite a bit of
> community support for some kind of revisions.
> 
Yes, but, I think finding consensus on what kind of revisions will be quite
hard.

> Q3: Can we agree on how to update 4.10?
> Perhaps.  We seemed to have some points of general agreement, but the
> last proposal attempting a comprehensive rewrite of 4.10 failed.
> Perhaps smaller tweaks would do better, or new policy proposals (like
> 123).
> 
Agreed. In hindsight, I wish I had resisted the kitchen sink of ponies
approach that was advocated for that proposal by others, who
ended up opposing the proposal as a result.

> Q4: What should happen if we fail to reach consensus on any
> modifications to 4.10?  Should it expire at some point?

Probably not for a very long time, IMHO.

Certainly not within 5 years. And it shouldn't be unavailable to transitional
technologies during that time.

> This is where I think proposal 122 comes in:
> 
> IMO the solution proposed by 122, which is to revoke 4.10, reserve an
> equivalently sized block for one more policy cycle, and then return it
> to the free pool if nothing can be agreed upon, is a less desirable
> solution than the status quo.
> 
Agreed.

> I seem to recall some people doing the math on demand for space under
> 4.10, but I don't remember the results, so I'll give it another try.
> If we assume that every organization requesting space today will find
> a way to request space under 4.10, and somehow manages to qualify for
> the maximum number of space allowed under the policy, we can figure
> out how quickly the 4.10 reserved pool could be used up.  According to
> https://www.arin.net/knowledge/statistics/index.html, ARIN is
> currently processing <200 IPv4 address space requests per month.  So
> let's assume 2400 requests/year.  Since ISPs can get 1 year of space
> at a time today, let's assume that's ~2500 orgs actively requesting
> space, and let's assume that number doubles after exhaustion, to say
> 5000 orgs.  If each such org qualifies for a /24 every 6 months under
> 4.10, then it would take approximately 3 years to assign all of the
> space from the /10 reserved under 4.10.
> 
That's probably as good a guess as any and seems like about the right
target timeframe.

> So IMO our best course of action is to get together a number of minor
> tweaks that we think should be made to 4.10, and get them into the
> policy process ASAP.  If any of them get consensus, we should be able
> to adopt them before more than a small fraction of the 4.10 pool is
> used up.
> 
Works for me.

> I don't think it would be a good idea to put a near-term expiration
> date on the /10 reservation currently defined under 4.10.  I would be
> less opposed to simply suspending 4.10 for a few months while we
> discuss alternatives, but IMO that isn't really necessary given 4.10's
> /24 maximum allocation and one-allocation-every-6-months restriction.
> IMO it would actually be better to start using 4.10 upon exhaustion
> and use our implementation experience to inform future tweaks to the
> rules for using its reserved pool.
> 
Agreed.

Owen

> -Scott
> 
> On Mon, Nov 22, 2010 at 4:17 AM, Hannigan, Martin <marty at akamai.com> wrote:
>> 
>> 
>> 
>> On 11/20/10 1:27 AM, "William Herrin" <bill at herrin.us> wrote:
>> 
>>> On Fri, Nov 19, 2010 at 7:07 PM, Hannigan, Martin <marty at akamai.com> wrote:
>>>> I agree. My date was deliberate though. I don't want to drag this out to
>>>> Philly as we risk being exhausted by then.
>>> 
>>> Then don't. Close the window in August, well before Philly. Pick which
>>> meeting you want to be the last chance for community consensus and
>>> close the window just enough time later for a draft policy to have
>>> gone through last call and ratification. Don't drag the deadline out
>>> to the close of the following meeting.
>>> 
>> 
>> 
>> That makes sense. It coincides with AC and BoT elections too which I think
>> is a good thing with respect to this.
>> 
>> On a higher level, I've read two points that have little substance with
>> regards to why this proposal shouldn't move forward.
>> 
>> 1. 122 backdoors this to the freepool! Dangerous! Harmful! [handwave]
>> 
>> I had hoped that it would be clear that something has to be done to preserve
>> this in a manner that works for most if not all of us. The implication that
>> some would seem intent to actually battle this out to the point where we
>> would lose transition addresses is egregious. I think timing this to
>> coincide with AC elections is probably better. See below.
>> 
>> 2. What about the rationale in 2008-5?
>> 
>> What about it? That was over a year ago and several AC members have noted
>> that the policy is insufficient. Are we really going to let something this
>> important go forward in a half-baked manner?
>> 
>> Three people seem to be fixated on the expiration. I removed the CI argument
>> and I'm willing to remove that argument as well.
>> 
>> I could rewrite this to suspend 4.10 and upon expiry, re-implement. That
>> would seem to address all objections and allow for this to be fully
>> addressed at election time if need be.
>> 
>> 
>> Best,
>> 
>> -M<
>> 
>> 
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

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

From bicknell at ufp.org  Tue Nov 23 09:29:32 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 23 Nov 2010 06:29:32 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <796F94E9-2035-4A78-B454-2FF7BCA1F050@delong.com>
References: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com>
	<C9101DE8.1830C%marty@akamai.com>
	<AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com>
	<796F94E9-2035-4A78-B454-2FF7BCA1F050@delong.com>
Message-ID: <20101123142932.GA10591@ussenterprise.ufp.org>

In a message written on Mon, Nov 22, 2010 at 10:36:42PM -0800, Owen DeLong wrote:
> On Nov 22, 2010, at 8:25 PM, Scott Leibrand wrote:
> > Q2: Does NRPM 4.10 need to be updated at some point?
> > Again, I think the answer is yes, and it seems we have quite a bit of
> > community support for some kind of revisions.
> > 
> Yes, but, I think finding consensus on what kind of revisions will be quite
> hard.

I don't, I just think we're trying at the wrong time.

It will only take weeks, or perhaps months past _ARIN_ runout to
collect a lot of information about what the world really looks like
on the ground when you can't get IPv4 space.  With that information
I believe consensus will develop quite quickly around the best thing
we can do.

I realize folks want to have this define in advance, but I just
don't see how to do that in this case.  If we're going to modify
4.10 in any way I think it should be to not give out any space (even
for "transition technologies").  We need a period of several months
where folks are forced to do without IPv4 to figure out what really
is and isn't the most useful way to use the last /10.

Part of the reason there are so many views now is that each person
has a slightly different prediction for what the world looks like
after run-out.  What you're trying to get consensus on isn't a
policy, it's on a view of the future.  If we just wait for it to
happen there will be no more disagreement on what it looks like.
If we end up with a month or two where this sits unable to be given
out, oh well.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101123/4ded44dc/attachment.sig>

From owen at delong.com  Tue Nov 23 09:43:31 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 23 Nov 2010 06:43:31 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <20101123142932.GA10591@ussenterprise.ufp.org>
References: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com>
	<C9101DE8.1830C%marty@akamai.com>
	<AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com>
	<796F94E9-2035-4A78-B454-2FF7BCA1F050@delong.com>
	<20101123142932.GA10591@ussenterprise.ufp.org>
Message-ID: <6CC1D077-7EE4-4102-A1F3-2DD3102AB3FF@delong.com>


On Nov 23, 2010, at 6:29 AM, Leo Bicknell wrote:

> In a message written on Mon, Nov 22, 2010 at 10:36:42PM -0800, Owen DeLong wrote:
>> On Nov 22, 2010, at 8:25 PM, Scott Leibrand wrote:
>>> Q2: Does NRPM 4.10 need to be updated at some point?
>>> Again, I think the answer is yes, and it seems we have quite a bit of
>>> community support for some kind of revisions.
>>> 
>> Yes, but, I think finding consensus on what kind of revisions will be quite
>> hard.
> 
> I don't, I just think we're trying at the wrong time.
> 
> It will only take weeks, or perhaps months past _ARIN_ runout to
> collect a lot of information about what the world really looks like
> on the ground when you can't get IPv4 space.  With that information
> I believe consensus will develop quite quickly around the best thing
> we can do.
> 
I think that is true in any particular subset of the user community. However,
ARIN is quite diverse and I think there will be many factions all vying for
the biggest piece of the remaining pie they can get. In the past, the
community has been particularly bad at swallowing hard and accepting
a policy that makes everyone equally unhappy. What makes you think
this time will be substantially different?

> I realize folks want to have this define in advance, but I just
> don't see how to do that in this case.  If we're going to modify
> 4.10 in any way I think it should be to not give out any space (even
> for "transition technologies").  We need a period of several months
> where folks are forced to do without IPv4 to figure out what really
> is and isn't the most useful way to use the last /10.
> 
I think that's a very poor choice. That basically says that all growth
on the internet during that time is users who have no access to the
remaining IPv4 content and services that have not adapted to IPv6
yet.  This is an untenable situation for providers that are completely
out of IPv4 space and a major competitive advantage for their
competitors that still happen to have space for whatever reason
or are able to obtain it quickly through the transfer market.

As such, I think holding back addresses in this way is not only
monumentally poor stewardship, but, also dramatically disproportionate
in the effect it will have on organizations, providing minimum
disadvantage to the largest consumers of address space.

If you want to conduct an experiment in this manner, I suggest
leaving 4.10 alone and setting aside an additional /10 from the
final /8 to be subject to this future policy effort, possibly encompassing
the 4.10 space as well if there is consensus at that time.

> Part of the reason there are so many views now is that each person
> has a slightly different prediction for what the world looks like
> after run-out.  What you're trying to get consensus on isn't a
> policy, it's on a view of the future.  If we just wait for it to
> happen there will be no more disagreement on what it looks like.
> If we end up with a month or two where this sits unable to be given
> out, oh well.
> 
I think another part of the problem is that people are coming from
different perspectives on how the inability to get new IPv4
addresses for expansion will affect their business and the
criticality of their particular need vs. that of the rest of the
community.

Owen



From info at arin.net  Tue Nov 23 10:01:12 2010
From: info at arin.net (ARIN)
Date: Tue, 23 Nov 2010 10:01:12 -0500
Subject: [arin-ppml] Policy Proposal 123: Reserved Pool for Critical
 Infrastructure - revised
Message-ID: <4CEBD738.6090506@arin.net>

The proposal originator submitted revised text.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 123: Reserved Pool for Critical Infrastructure

Proposal Originator: Martin Hannigan

Proposal Version: 3.0

Date: 23 Nov 2010

Proposal type: Modify

Policy term: 36 Months following implementation

Policy statement:

Upon receipt of the last /8 that the IANA will allocate to ARIN per the
Global Policy for the Allocation of the Remaining IPv4 Address Space,
ARIN will place an equivalent of a /16 of IPv4 address space in a
reserve for Critical Infrastructure. If at the end of the policy term
there is unused address space remaining in this pool, ARIN staff is
authorized to utilize this space in a manner consistent with community
expectations.

Rationale:

Section 4.10 of the NRPM is insufficient with respect to insuring the
continued operation of critical infrastructure. This proposal, if
adopted, will protect those resources with a reasonable amount of
reserved v4 address space and prevent an overrun of CI needs by NRPM
Section 4.10 or any successor. The intent is to separate CI needs and
make a distinct pool available to insure the continuity of CI
allocations per NRPM Section 4.4 for at least 36 months.

This proposal should be considered an emergency proposal. IANA
exhaustion is likely to occur prior to the next ARIN meeting.

Timetable for implementation: Immediate





From info at arin.net  Tue Nov 23 10:06:20 2010
From: info at arin.net (ARIN)
Date: Tue, 23 Nov 2010 10:06:20 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future Policy
 Development - revised
Message-ID: <4CEBD86C.6050003@arin.net>

The proposal originator submitted revised text.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 122: Reserved Pool for Future Policy Development

Proposal Originator: Martin Hannigan

Proposal Version: 2.0

Date: 23 Nov 2010

Proposal type: New

Policy term: Temporary, expires on August 10, 2011 00:00 UTC

Policy statement:

Upon receipt of the last /8 that the IANA will allocate to ARIN per the
Global Policy for the Allocation of the Remaining IPv4 Address Space,
ARIN will immediately suspend NRPM 4.10 and place the contiguous /10
designated for NRPM Section 4.10 in a reserved pool. Upon expiration of
this policy, NRPM 4.10 will be reinstated along with the aforementioned
contiguous /10 as it's source pool.

Rationale:

During the recent attempted fix of Section 4.10 we had consensus that
4.10 was insufficient and potentially damaging and unbalanced with
respect to transition efforts.  This will provide for time to review
our current depletion strategy and improve upon it to the benefit of the
entire community. If for some unforeseen reason the community does not
act, NRPM Section 4.10 will be reinstated post suspension forthwith. Any
subsequent policy should declare 4.10 deprecated in order to utilize
this reserved pool and be enacted. Otherwise, NRPM 4.10 will be reinstated.

Should be considered an emergency proposal.

Timetable for implementation: Immediate







From bicknell at ufp.org  Tue Nov 23 10:34:16 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 23 Nov 2010 07:34:16 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <6CC1D077-7EE4-4102-A1F3-2DD3102AB3FF@delong.com>
References: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com>
	<C9101DE8.1830C%marty@akamai.com>
	<AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com>
	<796F94E9-2035-4A78-B454-2FF7BCA1F050@delong.com>
	<20101123142932.GA10591@ussenterprise.ufp.org>
	<6CC1D077-7EE4-4102-A1F3-2DD3102AB3FF@delong.com>
Message-ID: <20101123153414.GA14916@ussenterprise.ufp.org>

In a message written on Tue, Nov 23, 2010 at 06:43:31AM -0800, Owen DeLong wrote:
> > I realize folks want to have this define in advance, but I just
> > don't see how to do that in this case.  If we're going to modify
> > 4.10 in any way I think it should be to not give out any space (even
> > for "transition technologies").  We need a period of several months
> > where folks are forced to do without IPv4 to figure out what really
> > is and isn't the most useful way to use the last /10.
> > 
> I think that's a very poor choice. That basically says that all growth
> on the internet during that time is users who have no access to the
> remaining IPv4 content and services that have not adapted to IPv6
> yet.  This is an untenable situation for providers that are completely
> out of IPv4 space and a major competitive advantage for their
> competitors that still happen to have space for whatever reason
> or are able to obtain it quickly through the transfer market.

You are pitting a pair of choices against each other as if they are
the only two options, when the reality is there will be a continium
of solutions in the middle.

ISP's will come back for more IPv4 space and get told no.  I would
hope a savvy ISP could set aside a /28 of their previous allocation
to use for transition technologies at that point.  I pick on that
size only because it's a popular suggestion of how much space we
should give the ISP from the /10.  The more we can encourage folks
to make these sorts of wise decisions, the longer the /10 will prove
useful.

Even if the situation you describe comes to be, where folks are
monumentally stupid and give out every last IP of their allocations
keeping nothing to run a transition box your dire consequences still
come true.  Giving a provider who receives a /28 or two from the
last /10 will not change their competitiveness against another
provider who still has half a /8 available.

> I think another part of the problem is that people are coming from
> different perspectives on how the inability to get new IPv4
> addresses for expansion will affect their business and the
> criticality of their particular need vs. that of the rest of the
> community.

I agree with your statement, but I also believe there's enough
information to get everyone on the same page.  When we have only a
/10 left, everyone is screwed.  There is no using that /10 to make
even 1/1000th of the people happy.  We're out, done, and if your
business depends on it you might as well go ahead and turn out the
lights.  I've not seen a single person suggest how the last /10
could save businesses that have failed to plan.

The last /10 isn't about making a business with no IPv4 able to
compete against someone who still has half a /8 left.  That is
frankly, laughable.  What it can be about though is help for those
who planned well and ran into unexpected consequences.  The guy who
deployed transition boxes across his entire footprint and then
purchased a smaller ISP that did not plan so well, but also expanded
his footprint.  He's up and working, but latency to those transition
boxes is bad for his new customers.  He planned well, so maybe we
can give him one more /28 for a pop in the network he purchased.

We need to get out of the mindset that if someone has totally ignored
IPv6 transition we have something good waiting for them in the wings.
We don't.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101123/d158154c/attachment.sig>

From info at arin.net  Tue Nov 23 10:54:46 2010
From: info at arin.net (ARIN)
Date: Tue, 23 Nov 2010 10:54:46 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - November 2010
Message-ID: <4CEBE3C6.6030905@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 18 November 2010 and made decisions about
several draft policies and and a proposal.

The AC moved a revised version of the following draft policy to last
call (it will be posted separately to last call):

   2010-8: Rework of IPv6 assignment criteria

The AC recommended that the ARIN Board of Trustees adopt the following
draft policies:

   2010-10 (Global Proposal): Global Policy for IPv4 Allocations by the
IANA Post Exhaustion
   2010-12: IPv6 Subsequent Allocation

The AC revised the following sentence in 2010-12 from "Justification for
these allocations will be reviewed every 3 years and reclaimed if it is
not in use" to "Justification for transitional allocations will be
reviewed every 3 years and reclaimed if they are no longer in use for
transitional purposes."

The AC accepted the following proposal on to the AC's docket for
development and evaluation:

   120. Protecting Number Resources

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

























From info at arin.net  Tue Nov 23 10:56:16 2010
From: info at arin.net (ARIN)
Date: Tue, 23 Nov 2010 10:56:16 -0500
Subject: [arin-ppml] Draft Policy 2010-8: Rework of IPv6 assignment criteria
 - Last Call (text revised)
Message-ID: <4CEBE420.2090800@arin.net>

The ARIN Advisory Council (AC) met on 18 November 2010 and decided to
send the following draft policy to last call:

   Draft Policy 2010-8: Rework of IPv6 assignment criteria

The AC stated: "This includes the changes presented in the slides
in the meeting and an attempt to fix the language issues that staff had,
also a number of related updates to the rationale."

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2010-8
will expire on 10 December 2010. After last call the AC will conduct
their last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-8
Rework of IPv6 assignment criteria

Version/Date: 23 November 2010

Policy statement:

Replace section 6.5.8 as follows;

6.5.8. Direct assignments from ARIN to end-user organizations

6.5.8.1 Initial Assignment Criteria

Organizations may justify an initial assignment for addressing devices
directly attached to their own network infrastructure, with an intent
for the addresses to begin operational use within 12 months, by meeting
one of the following criteria:

a. Having a previously justified IPv4 end-user assignment from ARIN or
one of its predecessor registries, or;

b. Currently being IPv6 Multihomed or immediately becoming IPv6
Multihomed and using an assigned valid global AS number, or;

c. By having a network that makes active use of a minimum of 2000 IPv6
addresses within 12 months, or;

d. By having a network that makes active use of a minimum of 200 /64
subnets within 12 months, or;

e. By providing a reasonable technical justification indicating why IPv6
addresses from an ISP or other LIR are unsuitable.

Examples of justifications for why addresses from an ISP or other LIR
may be unsuitable include, but are not limited to:

? An organization that operates infrastructure critical to life safety
or the functioning of society can justify the need for an assignment
based on the fact that renumbering would have a broader than expected
impact than simply the number of hosts directly involved. These would
include: hospitals, fire fighting, police, emergency response, power or
energy distribution, water or waste treatment, traffic management and
control, etc?
? Regardless of the number of hosts directly involved, an organization
can justify the need for an assignment if renumbering would affect 2000
or more individuals either internal or external to the organization.
? An organization with a network not connected to the Internet can
justify the need for an assignment by documenting a need for guaranteed
uniqueness, beyond the statistical uniqueness provided by ULA (see RFC
4193).
? An organization with a network not connected to the Internet, such as
a VPN overlay network, can justify the need for an assignment if they
require authoritative delegation of reverse DNS.

6.5.8.2 Initial assignment size

Organizations that meet at least one of the initial assignment criteria
above are eligible to receive an initial assignment of /48. Requests for
larger initial assignments, reasonably justified with supporting
documentation, will be evaluated based on the number of sites in an
organization?s network and the number of subnets needed to support any
extra-large sites defined below.

The initial assignment size will be determined by the number of sites
justified below. An organization qualifies for an assignment on the next
larger nibble boundary when their sites exceed 75% of the /48s available
in a prefix. For example:

More than 1 but less than or equal to 12 sites justified, receives a /44
assignment;
More than 12 but less than or equal to 192 sites justified, receives a
/40 assignment;
More than 192 but less than or equal to 3,072 sites justified, receives
a /36 assignment;
More than 3,072 but less than or equal to 49,152 sites justified,
receives a /32 assignment;
etc...

6.5.8.2.1 Standard sites

A site is a discrete location that is part of an organization?s network.
A campus with multiple buildings may be considered as one or multiple
sites, based on the implementation of its network infrastructure. For a
campus to be considered as multiple sites, reasonable technical
documentation must be submitted describing how the network
infrastructure is implemented in a manner equivalent to multiple sites.

An organization may request up to a /48 for each site in its network,
and any sites that will be operational within 12 months.

6.5.8.2.2 Extra-large sites

In rare cases, an organization may request more than a /48 for an
extra-large site which requires more than 16,384 /64 subnets. In such a
case, a detailed subnet plan must be submitted for each extra-large site
in an organization?s network. An extra-large site qualifies for the next
larger prefix when the total subnet utilization exceeds 25%. Each
extra-large site will be counted as an equivalent number of /48 standard
sites.

6.5.8.3 Subsequent assignments

Requests for subsequent assignments with supporting documentation will
be evaluated based on the same criteria as an initial assignment under
6.5.8.2 with the following modifications:

a. A subsequent assignment is justified when the total utilization based
on the number of sites justified exceeds 75% across all of an
organization?s assignments. If the organization received an assignment
per section 6.11 IPv6 Multiple Discrete Networks, such assignments will
be evaluated as if they were to a separate organization.

b. When possible subsequent assignments will result it the expansion of
an existing assignment by one or more nibble boundaries as justified.

c. If it is not possible to expand an existing assignment, or to expand
it adequately to meet the justified need, then a separate new assignment
will be made of the size justified.

6.5.8.4 Consolidation and return of separate assignments

Organizations with multiple separate assignments should consolidate into
a single aggregate, if feasible. If an organization stops using one or
more of its separate assignments, any unused assignments must be
returned to ARIN.

Rationale:

This proposal provides a complete rework of the IPv6 end-user assignment
criteria, removing the dependency on IPv4 policy, providing clear
guidance in requesting larger initial assignments, and eliminating
HD-Ratio as criteria for evaluating end-user assignments.

The HD-Ratio is replaced with a simplified 75% utilization threshold
based on nibble boundaries for end-user assignments. This threshold is
somewhat more restrictive for larger assignments, while slightly less
restrictive for the smaller /44 assignments, than the HD-Ratio. However,
in both cases it is much easier for an end-user to understand the policy
criteria that applies to them.

The following general concepts are included:

? Previously justified IPv4 resources may be used to justify the need
for IPv6 resources
? Internet multihoming is sufficient justification for an IPv6 end-user
assignment in and of itself
? Networks with more than 2000 hosts have a justified need for IPv6
resources; as is the case in current policy, it is just more clearly
stated without relying on a reference to, and the consequences of, IPv4
policy
? Networks with more than 200 subnets have a justified need for IPv6
resources, independent of the number of hosts they have
? Other end-users, not meeting one of the previous criteria, must
justify why an ISP or LIR assignment is not sufficient for their needs
? Reservations are no longer necessary as ARIN has committed to sparse
assignment for IPv6
? Providing sufficiently large initial assignments based on nibble
boundaries along with sparse assignments will reduce route table growth
caused solely by subsequent assignments

Organizations with multiple sites may receive a /48 for each site in
their network. A campus with multiple buildings may be considered as one
or multiple sites, based on the implementation of its network
infrastructure. When multiple separate organizations have networks in
the same building, such as in the case of a multi-tenant building, each
organization justifies a separate /48 for its network at the site.

The 25% subnet utilization for an extra-large site is proposed as the
threshold for a larger prefix in order to allow an extra-large site
enough room to create an organized subnet plan. Requiring denser usage
would make it almost impossible for an extra-large site to maintain any
kind of organized subnet plan. Furthermore, even at 25% utilization,
more than 16,384 subnets are required to justify more than a /48 for a
site. Few, if any, sites can actually meet or exceed this threshold.

Organizations may have multiple separate assignments due to previous
subsequent assignments made per clause 6.5.8.3.c or through Mergers and
Acquisitions in section 8.2. These multiple separate assignments must be
considered in total when making subsequent assignments, unless they are
part multiple discrete networks, per section 6.11.

The ARIN Board of Trusties should consider incentives that provide
additional motivation for end-users to consolidate into a single
aggregate per section 6.5.8.4 of this policy.

Timetable for implementation: Immediate




From gbonser at seven.com  Tue Nov 23 14:26:01 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 23 Nov 2010 11:26:01 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
	Development
In-Reply-To: <20101123153414.GA14916@ussenterprise.ufp.org>
References: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com><C9101DE8.1830C%marty@akamai.com><AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com><796F94E9-2035-4A78-B454-2FF7BCA1F050@delong.com><20101123142932.GA10591@ussenterprise.ufp.org><6CC1D077-7EE4-4102-A1F3-2DD3102AB3FF@delong.com>
	<20101123153414.GA14916@ussenterprise.ufp.org>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14CB23@RWC-EX1.corp.seven.com>

> You are pitting a pair of choices against each other as if they are
the
> only two options, when the reality is there will be a continium of
> solutions in the middle.

I also believe to be true.

> ISP's will come back for more IPv4 space and get told no.  I would
hope
> a savvy ISP could set aside a /28 of their previous allocation to use
> for transition technologies at that point. 

The savvy should *already* have some space set aside for that.  They
know it is coming.  Having this space set aside at the RIR level simply
enables them not setting aside of this space now at the LIR level.  

The savvy operators should already be handing new customers at least a
/48 of v6 space for customers in PA space and a smaller chunk of v4 for
use by 6to4 and such transition technologies, or maybe providing 6 to 4
themselves if they are big enough.  The links to the customers should be
v6 where possible and with v4 tunneled over v6.

The fact that many operators that consider themselves to be major
operations are still not native v6 is going to make all of this moot, I
am afraid.  They are going to hit the wall when runout happens and then
it is going to be a mad scramble with a lot of operators all having
networks in various states of misconfiguration at the same time.

For customers with v4 PI space, they should be assisting those customers
in getting their v6 assignments NOW.

> I pick on that size only
> because it's a popular suggestion of how much space we should give the
> ISP from the /10.  The more we can encourage folks to make these sorts
> of wise decisions, the longer the /10 will prove useful.

Necessity is the mother of invention according to the old saw.  Many
operations work on a "it isn't a problem until it is a problem" basis.
They aren't going to change a thing until they have to.  Many (most?)
already have the resources to start in that direction now and not wait
for runout.  Building in more cushion simply delays things a bit.
Having the spectre of "no space available" hanging before them might be
enough to spur them to set aside some of their own space NOW and begin
moving.

> Even if the situation you describe comes to be, where folks are
> monumentally stupid and give out every last IP of their allocations
> keeping nothing to run a transition box your dire consequences still
> come true.  Giving a provider who receives a /28 or two from the last
> /10 will not change their competitiveness against another provider who
> still has half a /8 available.

I predict many are going to give out every last bit of their space
judging from the lack of progress so far.

> The last /10 isn't about making a business with no IPv4 able to
compete
> against someone who still has half a /8 left.  That is frankly,
> laughable.  What it can be about though is help for those who planned
> well and ran into unexpected consequences.

Or new operations just getting started who get a large v6 block and need
a small v4 block in order to talk to the rest of the internet.  Where
this *really* puts the damper on things is for a new operator just
getting started and I believe there are a lot of operators out there who
are going to want to hold onto v4 as long as possible after runout so it
serves as a barrier of entry to competition.  Imaging trying to start up
a new operation after v4 runout.

> We need to get out of the mindset that if someone has totally ignored
> IPv6 transition we have something good waiting for them in the wings.
> We don't.

Absolutely agree.


From owen at delong.com  Tue Nov 23 16:46:54 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 23 Nov 2010 13:46:54 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
	Development
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14CB23@RWC-EX1.corp.seven.com>
References: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com><C9101DE8.1830C%marty@akamai.com><AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com><796F94E9-2035-4A78-B454-2FF7BCA1F050@delong.com><20101123142932.GA10591@ussenterprise.ufp.org><6CC1D077-7EE4-4102-A1F3-2DD3102AB3FF@delong.com>
	<20101123153414.GA14916@ussenterprise.ufp.org>
	<5A6D953473350C4B9995546AFE9939EE0B14CB23@RWC-EX1.corp.seven.com>
Message-ID: <ACD9DD68-B8EA-41CD-BF5A-27921437F4DC@delong.com>


On Nov 23, 2010, at 11:26 AM, George Bonser wrote:

>> You are pitting a pair of choices against each other as if they are
> the
>> only two options, when the reality is there will be a continium of
>> solutions in the middle.
> 
> I also believe to be true.
> 
Sure, there is a continuum of options available, but, I was describing
the likely consequences of the two choices proposed in order to
compare and contrast them.

>> ISP's will come back for more IPv4 space and get told no.  I would
> hope
>> a savvy ISP could set aside a /28 of their previous allocation to use
>> for transition technologies at that point. 
> 
> The savvy should *already* have some space set aside for that.  They
> know it is coming.  Having this space set aside at the RIR level simply
> enables them not setting aside of this space now at the LIR level.  
> 
What about operators that do not exist today?

What about operators that grow beyond their current ability to set aside
space?

> The savvy operators should already be handing new customers at least a
> /48 of v6 space for customers in PA space and a smaller chunk of v4 for
> use by 6to4 and such transition technologies, or maybe providing 6 to 4
> themselves if they are big enough.  The links to the customers should be
> v6 where possible and with v4 tunneled over v6.
> 
6to4 is utterly and completely useless if you have native IPv6. The purpose
of the IPv4 is addresses in 4.10 is to enable technologies at the SP level
such as NAT64 and DS-LITE. Technologies which allow native IPv6
customers to reach content and services only available over IPv4
and which have a high leverage ratio of subscribers:address.

In contrast, 6to4 is a way to allow a machine which does not have IPv6
connectivity to reach IPv6 content by using a dynamic stateless tunnel.

> The fact that many operators that consider themselves to be major
> operations are still not native v6 is going to make all of this moot, I
> am afraid.  They are going to hit the wall when runout happens and then
> it is going to be a mad scramble with a lot of operators all having
> networks in various states of misconfiguration at the same time.
> 
Hence my belief that with such a large number in this situation, prudent
stewardship of the address space requires us to use the collective
wisdom of the community to back-stop this behavior for the good of
the internet. As much as I generally oppose rewarding bad behavior,
this is a case where the collateral damage exceeds the direct
results of the bad behavior.

> For customers with v4 PI space, they should be assisting those customers
> in getting their v6 assignments NOW.
> 
Yep.

>> I pick on that size only
>> because it's a popular suggestion of how much space we should give the
>> ISP from the /10.  The more we can encourage folks to make these sorts
>> of wise decisions, the longer the /10 will prove useful.
> 
> Necessity is the mother of invention according to the old saw.  Many
> operations work on a "it isn't a problem until it is a problem" basis.
> They aren't going to change a thing until they have to.  Many (most?)
> already have the resources to start in that direction now and not wait
> for runout.  Building in more cushion simply delays things a bit.
> Having the spectre of "no space available" hanging before them might be
> enough to spur them to set aside some of their own space NOW and begin
> moving.
> 
That's a very dangerous game of chicken because it puts us on a
road where we can't flinch if the other guy doesn't. The old saw also
says "hope for the best, plan for the worst."


>> Even if the situation you describe comes to be, where folks are
>> monumentally stupid and give out every last IP of their allocations
>> keeping nothing to run a transition box your dire consequences still
>> come true.  Giving a provider who receives a /28 or two from the last
>> /10 will not change their competitiveness against another provider who
>> still has half a /8 available.
> 
> I predict many are going to give out every last bit of their space
> judging from the lack of progress so far.
> 
Yep.

>> The last /10 isn't about making a business with no IPv4 able to
> compete
>> against someone who still has half a /8 left.  That is frankly,
>> laughable.  What it can be about though is help for those who planned
>> well and ran into unexpected consequences.
> 
It was not my intention to say that it was. However, there is a difference
between the way this happens as a natural result of runout and having
ARIN actually participate in creating or exacerbating the situation.

> Or new operations just getting started who get a large v6 block and need
> a small v4 block in order to talk to the rest of the internet.  Where
> this *really* puts the damper on things is for a new operator just
> getting started and I believe there are a lot of operators out there who
> are going to want to hold onto v4 as long as possible after runout so it
> serves as a barrier of entry to competition.  Imaging trying to start up
> a new operation after v4 runout.
> 
Yes, this is much more in line with the intent of 4.10, although it is also
meant to backstop those organizations that run out and need small
quantities of IPv4 addresses for high subscriber leverage transitional
purposes.

If you want a list of the ponies that people will try to demand when we
open this Pandora's box, you need look no further than the version
of 2010-13 presented in Atlanta compared to the version that originally
went to the petition process.

>> We need to get out of the mindset that if someone has totally ignored
>> IPv6 transition we have something good waiting for them in the wings.
>> We don't.
> 
> Absolutely agree.

I couldn't agree more. If one assumes I have such a mindset, one has
not been paying attention for some time.

Owen



From gbonser at seven.com  Tue Nov 23 18:13:29 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 23 Nov 2010 15:13:29 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
	Development
In-Reply-To: <ACD9DD68-B8EA-41CD-BF5A-27921437F4DC@delong.com>
References: <AANLkTin-SNqKEi4DFUk+2aCns9FK0rHe+1TydE47hSmA@mail.gmail.com><C9101DE8.1830C%marty@akamai.com><AANLkTi=kbDX9fpTvNHtscb=GkTpddZfbeALdQdLdXELU@mail.gmail.com><796F94E9-2035-4A78-B454-2FF7BCA1F050@delong.com><20101123142932.GA10591@ussenterprise.ufp.org><6CC1D077-7EE4-4102-A1F3-2DD3102AB3FF@delong.com>
	<20101123153414.GA14916@ussenterprise.ufp.org>
	<5A6D953473350C4B9995546AFE9939EE0B14CB23@RWC-EX1.corp.seven.com>
	<ACD9DD68-B8EA-41CD-BF5A-27921437F4DC@delong.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14CB2F@RWC-EX1.corp.seven.com>

> 
> >> The last /10 isn't about making a business with no IPv4 able to
> > compete
> >> against someone who still has half a /8 left.  That is frankly,
> >> laughable.  What it can be about though is help for those who
> planned
> >> well and ran into unexpected consequences.
> >
> It was not my intention to say that it was. However, there is a
> difference
> between the way this happens as a natural result of runout and having
> ARIN actually participate in creating or exacerbating the situation.

I believe what Leo was getting at was that we could set the space aside
yet not designate yet exactly what it is to be used for.  That allows us
some leeway once we see how the chips actually fall.  If we attempt to
designate a specific purpose for those addresses now and it turns out
the addresses need to be used for something quite unforeseen, then we
are stuck with more addresses reserved for something then we need and
not enough for something else.  We don't want to paint ourselves into a
box and being vague now gives options later.  Once some time passes and
we see where the critical needs actually are, we can then assign those
resources where they can be most efficiently utilized.  Attempting to
look into a crystal ball now and tell where the pain is going to be a
year from now is likely impossible.  

In fact, there are going to be so many networks that have waited until
the last possible moment that connectivity problems are going to be
difficult to sort out because they won't know if the problem is in their
network or at the other end because both ends are attempting to migrate
at the same time.  THEY aren't even going to really know what they need
and will be in a mode of just taking everything they can get because
they don't know if they are going to need it or not.  If we wait a
little while, networks will have a better idea of exactly where there
needs are.

If we open up "transitional space" then everyone on the planet is going
to want some "just in case".  If we don't open it up, they will allocate
some of their own space, get things going, and then if they need more,
they will have a better idea of exactly what they need.  I think Leo was
saying not to put too fine a point on things yet.


> >> We need to get out of the mindset that if someone has totally
> ignored
> >> IPv6 transition we have something good waiting for them in the
> wings.
> >> We don't.
> >
> > Absolutely agree.
> 
> I couldn't agree more. If one assumes I have such a mindset, one has
> not been paying attention for some time.

Oh, I don't think anyone was accusing you of having such a mindset.  It
was just that I believe Leo was saying that laying out too much now
might give the impression to some operators out there "we don't have to
worry about that right now, we can just get some 'transitional space'
when the time comes." And it enables additional procrastination by some
operators who may read the thing the wrong way.  Reserve the space but
be vague on exactly how much is to be used for what.  In fact, I would
merge CI and IPv6 transition into one larger block that either use could
be drawn from.  We don't know how much will be needed for what function
but man, I hope there isn't a lot of CI currently being rolled out on
v4.

And I think I miscommunicated the tunneling thing.  I wasn't talking
about 6to4 per the way people have been trying to standardize it.  I was
thinking more like:  "Here is your connection to us.  It is v6.  You can
build a GRE tunnel on your router to send v4 traffic to our v4 router
because our edge units are now v6 only, not dual-stacked.  Oh, and set
your MTU on that link to 9000 so you don't introduce PMTUD issues on
that tunnel".




From marty at akamai.com  Wed Nov 24 03:02:01 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 24 Nov 2010 03:02:01 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <20101123153414.GA14916@ussenterprise.ufp.org>
Message-ID: <C9129319.1882C%marty@akamai.com>




On 11/23/10 5:34 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:


> 
> I agree with your statement, but I also believe there's enough
> information to get everyone on the same page.  When we have only a
> /10 left, everyone is screwed.  There is no using that /10 to make
> even 1/1000th of the people happy.  We're out, done, and if your
> business depends on it you might as well go ahead and turn out the
> lights.  I've not seen a single person suggest how the last /10
> could save businesses that have failed to plan.

I think that there's almost enough information to get people on the same
page. We're still not sure what the "final" inventory of address space will
be with respect to the last /8's; 3 x /8 at the end or 1 x /8 at the end to
add to whatever may be in reserve. Reserve pools are allowed for under the
current global allocation policy and are not counted when seeking new /8's.

[ clip ]
 
> We need to get out of the mindset that if someone has totally ignored
> IPv6 transition we have something good waiting for them in the wings.
> We don't.

The idea is somewhat of a continued transition and supporting the presence
of a v4 network for "some" period of time beyond exhaustion, among other
things, isn't it?



From packetgrrl at gmail.com  Wed Nov 24 03:28:45 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Wed, 24 Nov 2010 01:28:45 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy - revised
In-Reply-To: <4CC83D28.90100@arin.net>
References: <4CC83D28.90100@arin.net>
Message-ID: <AANLkTinHFWeRcVOasiKBzZdUff2ZL3sZt+D6YVXEhjzv@mail.gmail.com>

Who decides whether the " two
RIRs agree and exercise Internet stewardship and the values expressed in
RFC2050."  ?

Who makes the process for that?  What happens if they don't agree?

On Wed, Oct 27, 2010 at 8:54 AM, ARIN <info at arin.net> wrote:

> The proposal originator submitted a revised version of the proposal.
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal 119: Globally Coordinated Transfer Policy
>
> Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller
>
> Proposal Version: 2.0
>
> Date: 27 October 2010
>
> Proposal type: new
>
> Policy term: permanent
>
> Policy statement: Any RIR's resource registrant may transfer IPv4
> addresses to the resource registrant of another RIR as long as the two
> RIRs agree and exercise Internet stewardship and the values expressed in
> RFC2050.
>
> Rationale: Since individual RIRs now allow transfers, it makes sense to
> be able to transfer between regions as well.
>
> Timetable for implementation: upon ratification of all five RIRs
>
> Timetable for de-implementation: upon change to this policy text in any RIR
>
>
>
> _______________________________________________
> 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/20101124/a60f31af/attachment.htm>

From jcurran at arin.net  Wed Nov 24 04:29:52 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 24 Nov 2010 04:29:52 -0500
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy - revised
In-Reply-To: <AANLkTinHFWeRcVOasiKBzZdUff2ZL3sZt+D6YVXEhjzv@mail.gmail.com>
References: <4CC83D28.90100@arin.net>
	<AANLkTinHFWeRcVOasiKBzZdUff2ZL3sZt+D6YVXEhjzv@mail.gmail.com>
Message-ID: <44B0BDFB-5D2D-4548-81D7-AB49C95D1470@arin.net>

On Nov 24, 2010, at 3:28 AM, cja at daydream.com wrote:

> Who decides whether the " two
> RIRs agree and exercise Internet stewardship and the values expressed in
> RFC2050."  ?
> 
> Who makes the process for that?  What happens if they don't agree?  

Cathy - 
 
   Short of any additional guidance in the policy, I can explain how ARIN 
   staff would implement that language.  In the case of ARIN, we would
   maintain of a list of RIRs which we've reviewed and concur implement
   the principles in RFC 2050.  I imagine that the other RIRs would make
   similar assessments & lists, and in the case of mutual alignment, then
   inter-RIR transfers would be possible.

   This actually shouldn't be too difficult, since it is common for the RIRs
   to reference these principles in their policy framework and further that
   each RIR has agreed to them as part of setting the ICANN ICP-2 global 
   policy for recognition of an Regional Internet Registry.

   The language appears to be far more likely relevant if a RIR to abandon
   the stewardship principles in the future, as then we would not be able to 
   participate in transfers via that entity (i.e. whether such an entity would 
   still qualify as an RIR under such circumstances is a different question)

Does this address your question?

/John

John Curran
President and CEO
ARIN

   

From packetgrrl at gmail.com  Wed Nov 24 05:13:56 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Wed, 24 Nov 2010 03:13:56 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy - revised
In-Reply-To: <44B0BDFB-5D2D-4548-81D7-AB49C95D1470@arin.net>
References: <4CC83D28.90100@arin.net>
	<AANLkTinHFWeRcVOasiKBzZdUff2ZL3sZt+D6YVXEhjzv@mail.gmail.com>
	<44B0BDFB-5D2D-4548-81D7-AB49C95D1470@arin.net>
Message-ID: <AANLkTinKbPaH4z2wPOKFTVKyED+2BUOyRnXfdRzjw2go@mail.gmail.com>

Thanks John.. so basically you would sort of "certify" other RIRs based on
their adherence to "principles of RFC 2050" and then go forward allowing
transfers and periodically review whether each RIR still meets that
requirement.  That sounds fair to me.

----Cathy

On Wed, Nov 24, 2010 at 2:29 AM, John Curran <jcurran at arin.net> wrote:

> On Nov 24, 2010, at 3:28 AM, cja at daydream.com wrote:
>
> > Who decides whether the " two
> > RIRs agree and exercise Internet stewardship and the values expressed in
> > RFC2050."  ?
> >
> > Who makes the process for that?  What happens if they don't agree?
>
> Cathy -
>
>   Short of any additional guidance in the policy, I can explain how ARIN
>   staff would implement that language.  In the case of ARIN, we would
>   maintain of a list of RIRs which we've reviewed and concur implement
>   the principles in RFC 2050.  I imagine that the other RIRs would make
>   similar assessments & lists, and in the case of mutual alignment, then
>   inter-RIR transfers would be possible.
>
>   This actually shouldn't be too difficult, since it is common for the RIRs
>   to reference these principles in their policy framework and further that
>   each RIR has agreed to them as part of setting the ICANN ICP-2 global
>   policy for recognition of an Regional Internet Registry.
>
>   The language appears to be far more likely relevant if a RIR to abandon
>   the stewardship principles in the future, as then we would not be able to
>   participate in transfers via that entity (i.e. whether such an entity
> would
>   still qualify as an RIR under such circumstances is a different question)
>
> Does this address your question?
>
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101124/7d42807d/attachment.htm>

From packetgrrl at gmail.com  Wed Nov 24 05:22:51 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Wed, 24 Nov 2010 03:22:51 -0700
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy - revised
In-Reply-To: <4CC83D28.90100@arin.net>
References: <4CC83D28.90100@arin.net>
Message-ID: <AANLkTikAkGDd4rNBoni6-Z=rLTgYgmW720RAOzqtd4rt@mail.gmail.com>

How do folks feel about how transfers between regions would affect the
routing table?   We would be in essence punching holes in RIR blocks.   This
depends entirely on whether there are ISPs filtering or aggregating on
regional boundaries based on RIR /8 block allocations.

Thanks!
----Cathy


On Wed, Oct 27, 2010 at 8:54 AM, ARIN <info at arin.net> wrote:

> The proposal originator submitted a revised version of the proposal.
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal 119: Globally Coordinated Transfer Policy
>
> Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller
>
> Proposal Version: 2.0
>
> Date: 27 October 2010
>
> Proposal type: new
>
> Policy term: permanent
>
> Policy statement: Any RIR's resource registrant may transfer IPv4
> addresses to the resource registrant of another RIR as long as the two
> RIRs agree and exercise Internet stewardship and the values expressed in
> RFC2050.
>
> Rationale: Since individual RIRs now allow transfers, it makes sense to
> be able to transfer between regions as well.
>
> Timetable for implementation: upon ratification of all five RIRs
>
> Timetable for de-implementation: upon change to this policy text in any RIR
>
>
>
> _______________________________________________
> 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/20101124/0ff03226/attachment.htm>

From BillD at cait.wustl.edu  Wed Nov 24 08:08:19 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 24 Nov 2010 07:08:19 -0600
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy - revised
References: <4CC83D28.90100@arin.net><AANLkTinHFWeRcVOasiKBzZdUff2ZL3sZt+D6YVXEhjzv@mail.gmail.com><44B0BDFB-5D2D-4548-81D7-AB49C95D1470@arin.net>
	<AANLkTinKbPaH4z2wPOKFTVKyED+2BUOyRnXfdRzjw2go@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D0308791549C@ex1.cait.wustl.edu>

John, all,

So you would look at 'current policy' in each RIR to assess conformance with the specifics outlined in 205O associated with conservation, routability and registration?  Assuming that conforming policy existed in an RIR, what mechanism would you presume that would document that conformance in establishing a needs basis for transfers?

That is, if a requester in another RIR wants addresses from a constituent in the ARIN region, how would ARIN assess that the request conforms to the policy of ARIN for allocation?...or would ARIN simply assess that the RIR from which the request comes from, has needs-based policy...and therefore the request must be legitimate?

The reverse of course would be much simpler as the ARIN constituent requesting address space from another RIR's constituent would have to qualify under ARIN policy and be vetted accordingly, yes?

bd



-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of cja at daydream.com
Sent: Wed 11/24/2010 4:13 AM
To: John Curran
Cc: arin-ppml at arin.net List
Subject: Re: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer Policy - revised
 
Thanks John.. so basically you would sort of "certify" other RIRs based on
their adherence to "principles of RFC 2050" and then go forward allowing
transfers and periodically review whether each RIR still meets that
requirement.  That sounds fair to me.

----Cathy

On Wed, Nov 24, 2010 at 2:29 AM, John Curran <jcurran at arin.net> wrote:

> On Nov 24, 2010, at 3:28 AM, cja at daydream.com wrote:
>
> > Who decides whether the " two
> > RIRs agree and exercise Internet stewardship and the values expressed in
> > RFC2050."  ?
> >
> > Who makes the process for that?  What happens if they don't agree?
>
> Cathy -
>
>   Short of any additional guidance in the policy, I can explain how ARIN
>   staff would implement that language.  In the case of ARIN, we would
>   maintain of a list of RIRs which we've reviewed and concur implement
>   the principles in RFC 2050.  I imagine that the other RIRs would make
>   similar assessments & lists, and in the case of mutual alignment, then
>   inter-RIR transfers would be possible.
>
>   This actually shouldn't be too difficult, since it is common for the RIRs
>   to reference these principles in their policy framework and further that
>   each RIR has agreed to them as part of setting the ICANN ICP-2 global
>   policy for recognition of an Regional Internet Registry.
>
>   The language appears to be far more likely relevant if a RIR to abandon
>   the stewardship principles in the future, as then we would not be able to
>   participate in transfers via that entity (i.e. whether such an entity
> would
>   still qualify as an RIR under such circumstances is a different question)
>
> Does this address your question?
>
> /John
>
> John Curran
> President and CEO
> ARIN
>
>

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

From jcurran at arin.net  Wed Nov 24 09:16:17 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 24 Nov 2010 09:16:17 -0500
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy - revised
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D0308791549C@ex1.cait.wustl.edu>
References: <4CC83D28.90100@arin.net><AANLkTinHFWeRcVOasiKBzZdUff2ZL3sZt+D6YVXEhjzv@mail.gmail.com><44B0BDFB-5D2D-4548-81D7-AB49C95D1470@arin.net>
	<AANLkTinKbPaH4z2wPOKFTVKyED+2BUOyRnXfdRzjw2go@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D0308791549C@ex1.cait.wustl.edu>
Message-ID: <BA0EFE72-E81B-4253-99C5-8835CB783565@arin.net>

> On Nov 24, 2010, at 8:08 AM, Bill Darte wrote:
> 
> John, all,
> 
> So you would look at 'current policy' in each RIR to assess conformance with the specifics outlined in 2050 associated with conservation, routability and registration?  Assuming that conforming policy existed in an RIR, what mechanism would you presume that would document that conformance in establishing a needs basis for transfers?
>  
> That is, if a requester in another RIR wants addresses from a constituent in the ARIN region, how would ARIN assess that the request conforms to the policy of ARIN for allocation?...or would ARIN simply assess that the RIR from which the request comes from, has needs-based policy...and therefore the request must be legitimate?

Bill - As long as the request comes from an party in a region where the RIR which conforms to RFC2050 principles, ARIN would accept the request for processing.  ARIN would agree to the transfer request if the transferrer, being in the ARIN region, met the specifics of ARIN's transfer policy.

> The reverse of course would be much simpler as the ARIN constituent requesting address space from another RIR's constituent would have to qualify under ARIN policy and be vetted accordingly, yes?

ARIN would accept to the transfer request if the transferee, being in the ARIN region, met the specifics of ARIN's transfer policy and the RIR of the transferrer conformed to RFC2050 principles.

Does this address your question?
/John

John Curran
President and CEO
ARIN




From info at arin.net  Wed Nov 24 09:34:32 2010
From: info at arin.net (ARIN)
Date: Wed, 24 Nov 2010 09:34:32 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - October 2010
In-Reply-To: <4CB5F5D5.2020807@arin.net>
References: <4CB5F5D5.2020807@arin.net>
Message-ID: <4CED2278.5000000@arin.net>

> The deadline to begin a petition will be five
> business days after the AC's draft meeting minutes are published.

The minutes from the Advisory Council's 8 October 2010 meeting were
published and are available at:
https://www.arin.net/about_us/ac/index.html

The abandonment of 2010-9, 2010-11, and 2010-13, and the decision to not
send 2010-14 to last call are actions that can still be petitioned. The
petition deadline is 5 December 2010.

For more information on starting and participating in petitions, see PDP
Petitions at: https://www.arin.net/policy/pdp_petitions.html

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


ARIN wrote:
> In accordance with the ARIN Policy Development Process the ARIN Advisory
> Council (AC) held a meeting on 8 October 2010 and made decisions about
> several draft policies.
>
> The AC moved the following draft policy to last call (it will be posted
> separately to last call):
>
>   2010-12: IPv6 Subsequent Allocation
>
> The AC abandoned the following draft policies:
>
>   2010-9: IPv6 for 6rd
>   2010-11: Required Resource Reviews
>   2010-13: Permitted Uses of space reserved under NRPM 4.10
>
> The AC chose 2010-12 over 2010-9. 2010-13 was abandoned due to lack of
> support.
>
> The AC stated the following about 2010-11:
> "We understand that the community is concerned about seemingly limited
> application of NRPM section 12, however, we believe that a combination
> of factors have rendered the need for this policy moot at this time:
>   1. Staff has agreed to produce and publish statistics regarding the
> application and results of NRPM 12.
>   2. The community seems roughly evenly divided on the application of
> this policy. An even split is not consensus.
>   3. We believe staff has received the message from the community that
> we want them to make greater efforts to enforce ARIN policies through
> the use of NRPM 12."
>
> The following draft policies remain on the AC's docket for further
> development and evaluation:
>
>   2010-8: Rework of IPv6 assignment criteria
>   2010-14: Standardize IP Reassignment Registration Requirements
>
> The following draft policy was tabled until the AC's next meeting:
>
>   2010-10 (Global Proposal): Global Policy for IPv4 Allocations by the
> IANA Post Exhaustion
>
> Several of the AC's decisions may be petitioned. This includes the draft
> policies that were abandoned (2010-9, 2010-11, 2010-13) and the drafts
> that were not selected for last call (2010-8, 2010-10, 2010-14). Anyone
> dissatisfied with these decisions may initiate a "Last Call Petition."
> The purpose of a petition at this time is to try to send the draft
> policy to last call. The deadline to begin a petition will be five
> business days after the AC's draft meeting minutes are published. For
> more information on starting and participating in petitions, see PDP
> Petitions at: https://www.arin.net/policy/pdp_petitions.html
>
> Draft Policy and Proposal texts are available at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>





From bicknell at ufp.org  Wed Nov 24 09:37:51 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 24 Nov 2010 06:37:51 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C9129319.1882C%marty@akamai.com>
References: <20101123153414.GA14916@ussenterprise.ufp.org>
	<C9129319.1882C%marty@akamai.com>
Message-ID: <20101124143751.GA6701@ussenterprise.ufp.org>

In a message written on Wed, Nov 24, 2010 at 03:02:01AM -0500, Hannigan, Martin wrote:
> I think that there's almost enough information to get people on the same
> page. We're still not sure what the "final" inventory of address space will
> be with respect to the last /8's; 3 x /8 at the end or 1 x /8 at the end to
> add to whatever may be in reserve. Reserve pools are allowed for under the
> current global allocation policy and are not counted when seeking new /8's.

I am confused by your statement.  My understanding of the current
policy framework is that ARIN will allocate all IP space not reserved
for some purpose, and the only reservations I know of are the /10
we're discussing and the /16 proposed for CI.  There is no other
inventory.

> > We need to get out of the mindset that if someone has totally ignored
> > IPv6 transition we have something good waiting for them in the wings.
> > We don't.
> 
> The idea is somewhat of a continued transition and supporting the presence
> of a v4 network for "some" period of time beyond exhaustion, among other
> things, isn't it?

I have always seen what you describe as a stretch goal.  It's not
so far out of reach I would call it impossible, but I also don't
have any confidence that we can reach it.

My largest concern is that we seem to be going into this situation
with a bit too much confidence.  Many folks feel confident that
after runout (IANA+ARIN) what we will need is a pool of space for
transition technologies.  I think that is likely but not certain,
and I also think there are other possibilities.

In any large transition like this there will be unforeseen circumstances.
By their very nature they can't be predicted, so there is no way
to plan for them now other than having a pool of resources available.
It's the equivalent to a fire department; you can't predict where
and when a fire or car crash will occur, but it is prudent to invest
in equipment and training because something will happen.

It is for this reason I am very down on deciding what to do with
the last /10 ahead of time.  I can see a spectrum of possibilities,
from the chance of allowing first time resource recipients a
competitive foothold to it being barely enough to keep critical and
necessary services online.  The only way to know is to go through
exhaustion and come out the other side, and where the chips fall.

To put it simply, we have set aside a "Dedicated IPv4 block to
facilitate IPv6 Deployment", and I am arguing that we may need a
"Dedicated IPv4 block to keep the IPv4 internet from falling apart".
I can't be sure though, and I can't be sure we can't do both.
Reserve it all, find out what goes wrong and where the need is
greatest, and then pass a policy quickly to address it.  1-3 months
of no space followed by relief where it is needed most is far more
useful than the chance blowing the space on something other than
the greatest need.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101124/59710c53/attachment.sig>

From marty at akamai.com  Wed Nov 24 09:56:45 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 24 Nov 2010 09:56:45 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <20101124143751.GA6701@ussenterprise.ufp.org>
Message-ID: <C912F44D.18927%marty@akamai.com>




On 11/24/10 4:37 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:

> In a message written on Wed, Nov 24, 2010 at 03:02:01AM -0500, Hannigan,
> Martin wrote:
>> I think that there's almost enough information to get people on the same
>> page. We're still not sure what the "final" inventory of address space will
>> be with respect to the last /8's; 3 x /8 at the end or 1 x /8 at the end to
>> add to whatever may be in reserve. Reserve pools are allowed for under the
>> current global allocation policy and are not counted when seeking new /8's.
> 
> I am confused by your statement.  My understanding of the current
> policy framework is that ARIN will allocate all IP space not reserved
> for some purpose, and the only reservations I know of are the /10
> we're discussing and the /16 proposed for CI.  There is no other
> inventory.


My first point was that perhaps a /10 is too small. The other point related
to inventory was related to current RIR inventories. When an RIR applies to
the IANA they have utilization requirements like we do. One of those
requirements allows an RIR to mark "pools" as reserved. When the
requirements are tallied, the pools marked reserved are counted as 100% used
even if they are not used.

Hence, we don't know what the ARIN inventory will be at the point of the
issuance of the last /8. There are 6 /8's available now from the IANA. RIR's
typically, historically, receive two. That leaves four RIR's that "may"
become eligible to receive /8's from the IANA since Afrinic took one out of
seven that were available last week.

Let's stretch a bit:


"The date, frankly, is about to hit you in the head, and it's in January.
And in all likelihood that's when the trigger will occur. You know right now
when the date is. And it could come faster, by the way. It could come very
much faster, depending on the drawdown rate. The drawdown rate is
increasing, not slowing. And, therefore, I don't think we should spend any
energy."

        --Steve Ryan, ARIN Counsel


Six would seem like more than enough to get us through January, perhaps even
February. Theoretically, the next three RIR's that become eligible for the
allocation of two /8's from the IANA will receive the six. Then the cliff
allocation of the last 5 /8's will occur and IANA is at zero. I don't know
what ARIN has in reserved pools and if they are used. Do you? It's possible
that _any_ RIR could end up with more than 3 x /8 depending upon their
"luck" as I think that the days of coordinating draw down have come to a
close. My understanding is that the AfriNIC draw was, erm, un-timed.

It's likely that three RIR's will end the game with 2 x /8 + 1 x /8 from the
final allocation and one will end up with 1 x /8.


That probably made things more confusing. Sorry.


Best,

-M<




From bicknell at ufp.org  Wed Nov 24 10:18:09 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 24 Nov 2010 07:18:09 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C912F44D.18927%marty@akamai.com>
References: <20101124143751.GA6701@ussenterprise.ufp.org>
	<C912F44D.18927%marty@akamai.com>
Message-ID: <20101124151809.GA10846@ussenterprise.ufp.org>

In a message written on Wed, Nov 24, 2010 at 09:56:45AM -0500, Hannigan, Martin wrote:
> It's likely that three RIR's will end the game with 2 x /8 + 1 x /8 from the
> final allocation and one will end up with 1 x /8.
> 
> That probably made things more confusing. Sorry.

I follow you now.

FWIW, to me the end game outcomes don't change my opinion on this
(or any other) end of time policy, so I didn't immediately see how
the discussion was related.

How the end game plays out will have an impact on the community,
but to me it does not change what you have to do after the end game,
just how soon you have to do it.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101124/bdae4a2f/attachment.sig>

From scottleibrand at gmail.com  Wed Nov 24 10:56:22 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 24 Nov 2010 07:56:22 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <20101124143751.GA6701@ussenterprise.ufp.org>
References: <20101123153414.GA14916@ussenterprise.ufp.org>
	<C9129319.1882C%marty@akamai.com>
	<20101124143751.GA6701@ussenterprise.ufp.org>
Message-ID: <D5EDF396-2E1F-49BF-8336-68D7F4990D69@gmail.com>

What about reserving an additional block, rather than 4.10's /10, for this purpose?

I'm not sure if we'd want to, but that might be better than suspending 4.10...

Scott

On Nov 24, 2010, at 6:37 AM, Leo Bicknell <bicknell at ufp.org> wrote:

> In a message written on Wed, Nov 24, 2010 at 03:02:01AM -0500, Hannigan, Martin wrote:
>> I think that there's almost enough information to get people on the same
>> page. We're still not sure what the "final" inventory of address space will
>> be with respect to the last /8's; 3 x /8 at the end or 1 x /8 at the end to
>> add to whatever may be in reserve. Reserve pools are allowed for under the
>> current global allocation policy and are not counted when seeking new /8's.
> 
> I am confused by your statement.  My understanding of the current
> policy framework is that ARIN will allocate all IP space not reserved
> for some purpose, and the only reservations I know of are the /10
> we're discussing and the /16 proposed for CI.  There is no other
> inventory.
> 
>>> We need to get out of the mindset that if someone has totally ignored
>>> IPv6 transition we have something good waiting for them in the wings.
>>> We don't.
>> 
>> The idea is somewhat of a continued transition and supporting the presence
>> of a v4 network for "some" period of time beyond exhaustion, among other
>> things, isn't it?
> 
> I have always seen what you describe as a stretch goal.  It's not
> so far out of reach I would call it impossible, but I also don't
> have any confidence that we can reach it.
> 
> My largest concern is that we seem to be going into this situation
> with a bit too much confidence.  Many folks feel confident that
> after runout (IANA+ARIN) what we will need is a pool of space for
> transition technologies.  I think that is likely but not certain,
> and I also think there are other possibilities.
> 
> In any large transition like this there will be unforeseen circumstances.
> By their very nature they can't be predicted, so there is no way
> to plan for them now other than having a pool of resources available.
> It's the equivalent to a fire department; you can't predict where
> and when a fire or car crash will occur, but it is prudent to invest
> in equipment and training because something will happen.
> 
> It is for this reason I am very down on deciding what to do with
> the last /10 ahead of time.  I can see a spectrum of possibilities,
> from the chance of allowing first time resource recipients a
> competitive foothold to it being barely enough to keep critical and
> necessary services online.  The only way to know is to go through
> exhaustion and come out the other side, and where the chips fall.
> 
> To put it simply, we have set aside a "Dedicated IPv4 block to
> facilitate IPv6 Deployment", and I am arguing that we may need a
> "Dedicated IPv4 block to keep the IPv4 internet from falling apart".
> I can't be sure though, and I can't be sure we can't do both.
> Reserve it all, find out what goes wrong and where the need is
> greatest, and then pass a policy quickly to address it.  1-3 months
> of no space followed by relief where it is needed most is far more
> useful than the chance blowing the space on something other than
> the greatest need.
> 
> -- 
>       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 owen at delong.com  Wed Nov 24 16:08:38 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 24 Nov 2010 13:08:38 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <20101124143751.GA6701@ussenterprise.ufp.org>
References: <20101123153414.GA14916@ussenterprise.ufp.org>
	<C9129319.1882C%marty@akamai.com>
	<20101124143751.GA6701@ussenterprise.ufp.org>
Message-ID: <AF383344-6363-46DE-921F-5C2734C65C4C@delong.com>

> 
> To put it simply, we have set aside a "Dedicated IPv4 block to
> facilitate IPv6 Deployment", and I am arguing that we may need a
> "Dedicated IPv4 block to keep the IPv4 internet from falling apart".
> I can't be sure though, and I can't be sure we can't do both.
> Reserve it all, find out what goes wrong and where the need is
> greatest, and then pass a policy quickly to address it.  1-3 months
> of no space followed by relief where it is needed most is far more
> useful than the chance blowing the space on something other than
> the greatest need.
> 
We know we will need a dedicated IPv4 block to facilitate IPv6
deployment.

We may need a dedicated IPv4 block to keep the IPv4 internet from
falling apart (if such is even actually possible, I have my doubts).

Seems to me that it is imprudent to raid the block we know we need
to create the block we may need.

Hence my suggestion that 122 would be more palatable if it set aside
a separate /10 for that purpose rather than raiding 4.10.

Owen



From owen at delong.com  Wed Nov 24 15:59:38 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 24 Nov 2010 12:59:38 -0800
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy - revised
In-Reply-To: <AANLkTikAkGDd4rNBoni6-Z=rLTgYgmW720RAOzqtd4rt@mail.gmail.com>
References: <4CC83D28.90100@arin.net>
	<AANLkTikAkGDd4rNBoni6-Z=rLTgYgmW720RAOzqtd4rt@mail.gmail.com>
Message-ID: <B804AE09-BD9A-41D6-9F06-D699D753982B@delong.com>

I doubt anyone can really do such aggregation these days. There are all kinds of
cases of addresses obtained by global companies from the RIR where HQ is or
where they have some portion of their infrastructure and having some of that
space deployed in other regions, etc.

I don't see the routing table as a major factor here.

It could affect in-addr delegation, but, I would expect that impact to be minor.

FWIW, RIPE is now starting to talk about implementing a no-holds-barred
transfer policy as well.

Owen

On Nov 24, 2010, at 2:22 AM, cja at daydream.com wrote:

> 
> How do folks feel about how transfers between regions would affect the routing table?   We would be in essence punching holes in RIR blocks.   This depends entirely on whether there are ISPs filtering or aggregating on regional boundaries based on RIR /8 block allocations.  
> 
> Thanks!
> ----Cathy
> 
> 
> On Wed, Oct 27, 2010 at 8:54 AM, ARIN <info at arin.net> wrote:
> The proposal originator submitted a revised version of the proposal.
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal 119: Globally Coordinated Transfer Policy
> 
> Proposal Originator: Chris Grundemann, Martin Hannigan, Jason Schiller
> 
> Proposal Version: 2.0
> 
> Date: 27 October 2010
> 
> Proposal type: new
> 
> Policy term: permanent
> 
> Policy statement: Any RIR's resource registrant may transfer IPv4
> addresses to the resource registrant of another RIR as long as the two
> RIRs agree and exercise Internet stewardship and the values expressed in
> RFC2050.
> 
> Rationale: Since individual RIRs now allow transfers, it makes sense to
> be able to transfer between regions as well.
> 
> Timetable for implementation: upon ratification of all five RIRs
> 
> Timetable for de-implementation: upon change to this policy text in any RIR
> 
> 
> 
> _______________________________________________
> 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/20101124/cbb3866c/attachment.htm>

From bicknell at ufp.org  Wed Nov 24 16:53:43 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 24 Nov 2010 13:53:43 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <AF383344-6363-46DE-921F-5C2734C65C4C@delong.com>
References: <20101123153414.GA14916@ussenterprise.ufp.org>
	<C9129319.1882C%marty@akamai.com>
	<20101124143751.GA6701@ussenterprise.ufp.org>
	<AF383344-6363-46DE-921F-5C2734C65C4C@delong.com>
Message-ID: <20101124215343.GA65650@ussenterprise.ufp.org>

In a message written on Wed, Nov 24, 2010 at 01:08:38PM -0800, Owen DeLong wrote:
> Hence my suggestion that 122 would be more palatable if it set aside
> a separate /10 for that purpose rather than raiding 4.10.

I would not object to a second /10, but I'm sure I see it as necessary.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101124/5bdab670/attachment.sig>

From marty at akamai.com  Wed Nov 24 18:57:00 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Wed, 24 Nov 2010 18:57:00 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <20101124215343.GA65650@ussenterprise.ufp.org>
Message-ID: <C91372EC.189F0%marty@akamai.com>




On 11/24/10 11:53 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:

> In a message written on Wed, Nov 24, 2010 at 01:08:38PM -0800, Owen DeLong
> wrote:
>> Hence my suggestion that 122 would be more palatable if it set aside
>> a separate /10 for that purpose rather than raiding 4.10.
> 
> I would not object to a second /10, but I'm sure I see it as necessary.


It would only amplify the defects in 4.10.

Best,

-M<



From scottleibrand at gmail.com  Wed Nov 24 19:14:26 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 24 Nov 2010 16:14:26 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <C91372EC.189F0%marty@akamai.com>
References: <20101124215343.GA65650@ussenterprise.ufp.org>
	<C91372EC.189F0%marty@akamai.com>
Message-ID: <AANLkTimNEKFCvkEK-g7VnVAERxOS-ejJQ4rLwgstk9i8@mail.gmail.com>

On Wed, Nov 24, 2010 at 3:57 PM, Hannigan, Martin <marty at akamai.com> wrote:
>
> On 11/24/10 11:53 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:
>
>> In a message written on Wed, Nov 24, 2010 at 01:08:38PM -0800, Owen DeLong
>> wrote:
>>> Hence my suggestion that 122 would be more palatable if it set aside
>>> a separate /10 for that purpose rather than raiding 4.10.
>>
>> I would not object to a second /10, but I'm sure I see it as necessary.
>
>
> It would only amplify the defects in 4.10.

So do you see the problem as being that 4.10 will leaving addresses
reserved for too long without putting them into use?

If so, would there be additional criteria for giving out 4.10 reserved
space that would alleviate the defects in 4.10 from your perspective?

-Scott


From BillD at cait.wustl.edu  Wed Nov 24 19:20:30 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 24 Nov 2010 18:20:30 -0600
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
	Development
References: <20101124215343.GA65650@ussenterprise.ufp.org><C91372EC.189F0%marty@akamai.com>
	<AANLkTimNEKFCvkEK-g7VnVAERxOS-ejJQ4rLwgstk9i8@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030879154A1@ex1.cait.wustl.edu>

Leave 4.10 space for what it is now for.
Establish, if need be, an adjunct policy that allows that pool to be raided for other uses if after a period of time 6, 9, 12 months indicates that it is not being effectively utilized.
Crumbs!
bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Scott Leibrand
Sent: Wed 11/24/2010 6:14 PM
To: Hannigan, Martin
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy Development
 
On Wed, Nov 24, 2010 at 3:57 PM, Hannigan, Martin <marty at akamai.com> wrote:
>
> On 11/24/10 11:53 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:
>
>> In a message written on Wed, Nov 24, 2010 at 01:08:38PM -0800, Owen DeLong
>> wrote:
>>> Hence my suggestion that 122 would be more palatable if it set aside
>>> a separate /10 for that purpose rather than raiding 4.10.
>>
>> I would not object to a second /10, but I'm sure I see it as necessary.
>
>
> It would only amplify the defects in 4.10.

So do you see the problem as being that 4.10 will leaving addresses
reserved for too long without putting them into use?

If so, would there be additional criteria for giving out 4.10 reserved
space that would alleviate the defects in 4.10 from your perspective?

-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/20101124/1a8eba14/attachment.htm>

From scottleibrand at gmail.com  Wed Nov 24 19:22:19 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 24 Nov 2010 16:22:19 -0800
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
	Development
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030879154A1@ex1.cait.wustl.edu>
References: <20101124215343.GA65650@ussenterprise.ufp.org>
	<C91372EC.189F0%marty@akamai.com>
	<AANLkTimNEKFCvkEK-g7VnVAERxOS-ejJQ4rLwgstk9i8@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D030879154A1@ex1.cait.wustl.edu>
Message-ID: <AANLkTikJuFLYKexvRHzB9oFRNMbGMGaLv_Wu3gmVVaSW@mail.gmail.com>

What criteria would you use for "not being effectively utilized"?
Less than X% of the space given out Y months after exhaustion?  Less
than Z requests fulfilled under 4.10?

What other uses would be appropriate?  All valid requests?  Limit it
somehow to avoid giving out all of the remaining reserved space at
once to people on the waiting list?

-Scott

On Wed, Nov 24, 2010 at 4:20 PM, Bill Darte <BillD at cait.wustl.edu> wrote:
> Leave 4.10 space for what it is now for.
> Establish, if need be, an adjunct policy that allows that pool to be raided
> for other uses if after a period of time 6, 9, 12 months indicates that it
> is not being effectively utilized.
> Crumbs!
> bd
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of Scott Leibrand
> Sent: Wed 11/24/2010 6:14 PM
> To: Hannigan, Martin
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
> Development
>
> On Wed, Nov 24, 2010 at 3:57 PM, Hannigan, Martin <marty at akamai.com> wrote:
>>
>> On 11/24/10 11:53 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:
>>
>>> In a message written on Wed, Nov 24, 2010 at 01:08:38PM -0800, Owen
>>> DeLong
>>> wrote:
>>>> Hence my suggestion that 122 would be more palatable if it set aside
>>>> a separate /10 for that purpose rather than raiding 4.10.
>>>
>>> I would not object to a second /10, but I'm sure I see it as necessary.
>>
>>
>> It would only amplify the defects in 4.10.
>
> So do you see the problem as being that 4.10 will leaving addresses
> reserved for too long without putting them into use?
>
> If so, would there be additional criteria for giving out 4.10 reserved
> space that would alleviate the defects in 4.10 from your perspective?
>
> -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.
>
>


From BillD at cait.wustl.edu  Thu Nov 25 08:38:48 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 25 Nov 2010 07:38:48 -0600
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
	Development
References: <20101124215343.GA65650@ussenterprise.ufp.org><C91372EC.189F0%marty@akamai.com><AANLkTimNEKFCvkEK-g7VnVAERxOS-ejJQ4rLwgstk9i8@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D030879154A1@ex1.cait.wustl.edu>
	<AANLkTikJuFLYKexvRHzB9oFRNMbGMGaLv_Wu3gmVVaSW@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030879154A3@ex1.cait.wustl.edu>

I don't know...maybe some such...

Perhaps a trendline estimate just before the Fall meeting.  If there is lots of uptake for transitional technologies in that time frame, then wait until the Spring meeting to assess again.....At each inspection period (meeting time?), estimate the amount of space needed against the uptake history out to 2yrs.  Same this amount and release the remainder if any to the pool then....or if it appears that all will be used with transitional technologies, save it. At the end of 2 years, either way, return what's left to the free pool.

Augment the list of non-transitional uses with a maximum allocation size (say /24) that may qualify over that same period of time.

Or, one could authorize an abbreviated 'emergency' allocation process for the list, given AC and BoT agreement and a 'last call' to PPML, addresses could be allocated.

I think it is likely to be obvious whether transitional technologies or IPv6 uptake are the predominant mechanisms going forward by end of calendar year '11.

One can't predict the future, but such a mechanism could provide some flexibility.  I do think that having addresses available for transition rather than same ol', same ol' is best.

bd


-----Original Message-----
From: Scott Leibrand [mailto:scottleibrand at gmail.com]
Sent: Wed 11/24/2010 6:22 PM
To: Bill Darte
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy Development
 
What criteria would you use for "not being effectively utilized"?
Less than X% of the space given out Y months after exhaustion?  Less
than Z requests fulfilled under 4.10?

What other uses would be appropriate?  All valid requests?  Limit it
somehow to avoid giving out all of the remaining reserved space at
once to people on the waiting list?

-Scott

On Wed, Nov 24, 2010 at 4:20 PM, Bill Darte <BillD at cait.wustl.edu> wrote:
> Leave 4.10 space for what it is now for.
> Establish, if need be, an adjunct policy that allows that pool to be raided
> for other uses if after a period of time 6, 9, 12 months indicates that it
> is not being effectively utilized.
> Crumbs!
> bd
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of Scott Leibrand
> Sent: Wed 11/24/2010 6:14 PM
> To: Hannigan, Martin
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool for FuturePolicy
> Development
>
> On Wed, Nov 24, 2010 at 3:57 PM, Hannigan, Martin <marty at akamai.com> wrote:
>>
>> On 11/24/10 11:53 PM, "Leo Bicknell" <bicknell at ufp.org> wrote:
>>
>>> In a message written on Wed, Nov 24, 2010 at 01:08:38PM -0800, Owen
>>> DeLong
>>> wrote:
>>>> Hence my suggestion that 122 would be more palatable if it set aside
>>>> a separate /10 for that purpose rather than raiding 4.10.
>>>
>>> I would not object to a second /10, but I'm sure I see it as necessary.
>>
>>
>> It would only amplify the defects in 4.10.
>
> So do you see the problem as being that 4.10 will leaving addresses
> reserved for too long without putting them into use?
>
> If so, would there be additional criteria for giving out 4.10 reserved
> space that would alleviate the defects in 4.10 from your perspective?
>
> -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/20101125/9fcfa21c/attachment.htm>

From marty at akamai.com  Thu Nov 25 10:14:19 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 25 Nov 2010 10:14:19 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
 Policy Development
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D030879154A3@ex1.cait.wustl.edu>
Message-ID: <C91449EB.18AD3%marty@akamai.com>




On 11/25/10 3:38 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:

> I don't know...maybe some such...
> 
> 


This discussion keeps underscoring the point with respect to 4.10 and
proposal 122. Nobody knows, but they do know that 4.10 does not work.

Best,

-M<



From marty at akamai.com  Thu Nov 25 10:21:28 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Thu, 25 Nov 2010 10:21:28 -0500
Subject: [arin-ppml] Props. 122  + 123 process?
Message-ID: <C9144B98.18AD7%marty@akamai.com>




We've established that at least Prop 123 is a no-brainer and are on the way
to finding support with 122.

Both say "emergency" on them. The next A/C meeting and BoT meerings are some
time off. The smart money believes that the IANA is going to exhaust in
early January which means if we are going to do something we need to do it
now?

What's the process?


Best,

-M<



PS: Happy Thanksgiving, all! I wouldn't normally be posting on such a
fabulous food day except that I'm in bountiful Africa, specifically airy
Johannesburg, at the juicy AfriNIC meeting presenting a fully baked global
proposal. ;)  Enjoy!



From bill at herrin.us  Thu Nov 25 11:27:50 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 25 Nov 2010 11:27:50 -0500
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
In-Reply-To: <AF383344-6363-46DE-921F-5C2734C65C4C@delong.com>
References: <20101123153414.GA14916@ussenterprise.ufp.org>
	<C9129319.1882C%marty@akamai.com>
	<20101124143751.GA6701@ussenterprise.ufp.org>
	<AF383344-6363-46DE-921F-5C2734C65C4C@delong.com>
Message-ID: <AANLkTink-ZmaPi4you8mT3Q9AS3X1Yp6WrieYzz4yBMh@mail.gmail.com>

On Wed, Nov 24, 2010 at 4:08 PM, Owen DeLong <owen at delong.com> wrote:
>> To put it simply, we have set aside a "Dedicated IPv4 block to
>> facilitate IPv6 Deployment", and I am arguing that we may need a
>> "Dedicated IPv4 block to keep the IPv4 internet from falling apart".
>> I can't be sure though, and I can't be sure we can't do both.
>> Reserve it all, find out what goes wrong and where the need is
>> greatest, and then pass a policy quickly to address it. ?1-3 months
>> of no space followed by relief where it is needed most is far more
>> useful than the chance blowing the space on something other than
>> the greatest need.
>
> We know we will need a dedicated IPv4 block to facilitate IPv6
> deployment.

We do? For what? NAT64? It's looking less likely by the day, or at
least less likely that it will be used prior to waning IPv4 when v6 is
ubiquitous enough for ISPs to safely start to dismantle their IPv4
infrastructure (and thus by definition have plenty of IPv4 addresses
available).


> We may need a dedicated IPv4 block to keep the IPv4 internet from
> falling apart

Yes, that could actually be valuable. Facilitating tech like v4 carrier NAT.

-Bill


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


From bill at herrin.us  Thu Nov 25 12:24:40 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 25 Nov 2010 12:24:40 -0500
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
 Policy - revised
In-Reply-To: <AANLkTikAkGDd4rNBoni6-Z=rLTgYgmW720RAOzqtd4rt@mail.gmail.com>
References: <4CC83D28.90100@arin.net>
	<AANLkTikAkGDd4rNBoni6-Z=rLTgYgmW720RAOzqtd4rt@mail.gmail.com>
Message-ID: <AANLkTikSyELuJv9jkA1MNw3mchaVhtfKYEaQzdbVPunk@mail.gmail.com>

On Wed, Nov 24, 2010 at 5:22 AM, cja at daydream.com <packetgrrl at gmail.com> wrote:
> How do folks feel about how transfers between regions would affect the
> routing table? ? We would be in essence punching holes in RIR blocks. ? This
> depends entirely on whether there are ISPs filtering or aggregating on
> regional boundaries based on RIR /8 block allocations.

Hi Cathy,

There's a low but non-zero probability of harm to future routing
operations from allowing inter-region transfers.

At the network edge, it's possible to do a few tricks with routing
that reduce your table by tying most outregion routes to a few
unfiltered ones. However, these tricks are not an especially large
improvement over accepting a default and simply filtering the distant
routes.

BGP RIB compression has been all but demonstrated impossible for
transit ASes (as opposed to origin-only ASes), so there's no
anticipated impact there. You just can't aggregate that way no matter
how distant; the more specific prefix rule means your downstream will
send traffic to his other ISPs if you in any way aggregate, damaging
the product you supply.

There is a RIB parallelism scheme in which address blocks transfered
out-region might experience inefficient routing. The idea is that you
only keep the full APNIC-region RIBs in your APNIC-region routers.
Your ARIN region routers hold the full ARIN region RIB but they only
hold the APNIC /8's, expecting to encapsulate packets for those
destinations in MPLS and send them to the APNIC-region routers for
further processing.  Routing for the few prefixes transferred from
APNIC to ARIN might then suffer multiple ocean crossings.

The RIB parallelism scheme only exists on a drawing board; I know of
no examples where it's in production and it would probably require
modifications to MPLS implementations which allow routers to associate
tags with particular exits instead of just particular routers.
However, inter-region transfers could complicate or even foreclose its
future use.

FIB compression could be impacted by reducing the likelihood that
nearby prefixes all point out the same interface. The idea with FIB
compression is that you figure out which exit is the destination for
most of your routes, set a default pointing at that exit, and then
keep only the FIB entries that direct packets somewhere else. Do this
recursively and you can get the today's FIB down to between half and a
quarter of the size of the RIB at a cost of losing the implicit
authoritative set of null routes.

However it's not at all clear that the way multinational backbone
networks connect hasn't already made whatever impact will be made to
FIB compression. There's an Internet Draft somewhere close to becoming
an RFC on FIB compression but I'm not aware of its use anywhere in
deployed software.

So all told, there's a low but non-zero probability of harm to future
routing operations from allowing inter-region transfers.

Regards,
Bill Herrin


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


From BillD at cait.wustl.edu  Thu Nov 25 19:47:44 2010
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 25 Nov 2010 18:47:44 -0600
Subject: [arin-ppml] Policy Proposal 122: Reserved Pool for Future
	Policy Development
References: <C91449EB.18AD3%marty@akamai.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D030879154A4@ex1.cait.wustl.edu>

The continuing discussion underscores that no one knows whether 4.10 will be a valuable set aside or not.
Time will tell whether those crumbs were well allocated by the community or need be reallocated to something else.
In the absence of any real knowledge of what will happen, all roads seem as dubious.

bd


-----Original Message-----
From: Hannigan, Martin [mailto:marty at akamai.com]
Sent: Thu 11/25/2010 9:14 AM
To: Bill Darte; Scott Leibrand
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal 122: Reserved Pool for Future Policy Development
 



On 11/25/10 3:38 PM, "Bill Darte" <BillD at cait.wustl.edu> wrote:

> I don't know...maybe some such...
> 
> 


This discussion keeps underscoring the point with respect to 4.10 and
proposal 122. Nobody knows, but they do know that 4.10 does not work.

Best,

-M<


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

From scottleibrand at gmail.com  Fri Nov 26 14:39:21 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 26 Nov 2010 11:39:21 -0800
Subject: [arin-ppml] Implementation of 2010-1
Message-ID: <AANLkTinJeSfaT34EuoxdTbOmXmNRtdeCkmNyVSAO1Wba@mail.gmail.com>

John,

Do you have any updates on when ARIN expects to implement Draft Policy 2010-1
Waiting List for Unmet IPv4 Requests?  According to
https://www.arin.net/policy/proposals/2010_1.html, the Board adopted
it on 10 August 2010, and its status is "Adopted - Implementation to
be determined".

I believe it is important that we implement this policy well in
advance of IANA exhaustion and update the NRPM accordingly to ensure
everyone is aware of how addresses will be given out as we approach
exhaustion of the ARIN IPv4 free pool.

Thanks,
Scott


From scottleibrand at gmail.com  Fri Nov 26 15:01:01 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 26 Nov 2010 12:01:01 -0800
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <C9144B98.18AD7%marty@akamai.com>
References: <AcuMtG4jzs8DFDAECEWUn1GDCdIDSA==>
	<C9144B98.18AD7%marty@akamai.com>
Message-ID: <AANLkTikPrv+dEydjf+WTREUHCVOFoEeJD-3SCovPoeTC@mail.gmail.com>

(Speaking solely for myself.)

Marty,

My understanding is that the AC can make a recommendation to the Board
at any time (via a regularly scheduled or specially called meeting)
that, for example, we believe a certain issue requires emergency
policy action, and that we believe they should initiate the Emergency
PDP.  With or without such a recommendation, the Board can decide (at
a regularly scheduled or specially called meeting) to invoke the
Emergency PDP, which is detailed in section 7.1 of
https://www.arin.net/policy/pdp.html, and triggers a 2-week PPML
discussion and up to 1 week of AC review before a final decision by
the Board.

I'm still not sure I understand the need for emergency policy action
here, though.  Can you explain in a little bit more detail what
irreparable harm you foresee if we don't take action before the April
public policy meeting?

As I see it, we can expect to hit IANA exhaustion sometime in the
first quarter of 2011, perhaps in January.  At that point, the last
/8s will be distributed, and a /10 will be reserved per 4.10.  ARIN
will continue making allocations normally until the ARIN free pool
shrinks to the point where a particular large request cannot be met.
At that point, 2010-1 will kick in, and the requester will have the
option of specifying a smaller block, or going on the waiting list
(and presumably looking for a block of the appropriate size on the
transfer market).  All organizations will also be limited to receiving
one allocation, assignment, or transfer every 3 months.

As a result, I expect that there will be some time between IANA
exhaustion and the point at which ARIN is no longer able to fill
requests for /24s, and that this most likely will not occur until
after our April meeting.  However, even if the general free pool is
exhausted of /24s by then, we'll still have the 4.10 reserved /10
available, so we could modify proposal 123 slightly to carve out a /16
of that for critical infrastructure.  (That would be 1.6% of the /10.)

I'm even less clear on why 122 should be considered an emergency.  In
its current form, it simply prevents any allocations out of 4.10's
reserved /10 for several months.  Since there is a /24 maximum
allocation size under 4.10, such allocations will only start to be
needed once ARIN is unable to meet /24 requests out of the general
pool.  And since requesters of space under 4.10 can only get one block
every 6 months, I don't expect much of the reserved /10 to be used up
before our April meeting.

So, unless you can point out a substantial risk of irreparable harm
resulting from inaction between now and April, I don't see any need
for emergency policy action on these proposals, and would instead
suggest we run 123, and any suggestions people have for improving
4.10, though the normal policy process.

-Scott

P.S.  Hope you all enjoyed Thanksgiving at AfriNIC!

On Thu, Nov 25, 2010 at 7:21 AM, Hannigan, Martin <marty at akamai.com> wrote:
>
>
>
> We've established that at least Prop 123 is a no-brainer and are on the way
> to finding support with 122.
>
> Both say "emergency" on them. The next A/C meeting and BoT meerings are some
> time off. The smart money believes that the IANA is going to exhaust in
> early January which means if we are going to do something we need to do it
> now?
>
> What's the process?
>
>
> Best,
>
> -M<
>
>
>
> PS: Happy Thanksgiving, all! I wouldn't normally be posting on such a
> fabulous food day except that I'm in bountiful Africa, specifically airy
> Johannesburg, at the juicy AfriNIC meeting presenting a fully baked global
> proposal. ;) ?Enjoy!
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From ppml at rs.seastrom.com  Sun Nov 28 09:11:35 2010
From: ppml at rs.seastrom.com (Robert E. Seastrom)
Date: Sun, 28 Nov 2010 09:11:35 -0500
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy - revised
In-Reply-To: <AANLkTikAkGDd4rNBoni6-Z=rLTgYgmW720RAOzqtd4rt@mail.gmail.com>
	(packetgrrl@gmail.com's message of "Wed,
	24 Nov 2010 03:22:51 -0700")
References: <4CC83D28.90100@arin.net>
	<AANLkTikAkGDd4rNBoni6-Z=rLTgYgmW720RAOzqtd4rt@mail.gmail.com>
Message-ID: <86sjylv8q0.fsf@seastrom.com>


"cja at daydream.com" <packetgrrl at gmail.com> writes:

> How do folks feel about how transfers between regions would affect
> the routing table? ? We would be in essence punching holes in RIR
> blocks. ? This depends entirely on whether there are ISPs filtering
> or aggregating on regional boundaries based on RIR /8 block
> allocations. ?

I don't see much effect on the routing table for reasons others have
already mentioned.  I do see an increase in work for those who use IP
address country of registration as part of a reputation scheme (for
instance, spam filtering, credit card fraud avoidance, etc).
Commentary about the effectiveness of such schemes should be
cheerfully ignored; the point is that some organizations want to use
them and it makes a certain amount of sense to require (for instance)
that one do a handshake with one's credit card provider before it is
possible to use one's card outside of his or her home country.

Anyway, so long as these transfers are documented in a near-realtime
machine-parseable format, this shouldn't be too painful.

-r




From owen at delong.com  Sun Nov 28 09:28:56 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 28 Nov 2010 06:28:56 -0800
Subject: [arin-ppml] Policy Proposal 119: Globally Coordinated Transfer
	Policy - revised
In-Reply-To: <86sjylv8q0.fsf@seastrom.com>
References: <4CC83D28.90100@arin.net>
	<AANLkTikAkGDd4rNBoni6-Z=rLTgYgmW720RAOzqtd4rt@mail.gmail.com>
	<86sjylv8q0.fsf@seastrom.com>
Message-ID: <45114E01-063F-4F51-9E6F-8E829AAA273F@delong.com>


On Nov 28, 2010, at 6:11 AM, Robert E. Seastrom wrote:

> 
> "cja at daydream.com" <packetgrrl at gmail.com> writes:
> 
>> How do folks feel about how transfers between regions would affect
>> the routing table?   We would be in essence punching holes in RIR
>> blocks.   This depends entirely on whether there are ISPs filtering
>> or aggregating on regional boundaries based on RIR /8 block
>> allocations.  
> 
> I don't see much effect on the routing table for reasons others have
> already mentioned.  I do see an increase in work for those who use IP
> address country of registration as part of a reputation scheme (for
> instance, spam filtering, credit card fraud avoidance, etc).
> Commentary about the effectiveness of such schemes should be
> cheerfully ignored; the point is that some organizations want to use
> them and it makes a certain amount of sense to require (for instance)
> that one do a handshake with one's credit card provider before it is
> possible to use one's card outside of his or her home country.
> 
Reasonable or not, effective or not, they are hardly, in my opinion,
a blocking consideration for policy. I believe it is up to the banking
industry to adapt to IP policy.

Admittedly, having been on the receiving end of such a (misguided)
idea of security (unrelated to credit card, i was attempting to verify
the posting of a mortgage payment) while I was in Rwanda, I can
honestly say that the current problem with such schemes is that
they appear to work well enough.

If anything, this policy will benefit the internet by making it even
more obvious that topology!=geography and addresses are
not subject  to export controls, immigration, or customs
clearance.

Indeed, integers have virtually no travel restrictions regardless
of any policies we put in place.

Owen



From marty at akamai.com  Mon Nov 29 10:15:15 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Mon, 29 Nov 2010 10:15:15 -0500
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <AANLkTikPrv+dEydjf+WTREUHCVOFoEeJD-3SCovPoeTC@mail.gmail.com>
Message-ID: <C9192DB3.18D8F%marty@akamai.com>




On 11/26/10 3:01 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:

[ snip ]



> 
> As a result, I expect that there will be some time between IANA
> exhaustion and the point at which ARIN is no longer able to fill
> requests for /24s, and that this most likely will not occur until
> after our April meeting.  However, even if the general free pool is
> exhausted of /24s by then, we'll still have the 4.10 reserved /10
> available, so we could modify proposal 123 slightly to carve out a /16
> of that for critical infrastructure.  (That would be 1.6% of the /10.)

The proposal says exactly what it means and nowhere does it indicate that
anything should be withdrawn from 4.10. In fact, it's unclear if 4.10 is
properly sized to begin with.

> I'm even less clear on why 122 should be considered an emergency.  In
> its current form, it simply prevents any allocations out of 4.10's
> reserved /10 for several months.  Since there is a /24 maximum
> allocation size under 4.10, such allocations will only start to be
> needed once ARIN is unable to meet /24 requests out of the general
> pool.  And since requesters of space under 4.10 can only get one block
> every 6 months, I don't expect much of the reserved /10 to be used up
> before our April meeting.
> 
> So, unless you can point out a substantial risk of irreparable harm
> resulting from inaction between now and April, I don't see any need
> for emergency policy action on these proposals, and would instead
> suggest we run 123, and any suggestions people have for improving
> 4.10, though the normal policy process.
> 


Scott, the commentary regarding any sort of exigent request are in the
rationale, not the policy. I think deciding what is and isn't an emergency
is up to the AC. One would have thought that most of this would have been
done already though and not having at least the CI portion of this thought
out prior to exhaustion merely "looks" bad.


Best,

-M<



From scottleibrand at gmail.com  Mon Nov 29 14:24:12 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 29 Nov 2010 11:24:12 -0800
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <C9192DB3.18D8F%marty@akamai.com>
References: <AANLkTikPrv+dEydjf+WTREUHCVOFoEeJD-3SCovPoeTC@mail.gmail.com>
	<C9192DB3.18D8F%marty@akamai.com>
Message-ID: <AANLkTinjLUmST-o59FXvMTUfnspiGYuqWgbncj2_2jS-@mail.gmail.com>

(Taking this part out of order...)

On Mon, Nov 29, 2010 at 7:15 AM, Hannigan, Martin <marty at akamai.com> wrote:

> I think deciding what is and isn't an emergency is up to the AC.

Agreed.  And to help us decide in this case, I'd love to hear from the
community whether anyone thinks 122 and/or 123 address an emergency
need, and if so, why you think emergency action is needed.

Further comments inline...

> On 11/26/10 3:01 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:
> [ snip ]
>> As a result, I expect that there will be some time between IANA
>> exhaustion and the point at which ARIN is no longer able to fill
>> requests for /24s, and that this most likely will not occur until
>> after our April meeting. ?However, even if the general free pool is
>> exhausted of /24s by then, we'll still have the 4.10 reserved /10
>> available, so we could modify proposal 123 slightly to carve out a /16
>> of that for critical infrastructure. ?(That would be 1.6% of the /10.)
>
> The proposal says exactly what it means and nowhere does it indicate that
> anything should be withdrawn from 4.10.

Agreed.  That was my suggestion, as part of my explanation of why I
don't think 123 warrants use of the emergency PDP.

> In fact, it's unclear if 4.10 is properly sized to begin with.

Do you believe that 4.10 is too big or too small?  If it's too big, we
can reduce the size of the reservation at our next meeting, and in any
event we're in the same position with 122 as without it.  If it's too
small, then we'd need to reserve more space before ARIN exhaustion,
which 122 doesn't do.  I don't see how 122 helps either way.

>> I'm even less clear on why 122 should be considered an emergency. ?In
>> its current form, it simply prevents any allocations out of 4.10's
>> reserved /10 for several months. ?Since there is a /24 maximum
>> allocation size under 4.10, such allocations will only start to be
>> needed once ARIN is unable to meet /24 requests out of the general
>> pool. ?And since requesters of space under 4.10 can only get one block
>> every 6 months, I don't expect much of the reserved /10 to be used up
>> before our April meeting.
>>
>> So, unless you can point out a substantial risk of irreparable harm
>> resulting from inaction between now and April, I don't see any need
>> for emergency policy action on these proposals, and would instead
>> suggest we run 123, and any suggestions people have for improving
>> 4.10, though the normal policy process.

> Scott, the commentary regarding any sort of exigent request are in the
> rationale, not the policy.

I saw that.  For 122, it says that "This will provide for time to
review our current depletion strategy and improve upon it to the
benefit of the entire community."  What I don't understand is why it
would help to suspend 4.10.  We can still review 4.10 and work to
improve upon it between now and April, whether or not we allow 4.10 to
be implemented as written.

> One would have thought that most of this would have been
> done already though and not having at least the CI portion of this thought
> out prior to exhaustion merely "looks" bad.

My own personal opinion is that CI is adequately served by existing
policy.  Up until ARIN's free pool is exhausted at the /24 level, CI
needs (and any other justified need) can be met for free.  After that,
the sponsoring organization (or any interested party) can provide
space out of their existing inventory, or can acquire it via transfer,
just as any other IPv4 user would do.  If there isn't sufficient
economic justification to acquire space for a particular CI need, then
IMO it's not really "critical", and doesn't deserve free space out of
a special pool.

I'm not necessarily opposed to 123, although at this point I remain
unconvinced that it warrants emergency policy action, as opposed to
discussion in April.

Thanks,
Scott


From gary.buhrmaster at gmail.com  Mon Nov 29 15:01:35 2010
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Mon, 29 Nov 2010 20:01:35 +0000
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <AANLkTinjLUmST-o59FXvMTUfnspiGYuqWgbncj2_2jS-@mail.gmail.com>
References: <AANLkTikPrv+dEydjf+WTREUHCVOFoEeJD-3SCovPoeTC@mail.gmail.com>
	<C9192DB3.18D8F%marty@akamai.com>
	<AANLkTinjLUmST-o59FXvMTUfnspiGYuqWgbncj2_2jS-@mail.gmail.com>
Message-ID: <AANLkTi=3_sT+LyNU-gGRFdtXqjMVRgQqPnBS_qSYtdaJ@mail.gmail.com>

On Mon, Nov 29, 2010 at 19:24, Scott Leibrand <scottleibrand at gmail.com> wrote:
...
> Agreed. ?And to help us decide in this case, I'd love to hear from the
> community whether anyone thinks 122 and/or 123 address an emergency
> need, and if so, why you think emergency action is needed.

Emergency?  No.

That is not to claim that there cannot possibly be some
future action or event that could cause an emergency,
just that I do not see one now.  I trust the AC would know
an emergency when they see one, and take appropriate
steps.

Gary


From frnkblk at iname.com  Tue Nov 30 01:27:56 2010
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Tue, 30 Nov 2010 00:27:56 -0600
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <C9192DB3.18D8F%marty@akamai.com>
References: <AANLkTikPrv+dEydjf+WTREUHCVOFoEeJD-3SCovPoeTC@mail.gmail.com>
	<C9192DB3.18D8F%marty@akamai.com>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAA4AQeP7+CTIK9HeYuTMddAQAAAAA=@iname.com>

I'll be the first one to admit that I may be missing the boat on the
Proposal 4.10/122/123 threads, but it seems to me that we ought to:
a) keep the /10 from 4.10 for IPv6 *transitional* technologies (i.e. DSLite,
CGN, NAT64, etc).
b) establish via emergency procedures a separate /16 (I would fully support
a /10) for CI as described in Proposal 123
c) establish same (or separate) regular and repeated policy review timers
for each of the two pools, beginning after a certain point (i.e. when 2010-1
kicks in, and then review again every 9 months thereafter)
d) with non-autorenew timers, such that if the ARIN community cannot
re-confirm consensus at renewal time, that unallocated space in those pools
is returned to the free pool

Rationale:
a) having these plans in place *before* ARIN's last /8 is assigned
demonstrates to the broader public that the networking community has a plan
in place, which will help maintain "customer confidence" and reduce IPv4
netblock speculation.  If we do it afterward there *will* be the perception
that we were reactionary and don't have what it takes to plan accordingly.
Let's show some leadership here.  Better to attempt to do something right
than do nothing at all.
b) the sizes of these two pools are small enough in the grand scheme of
things that it is better to be safe than sorry.
c) having two pools rather than one will prevent a run-out of all remaining
addresses for just one of the two purposes, something that might occur if
there was just one pool.
d) we can always return unallocated space to the free pool via a new
proposal or not acting on a review timer -- no real harm done.
   1) having a regular review process avoids the Class E issue that was
mentioned before
   2) if the policy for that /10 is working well it can be quickly reviewed
and renewed for an additional time period
   3) if the policy is not working well it can be changed through the
regular policy process, or at renewal time
   4) if we can't agree at renewal time we're under some time pressure to
resolve the issue at the risk of letting the addresses return to the free
pool.
   5) if we don't care about one or both of pools, they'll naturally lapse
into the free pool
   6) if we run out on one (successful!) we still have an opportunity to
write up a policy to draw on the other /10
e) creating a pool for CI may keep the governments represented by ARIN
members from attempting to intervene in a last-minute kind of way to "save
space" for national security reasons

We've agreed that we don't know which IPv6 transition approach(es) will be
the winner(s), and I think most of us agree that we need some space for CI
in situations where even our best planning didn't anticipate a certain need.

Regards,

Frank

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Hannigan, Martin
Sent: Monday, November 29, 2010 9:15 AM
To: Scott Leibrand
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Props. 122 + 123 process?

On 11/26/10 3:01 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:

[ snip ]

> 
> As a result, I expect that there will be some time between IANA
> exhaustion and the point at which ARIN is no longer able to fill
> requests for /24s, and that this most likely will not occur until
> after our April meeting.  However, even if the general free pool is
> exhausted of /24s by then, we'll still have the 4.10 reserved /10
> available, so we could modify proposal 123 slightly to carve out a /16
> of that for critical infrastructure.  (That would be 1.6% of the /10.)

The proposal says exactly what it means and nowhere does it indicate that
anything should be withdrawn from 4.10. In fact, it's unclear if 4.10 is
properly sized to begin with.

> I'm even less clear on why 122 should be considered an emergency.  In
> its current form, it simply prevents any allocations out of 4.10's
> reserved /10 for several months.  Since there is a /24 maximum
> allocation size under 4.10, such allocations will only start to be
> needed once ARIN is unable to meet /24 requests out of the general
> pool.  And since requesters of space under 4.10 can only get one block
> every 6 months, I don't expect much of the reserved /10 to be used up
> before our April meeting.
> 
> So, unless you can point out a substantial risk of irreparable harm
> resulting from inaction between now and April, I don't see any need
> for emergency policy action on these proposals, and would instead
> suggest we run 123, and any suggestions people have for improving
> 4.10, though the normal policy process.
> 


Scott, the commentary regarding any sort of exigent request are in the
rationale, not the policy. I think deciding what is and isn't an emergency
is up to the AC. One would have thought that most of this would have been
done already though and not having at least the CI portion of this thought
out prior to exhaustion merely "looks" bad.


Best,

-M<

_______________________________________________
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 marty at akamai.com  Tue Nov 30 07:49:16 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 30 Nov 2010 07:49:16 -0500
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <AANLkTinjLUmST-o59FXvMTUfnspiGYuqWgbncj2_2jS-@mail.gmail.com>
Message-ID: <C91A5CFC.1900D%marty@akamai.com>




On 11/29/10 2:24 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:



[ snip ]

> 
>> In fact, it's unclear if 4.10 is properly sized to begin with.
> 
> Do you believe that 4.10 is too big or too small?


How did the AC arrive at a /10 as being an acceptable size?

Best,

-M<



From john.sweeting at twcable.com  Tue Nov 30 08:53:55 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 30 Nov 2010 08:53:55 -0500
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <C91A5CFC.1900D%marty@akamai.com>
References: <AANLkTinjLUmST-o59FXvMTUfnspiGYuqWgbncj2_2jS-@mail.gmail.com>,
	<C91A5CFC.1900D%marty@akamai.com>
Message-ID: <DCC302FAA9FE5F4BBA4DCAD46569377914023E8E28@PRVPEXVS03.corp.twcable.com>

Marty, if you go back and read the transcripts from the fall 2008 meeting in LA it is explained by the author Alain Durand in his presentation. The poll at the time supported this proposal 129 in room, 55 in favor, 0 against. Thanks.


________________________________________
From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Hannigan, Martin [marty at akamai.com]
Sent: Tuesday, November 30, 2010 7:49 AM
To: Scott Leibrand
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Props. 122 + 123 process?

On 11/29/10 2:24 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:



[ snip ]

>
>> In fact, it's unclear if 4.10 is properly sized to begin with.
>
> Do you believe that 4.10 is too big or too small?


How did the AC arrive at a /10 as being an acceptable size?

Best,

-M<

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

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 owen at delong.com  Tue Nov 30 10:01:08 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Nov 2010 07:01:08 -0800
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <C91A5CFC.1900D%marty@akamai.com>
References: <C91A5CFC.1900D%marty@akamai.com>
Message-ID: <CB147E20-4F26-4304-BAEC-E6378F3E1A32@delong.com>


On Nov 30, 2010, at 4:49 AM, Hannigan, Martin wrote:

> 
> 
> 
> On 11/29/10 2:24 PM, "Scott Leibrand" <scottleibrand at gmail.com> wrote:
> 
> 
> 
> [ snip ]
> 
>> 
>>> In fact, it's unclear if 4.10 is properly sized to begin with.
>> 
>> Do you believe that 4.10 is too big or too small?
> 
> 
> How did the AC arrive at a /10 as being an acceptable size?
> 
> Best,
> 
> -
There was much discussion on list and at the public policy meeting.
IIRC, there was even a show of hands ranging from /8 to /11 and
the majority of support went to /10.

Owen




From marty at akamai.com  Tue Nov 30 10:44:30 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 30 Nov 2010 10:44:30 -0500
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD46569377914023E8E28@PRVPEXVS03.corp.twcable.com>
Message-ID: <C91A860E.1905B%marty@akamai.com>



On 11/30/10 8:53 AM, "Sweeting, John" <john.sweeting at twcable.com> wrote:

> Marty, if you go back and read the transcripts from the fall 2008 meeting in
> LA it is explained by the author Alain Durand in his presentation. The poll at
> the time supported this proposal 129 in room, 55 in favor, 0 against. Thanks.
> 
> 

It's too bad that 2010-10 Global Policy for IPv4 Allocations by the IANA
Post Exhaustion which was 40:5 didn't have such an easy go of it, but I
don't think that this thread is a debate about how to judge consensus so
let's move on. 

That thread you quote isn't relevant, IMHO. It's already been established in
the previous public policy meeting and following that the policy is flawed
and we have multiple parties here agreeing. I think that defending 4.10 is a
waste of all of our time at this stage.

The relevant thread with respect as to why to deal with 4.10 at all is:

    [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)


That demonstrates the weaknesses with respect to 4.10 in more detail and
includes suggestions to make improvements.

When you analyze the spread of who benefits from 4.10 it's legacy holders.
4.10 pretty much insures that smaller entities are less-likely to be
required to acquire address space on the open market and that legacy holders
are going to have addresses available for medium and larger networks to
purchase/fund through the STLS.

V4 is done, no arguments here. I'm not a legacy holder and my agenda is
mostly cost. If we're going to have policy related to transition it should
have some support other than "there's nothing better proposed" or we ought
to get rid of it. A fix would be better which is why 122 is out there.

Best,

-M<



From john.sweeting at twcable.com  Tue Nov 30 10:46:13 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 30 Nov 2010 10:46:13 -0500
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <C91A860E.1905B%marty@akamai.com>
References: <DCC302FAA9FE5F4BBA4DCAD46569377914023E8E28@PRVPEXVS03.corp.twcable.com>,
	<C91A860E.1905B%marty@akamai.com>
Message-ID: <DCC302FAA9FE5F4BBA4DCAD46569377914023E8E35@PRVPEXVS03.corp.twcable.com>

No debate at all, I was curious about your question "how did the AC come to a /10?" and since I was not on the AC at the time I went into the transcripts to find out. I was simply answering your question, not making any specific point at all.


+++++
________________________________________
From: Hannigan, Martin [marty at akamai.com]
Sent: Tuesday, November 30, 2010 10:44 AM
To: Sweeting, John; Scott Leibrand
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Props. 122 + 123 process?

On 11/30/10 8:53 AM, "Sweeting, John" <john.sweeting at twcable.com> wrote:

> Marty, if you go back and read the transcripts from the fall 2008 meeting in
> LA it is explained by the author Alain Durand in his presentation. The poll at
> the time supported this proposal 129 in room, 55 in favor, 0 against. Thanks.
>
>

It's too bad that 2010-10 Global Policy for IPv4 Allocations by the IANA
Post Exhaustion which was 40:5 didn't have such an easy go of it, but I
don't think that this thread is a debate about how to judge consensus so
let's move on.

That thread you quote isn't relevant, IMHO. It's already been established in
the previous public policy meeting and following that the policy is flawed
and we have multiple parties here agreeing. I think that defending 4.10 is a
waste of all of our time at this stage.

The relevant thread with respect as to why to deal with 4.10 at all is:

    [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)


That demonstrates the weaknesses with respect to 4.10 in more detail and
includes suggestions to make improvements.

When you analyze the spread of who benefits from 4.10 it's legacy holders.
4.10 pretty much insures that smaller entities are less-likely to be
required to acquire address space on the open market and that legacy holders
are going to have addresses available for medium and larger networks to
purchase/fund through the STLS.

V4 is done, no arguments here. I'm not a legacy holder and my agenda is
mostly cost. If we're going to have policy related to transition it should
have some support other than "there's nothing better proposed" or we ought
to get rid of it. A fix would be better which is why 122 is out there.

Best,

-M<


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 owen at delong.com  Tue Nov 30 11:21:52 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Nov 2010 08:21:52 -0800
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD46569377914023E8E35@PRVPEXVS03.corp.twcable.com>
References: <DCC302FAA9FE5F4BBA4DCAD46569377914023E8E28@PRVPEXVS03.corp.twcable.com>,
	<C91A860E.1905B%marty@akamai.com>
	<DCC302FAA9FE5F4BBA4DCAD46569377914023E8E35@PRVPEXVS03.corp.twcable.com>
Message-ID: <0A290937-C4C5-45C4-A00B-92B334C4C491@delong.com>


On Nov 30, 2010, at 7:46 AM, Sweeting, John wrote:

> No debate at all, I was curious about your question "how did the AC come to a /10?" and since I was not on the AC at the time I went into the transcripts to find out. I was simply answering your question, not making any specific point at all.
> 
> 
> +++++
> ________________________________________
> From: Hannigan, Martin [marty at akamai.com]
> Sent: Tuesday, November 30, 2010 10:44 AM
> To: Sweeting, John; Scott Leibrand
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Props. 122 + 123 process?
> 
> On 11/30/10 8:53 AM, "Sweeting, John" <john.sweeting at twcable.com> wrote:
> 
>> Marty, if you go back and read the transcripts from the fall 2008 meeting in
>> LA it is explained by the author Alain Durand in his presentation. The poll at
>> the time supported this proposal 129 in room, 55 in favor, 0 against. Thanks.
>> 
>> 
> 
> It's too bad that 2010-10 Global Policy for IPv4 Allocations by the IANA
> Post Exhaustion which was 40:5 didn't have such an easy go of it, but I
> don't think that this thread is a debate about how to judge consensus so
> let's move on.
> 
Huh? The AC recommended adoption of 2010-10 after last call, so, I'm not
sure what you mean by your statement.

> That thread you quote isn't relevant, IMHO. It's already been established in
> the previous public policy meeting and following that the policy is flawed
> and we have multiple parties here agreeing. I think that defending 4.10 is a
> waste of all of our time at this stage.
> 
I don't agree with your conclusion here.

> The relevant thread with respect as to why to deal with 4.10 at all is:
> 
>    [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
> 
> 
> That demonstrates the weaknesses with respect to 4.10 in more detail and
> includes suggestions to make improvements.
> 
This proposal received overwhelming opposition. There was nothing in the 2010-13
debate that leads me to believe that 122 is in any way a good idea. If anything, I
think the 2010-13 debate leads me to the conclusion that trying to build hybrid
ponies was a bad idea and I should have stuck to the original clarification of
4.10 that was intended in the version of 2010-13 that was abandoned by the AC
just prior to the petition.

> When you analyze the spread of who benefits from 4.10 it's legacy holders.
> 4.10 pretty much insures that smaller entities are less-likely to be
> required to acquire address space on the open market and that legacy holders
> are going to have addresses available for medium and larger networks to
> purchase/fund through the STLS.
> 
I think you mean through NRPM 8.3. STLS is just one possible interface to NRPM 8.3.

However, I believe that the primary beneficiaries of 4.10 are:

	1.	Eyeball ISPs that need additional resources for high-ratio conversion
		or transition oriented technologies.

	2.	New ISPs that start up after IPv4 runout and need a small amount of IPv4
		space to make their IPv6 implementation feasible while others still have
		not completed the transition.

> V4 is done, no arguments here. I'm not a legacy holder and my agenda is
> mostly cost. If we're going to have policy related to transition it should
> have some support other than "there's nothing better proposed" or we ought
> to get rid of it. A fix would be better which is why 122 is out there.
> 
While I do hold resources covered under LRSA, I don't see how 4.10 will
in any way benefit me or any other legacy holder.

Owen



From farmer at umn.edu  Tue Nov 30 14:09:30 2010
From: farmer at umn.edu (David Farmer)
Date: Tue, 30 Nov 2010 13:09:30 -0600
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <C91A860E.1905B%marty@akamai.com>
References: <C91A860E.1905B%marty@akamai.com>
Message-ID: <4CF54BEA.6070107@umn.edu>

On 11/30/10 09:44 CST, Hannigan, Martin wrote:
...
> That thread you quote isn't relevant, IMHO. It's already been established in
> the previous public policy meeting and following that the policy is flawed
> and we have multiple parties here agreeing.

I agreed earlier and still agree there there is a strong consensus that 
4.10 should be changed.  However, a consensus that something should be 
change does not equate to a consensus for what that the change should 
be.  What we need to be doing is developing a consensus for what that 
change should be.

> I think that defending 4.10 is a waste of all of our time at this stage.

You seem to be making the leap that a consensus that 4.10 should be 
changed equates to a lack of any support for 4.10 at all.  I believe 
that to be incorrect.

> The relevant thread with respect as to why to deal with 4.10 at all is:
>
>      [arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)
>
>
> That demonstrates the weaknesses with respect to 4.10 in more detail and
> includes suggestions to make improvements.

I assume you mean the rational from that revision of the Draft Policy, 
is that correct?

 From http://lists.arin.net/pipermail/arin-ppml/2010-September/018174.html
-----
> Rationale:
>
> The current terminology in section 4.10 is vague and could allow a variety of interpretations which could lead to allocations or assignments being made to ISPs intending to misuse the space for general deployment by using IPv6 overlay technologies as a "IPv6 deployments" requiring IPv4 space for transition. For example, the current policy could be interpreted to enable an ISP to require IPv4 addresses for all IPv6 customers to roll IPv6 out as 6rd to customers who would be otherwise unable to get IPv4 space. This is clearly outside of the original intent of the proposal which created 4.10 (6rd was not yet envisioned at the time that was written). This proposal seeks to clarify that intent and tighten up the requirements for organizations seeking to get space from this limited final resource so that it truly is available to facilitate transitional technologies.

Yes and this is why I believe there is a consensus to make a change, but 
I believe this can be accomplished with a much simpler change and 
without fundamentally changing 4.10 intent.

> Additionally, there are a number of community segments that are not well served by the original intent of 4.10 and several community members requested a mechanism for providing a certain amount of certainty with regards to obtaining space at the end. While it would be impossible to guarantee organizations all the space they need as runout is upon us, this policy seeks to provide a way for organizations to sign up for and receive a reservation from the final space proportionate to their need. The policy also includes guidelines intended to ensure that this vital community resource is given only to organizations working towards a smooth transition to IPv6 to the benefit of the full community.

This is were I have issues and I believe the consensus to make a change 
is getting lost in trying to make everyone feel like they are getting a 
piece.  We are making the ponies that Owen is referring to I believe.

> In order to meet these needs, this policy has become very complex. It is an unfortunate artifact of the complex issue it seeks to address. A great deal of effort has been made to simplify the policy as much as possible, and, special thinks go out to several members of the community for their assistance in this matter.

This is the deathblow, not just complex, but a very complex, set of ponies.

> One provision in this draft policy calls for utilization criteria which may be waived by ARIN staff discretion. The intent of this clause is to allow staff to avoid penalizing an organization for successful address conservation efforts.
>
> Runout is upon us. IANA will run out of the IANA free pool and issue the last /8 this policy seeks to regulate before the next ARIN public policy meeting. If we are to make any attempt at fair distribution for the sake of IPv6 deployment, this is our final opportunity to do so outside of an emergency action by the ARIN board.
-----

If this isn't what you were referring to, please provide a more specific 
pointer.

> When you analyze the spread of who benefits from 4.10 it's legacy holders.

What??  Please explain, I'm not understating the Legacy holders comment, 
I'm not getting how 4.10 benefits Legacy holders over non-Legacy holders.

> 4.10 pretty much insures that smaller entities are less-likely to be
> required to acquire address space on the open market and that legacy holders
> are going to have addresses available for medium and larger networks to
> purchase/fund through the STLS.

Yea, so.  That is more or less just a fact of life.  I'm a big guy, I 
eat a lot, I'll be hungry sooner when we run-out of food.  But, I'll 
probably last longer on my fat reserves too.

> V4 is done, no arguments here. I'm not a legacy holder and my agenda is
> mostly cost. If we're going to have policy related to transition it should
> have some support other than "there's nothing better proposed" or we ought
> to get rid of it.

Is 4.10 about transition?  4.10 says "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."  That is not explicitly 
only transition, I also take that to mean insuring that there are little 
bit of IPv4 available long after we have transitioned to IPv6.  So, I do 
not accept that 4.10 is solely about transition.  4.10 is also about 
maintain a strategic reserve of IPv4 just in case after IPv6 is more or 
less the norm, that the free flow of IPv4 resources that most people 
expect will happen doesn't materialize.

> A fix would be better which is why 122 is out there.

So as I see it, the fundamental strategy of 122, is to tell the 
community come to a consensus or else.  This is not helpful, all it is 
doing the threatening the community.  What we need is a policy proposal 
that provides a vision for what the consensus to change 4.10 should be.

I know for a fact that a large number of people, maybe even a consensus, 
thinks that there are some things that should be fixed regarding policy 
section 8.3. Transfers to Specified Recipients.  Anyone care to try to 
come to a consensus regarding that can of worms?  Do you think putting a 
300 day deadline on coming to a consensus on how change the transfer 
policy, or have it go away would be helpful?  I think NOT!

Policy Proposal 122 is equally not helpful!  If the community is going 
to come to a consensus on how to change 4.10, it will happen in its due 
course.  If that doesn't happen then we have a policy that the community 
came to consensus on and we will see how ARIN staff will implement it. 
Maybe that will drive a consensus for how to change 4.10.

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


From marty at akamai.com  Tue Nov 30 16:39:11 2010
From: marty at akamai.com (Hannigan, Martin)
Date: Tue, 30 Nov 2010 16:39:11 -0500
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <4CF54BEA.6070107@umn.edu>
Message-ID: <C91AD92F.191F7%marty@akamai.com>




On 11/30/10 2:09 PM, "David Farmer" <farmer at umn.edu> wrote:

> On 11/30/10 09:44 CST, Hannigan, Martin wrote:
> ...
>> That thread you quote isn't relevant, IMHO. It's already been established in
>> the previous public policy meeting and following that the policy is flawed
>> and we have multiple parties here agreeing.
> 
> I agreed earlier and still agree there there is a strong consensus that
> 4.10 should be changed.


I'm really not sure what the relevance of continuing to argue that 4.10 in
it's present form is better than anything absent an actual proposal. There's
a proposal on the table to suspend 4.10. It was modified to answer
objections related to concerns that this /10 would be returned to the free
pool. So far, there are no other objections I can act on other than
consensus.

As far as I can tell, there should be no roadblocks to suspending it so that
we can fix it.


Not sure if you noticed:

 [arin-announce] Four /8 Blocks Allocated to the RIRs ? 2.73% Remains at
IANA





Best,

-M<



From owen at delong.com  Tue Nov 30 16:54:31 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Nov 2010 13:54:31 -0800
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <C91AD92F.191F7%marty@akamai.com>
References: <C91AD92F.191F7%marty@akamai.com>
Message-ID: <BC4D680A-2C57-400A-AFEE-D3B47BE1DF13@delong.com>


On Nov 30, 2010, at 1:39 PM, Hannigan, Martin wrote:

> 
> 
> 
> On 11/30/10 2:09 PM, "David Farmer" <farmer at umn.edu> wrote:
> 
>> On 11/30/10 09:44 CST, Hannigan, Martin wrote:
>> ...
>>> That thread you quote isn't relevant, IMHO. It's already been established in
>>> the previous public policy meeting and following that the policy is flawed
>>> and we have multiple parties here agreeing.
>> 
>> I agreed earlier and still agree there there is a strong consensus that
>> 4.10 should be changed.
> 
> 
> I'm really not sure what the relevance of continuing to argue that 4.10 in
> it's present form is better than anything absent an actual proposal. There's
> a proposal on the table to suspend 4.10. It was modified to answer
> objections related to concerns that this /10 would be returned to the free
> pool. So far, there are no other objections I can act on other than
> consensus.
> 
> As far as I can tell, there should be no roadblocks to suspending it so that
> we can fix it.
> 
It should not be suspended pending fixing it. The original purpose for 4.10
is still valid and likely will be necessary in the meantime. I have raised this
objection previously.

> 
> Not sure if you noticed:
> 
> [arin-announce] Four /8 Blocks Allocated to the RIRs ? 2.73% Remains at
> IANA
> 
Indeed... I doubt the IANA free pool will make it to 2011.

Owen



From farmer at umn.edu  Tue Nov 30 18:41:58 2010
From: farmer at umn.edu (David Farmer)
Date: Tue, 30 Nov 2010 17:41:58 -0600
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <BC4D680A-2C57-400A-AFEE-D3B47BE1DF13@delong.com>
References: <C91AD92F.191F7%marty@akamai.com>
	<BC4D680A-2C57-400A-AFEE-D3B47BE1DF13@delong.com>
Message-ID: <4CF58BC6.3060005@umn.edu>

On 11/30/10 15:54 CST, Owen DeLong wrote:
>
> On Nov 30, 2010, at 1:39 PM, Hannigan, Martin wrote:
>> On 11/30/10 2:09 PM, "David Farmer"<farmer at umn.edu>  wrote:
>>> On 11/30/10 09:44 CST, Hannigan, Martin wrote:
>>> ...
>>>> That thread you quote isn't relevant, IMHO. It's already been established in
>>>> the previous public policy meeting and following that the policy is flawed
>>>> and we have multiple parties here agreeing.
>>>
>>> I agreed earlier and still agree there there is a strong consensus that
>>> 4.10 should be changed.
>>
>> I'm really not sure what the relevance of continuing to argue that 4.10 in
>> it's present form is better than anything absent an actual proposal. There's
>> a proposal on the table to suspend 4.10. It was modified to answer
>> objections related to concerns that this /10 would be returned to the free
>> pool. So far, there are no other objections I can act on other than
>> consensus.

Marty,

I apologize, I should have read the changes more closely or maybe got 
more sleep last night, probably both with a causal linkage.  So sorry.

I guess, I no longer have any fundamental objection to PP#122 as it has 
been modified.   Worst case scenario it delays implementation of 4.10 
until Aug 10 2011, I could probably live with that.

But, on the other side what do you perceive the harm would be to of 
allowing 4.10 to be implemented as it is?  Or, will be if we fail to 
come to a consensus to fix it.

>> As far as I can tell, there should be no roadblocks to suspending it so that
>> we can fix it.

Well maybe fix it, the point of my earlier email was I'm confident of a 
consensus that we need to make fixes, I not confident of a consensus on 
what those fixes should be.  But I'm ready and willing to move on to 
that discussion ASAP.   The timetable for getting a Draft Policy ready 
for the Spring Policy Meeting is mighty short at this point.  Are you 
suggesting that PP#123 is the replacement for 4.10?  The way I read #123 
is that it is in addition to 4.10, do I have that wrong?

> It should not be suspended pending fixing it. The original purpose for 4.10
> is still valid and likely will be necessary in the meantime. I have raised this
> objection previously.

And Owen, what do you perceive the harm would be to suspend 4.10 until 
Aug 10 2011?

>> Not sure if you noticed:
>>
>> [arin-announce] Four /8 Blocks Allocated to the RIRs ? 2.73% Remains at
>> IANA

Yep, about 30 sec before your response.

> Indeed... I doubt the IANA free pool will make it to 2011.

I have an additional request; Given the amount of scrutiny that our 
community is likely to be put under in the coming year, for the above 
reason;

I would like to see a clear and significant (more than just the usual 
suspects) consensus that the community both supports these policies and 
more importantly that the community supports the use of the emergency 
policy process regarding these policies.  It needs to be clear to any 
third-party who reviews PPML at some future date, maybe as few as a 
couple months from now what the communities consensus was.

Therefore, please speak up on these policy proposals, and if you haven't 
posted lately to PPML, this is an excellent opportunity to rectify that 
situation.

So please let everyone know your thoughts, even if that is as simple as;

"I support PP#122 and support use of the emergency policy process", or 
not as the case may be. If you can provide some reasons why, all the 
better, but that's not required.

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


From owen at delong.com  Tue Nov 30 19:10:45 2010
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Nov 2010 16:10:45 -0800
Subject: [arin-ppml] Props. 122 + 123 process?
In-Reply-To: <4CF58BC6.3060005@umn.edu>
References: <C91AD92F.191F7%marty@akamai.com>
	<BC4D680A-2C57-400A-AFEE-D3B47BE1DF13@delong.com>
	<4CF58BC6.3060005@umn.edu>
Message-ID: <7FEFD996-D4C3-4D5A-A7B8-E570189A8B1E@delong.com>

I support PP123 and can accept putting 123 through the emergency process if others feel it is necessary.

I oppose PP122 in that I feel suspending 4.10 could be harmful and is unwarranted. I see no need for PP122
to go through the emergency process in its current form.

Owen

On Nov 30, 2010, at 3:41 PM, David Farmer wrote:

> On 11/30/10 15:54 CST, Owen DeLong wrote:
>> 
>> On Nov 30, 2010, at 1:39 PM, Hannigan, Martin wrote:
>>> On 11/30/10 2:09 PM, "David Farmer"<farmer at umn.edu>  wrote:
>>>> On 11/30/10 09:44 CST, Hannigan, Martin wrote:
>>>> ...
>>>>> That thread you quote isn't relevant, IMHO. It's already been established in
>>>>> the previous public policy meeting and following that the policy is flawed
>>>>> and we have multiple parties here agreeing.
>>>> 
>>>> I agreed earlier and still agree there there is a strong consensus that
>>>> 4.10 should be changed.
>>> 
>>> I'm really not sure what the relevance of continuing to argue that 4.10 in
>>> it's present form is better than anything absent an actual proposal. There's
>>> a proposal on the table to suspend 4.10. It was modified to answer
>>> objections related to concerns that this /10 would be returned to the free
>>> pool. So far, there are no other objections I can act on other than
>>> consensus.
> 
> Marty,
> 
> I apologize, I should have read the changes more closely or maybe got more sleep last night, probably both with a causal linkage.  So sorry.
> 
> I guess, I no longer have any fundamental objection to PP#122 as it has been modified.   Worst case scenario it delays implementation of 4.10 until Aug 10 2011, I could probably live with that.
> 
> But, on the other side what do you perceive the harm would be to of allowing 4.10 to be implemented as it is?  Or, will be if we fail to come to a consensus to fix it.
> 
>>> As far as I can tell, there should be no roadblocks to suspending it so that
>>> we can fix it.
> 
> Well maybe fix it, the point of my earlier email was I'm confident of a consensus that we need to make fixes, I not confident of a consensus on what those fixes should be.  But I'm ready and willing to move on to that discussion ASAP.   The timetable for getting a Draft Policy ready for the Spring Policy Meeting is mighty short at this point.  Are you suggesting that PP#123 is the replacement for 4.10?  The way I read #123 is that it is in addition to 4.10, do I have that wrong?
> 
>> It should not be suspended pending fixing it. The original purpose for 4.10
>> is still valid and likely will be necessary in the meantime. I have raised this
>> objection previously.
> 
> And Owen, what do you perceive the harm would be to suspend 4.10 until Aug 10 2011?
> 
>>> Not sure if you noticed:
>>> 
>>> [arin-announce] Four /8 Blocks Allocated to the RIRs ? 2.73% Remains at
>>> IANA
> 
> Yep, about 30 sec before your response.
> 
>> Indeed... I doubt the IANA free pool will make it to 2011.
> 
> I have an additional request; Given the amount of scrutiny that our community is likely to be put under in the coming year, for the above reason;
> 
> I would like to see a clear and significant (more than just the usual suspects) consensus that the community both supports these policies and more importantly that the community supports the use of the emergency policy process regarding these policies.  It needs to be clear to any third-party who reviews PPML at some future date, maybe as few as a couple months from now what the communities consensus was.
> 
> Therefore, please speak up on these policy proposals, and if you haven't posted lately to PPML, this is an excellent opportunity to rectify that situation.
> 
> So please let everyone know your thoughts, even if that is as simple as;
> 
> "I support PP#122 and support use of the emergency policy process", or not as the case may be. If you can provide some reasons why, all the better, but that's not required.
> 
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota	
> 2218 University Ave SE	    Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================