From narten at us.ibm.com  Fri Aug  7 00:53:03 2015
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 07 Aug 2015 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201508070453.t774r314006127@rotala.raleigh.ibm.com>

Total of 1 messages in the last 7 days.
 
script run at: Fri Aug  7 00:53:03 EDT 2015
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     6734 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     6734 | Total



From alfeh at me.com  Tue Aug 11 17:43:42 2015
From: alfeh at me.com (Alfie Cleveland)
Date: Tue, 11 Aug 2015 22:43:42 +0100
Subject: [arin-ppml] Automatic IPv6 Eligibility
Message-ID: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>

Hello,

I?m requesting comment in regards to automatically make organisations eligible for IPv6 if they hold justified IPv4 space. This similar to  Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource Policies. I feel that if organisations were able to receive a /48 for each /24 they hold, then it would help expedite the rollout of IPv6. Organisations currently have two choices - continue to use IPv4, or spend valuable time on applying for IPv6 space. IPv6 space is clearly in abundance - and this could potentially help slow the exhaustion of IPv4.

Regards,
Alfie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150811/52a62244/attachment.htm>

From jcurran at arin.net  Tue Aug 11 18:01:17 2015
From: jcurran at arin.net (John Curran)
Date: Tue, 11 Aug 2015 22:01:17 +0000
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
Message-ID: <109AB34A-74ED-4209-B2A4-90BC8ACD10A3@corp.arin.net>

On Aug 11, 2015, at 4:43 PM, Alfie Cleveland <alfeh at me.com<mailto:alfeh at me.com>> wrote:

Hello,

I?m requesting comment in regards to automatically make organisations eligible for IPv6 if they hold justified IPv4 space. This similar to  Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource Policies. I feel that if organisations were able to receive a /48 for each /24 they hold, then it would help expedite the rollout of IPv6. Organisations currently have two choices - continue to use IPv4, or spend valuable time on applying for IPv6 space. IPv6 space is clearly in abundance - and this could potentially help slow the exhaustion of IPv4.


Alfie -

Per NRPM 6.5.2.2, an ISP qualifies for an IPv6 allocation if they 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; i.e.  this means that they presently are automatically eligible for IPv6 if they
hold IPv4 space, as you suggest above.

Perhaps you are proposing that there be a default automatic size of IPv6 allocation ("a /48 for each
/24 they hold?) which would allow for more expeditious preparation of IPv6 initial requests, for those
who choose to receive this default allocation size rather than calculating 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??

/John

John Curran
President and CEO
ARIN

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

From alfeh at me.com  Tue Aug 11 18:05:08 2015
From: alfeh at me.com (Alfie Cleveland)
Date: Tue, 11 Aug 2015 23:05:08 +0100
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <109AB34A-74ED-4209-B2A4-90BC8ACD10A3@corp.arin.net>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<109AB34A-74ED-4209-B2A4-90BC8ACD10A3@corp.arin.net>
Message-ID: <408F4B53-FCC7-4ACE-B4F3-8044EC134E44@me.com>

John -

Apologies if I wasn?t entirely clear. As referenced in Section 9.3.1. of the APNIC INPP, I propose that this also applies to end users - allowing end users to, free of charge, receive a /48 for each /24 they hold.

Regards,
Alfie


> On 11 Aug 2015, at 23:01, John Curran <jcurran at arin.net> wrote:
> 
> On Aug 11, 2015, at 4:43 PM, Alfie Cleveland <alfeh at me.com <mailto:alfeh at me.com>> wrote:
>> 
>> Hello,
>> 
>> I?m requesting comment in regards to automatically make organisations eligible for IPv6 if they hold justified IPv4 space. This similar to  Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource Policies. I feel that if organisations were able to receive a /48 for each /24 they hold, then it would help expedite the rollout of IPv6. Organisations currently have two choices - continue to use IPv4, or spend valuable time on applying for IPv6 space. IPv6 space is clearly in abundance - and this could potentially help slow the exhaustion of IPv4.
> 
> 
> Alfie -
> 
> Per NRPM 6.5.2.2, an ISP qualifies for an IPv6 allocation if they 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; i.e.  this means that they presently are automatically eligible for IPv6 if they 
> hold IPv4 space, as you suggest above.
> 
> Perhaps you are proposing that there be a default automatic size of IPv6 allocation ("a /48 for each
> /24 they hold?) which would allow for more expeditious preparation of IPv6 initial requests, for those 
> who choose to receive this default allocation size rather than calculating 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??  
> 
> /John
> 
> John Curran
> President and CEO
> ARIN
> 

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

From sethm at rollernet.us  Tue Aug 11 20:43:40 2015
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 11 Aug 2015 17:43:40 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
Message-ID: <55CA96BC.6040308@rollernet.us>

On 8/11/15 14:43, Alfie Cleveland wrote:
> Hello,
>
> I?m requesting comment in regards to automatically make organisations
> eligible for IPv6 if they hold justified IPv4 space. This similar to
> Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
> Policies. I feel that if organisations were able to receive a /48 for
> each /24 they hold, then it would help expedite the rollout of IPv6.
> Organisations currently have two choices - continue to use IPv4, or
> spend valuable time on applying for IPv6 space. IPv6 space is clearly in
> abundance - and this could potentially help slow the exhaustion of IPv4.
>


I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and I 
don't remember having to do much to qualify for them other than ask. Has 
this changed?

~Seth


From rcarpen at network1.net  Tue Aug 11 22:11:40 2015
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 11 Aug 2015 22:11:40 -0400 (EDT)
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <55CA96BC.6040308@rollernet.us>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
Message-ID: <1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>


----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen sethm at rollernet.us wrote:

> On 8/11/15 14:43, Alfie Cleveland wrote:
>> Hello,
>>
>> I?m requesting comment in regards to automatically make organisations
>> eligible for IPv6 if they hold justified IPv4 space. This similar to
>> Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
>> Policies. I feel that if organisations were able to receive a /48 for
>> each /24 they hold, then it would help expedite the rollout of IPv6.
>> Organisations currently have two choices - continue to use IPv4, or
>> spend valuable time on applying for IPv6 space. IPv6 space is clearly in
>> abundance - and this could potentially help slow the exhaustion of IPv4.
>>
> 
> 
> I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and I
> don't remember having to do much to qualify for them other than ask. Has
> this changed?

No. If you have IPv4 space already, it is incredibly easy to get IPv6. Getting the default /48 as an end-user is about as automatic as it could be, and qualifying for more is not much more effort if you have multiple sites.

The only issue is that for end-users, you now have to pay an additional $100 per year for the IPv6 assignment.

-Randy


From arin at ics-il.net  Tue Aug 11 22:14:56 2015
From: arin at ics-il.net (Mike Hammett)
Date: Tue, 11 Aug 2015 21:14:56 -0500 (CDT)
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
Message-ID: <1782869989.7058.1439345712136.JavaMail.mhammett@ThunderFuck>

I had thought that at one point the IPv6 allocation was free for ISPs, but that deal expired at one point and it was now up to us to pay for both allocations. I'm not complaining, just seeking clarification since we're talking about getting IPv6 eligibility, costs, etc. 


----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 



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

From: "Randy Carpenter" <rcarpen at network1.net> 
To: "Seth Mattinen" <sethm at rollernet.us> 
Cc: arin-ppml at arin.net 
Sent: Tuesday, August 11, 2015 9:11:40 PM 
Subject: Re: [arin-ppml] Automatic IPv6 Eligibility 


----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen sethm at rollernet.us wrote: 

> On 8/11/15 14:43, Alfie Cleveland wrote: 
>> Hello, 
>> 
>> I?m requesting comment in regards to automatically make organisations 
>> eligible for IPv6 if they hold justified IPv4 space. This similar to 
>> Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource 
>> Policies. I feel that if organisations were able to receive a /48 for 
>> each /24 they hold, then it would help expedite the rollout of IPv6. 
>> Organisations currently have two choices - continue to use IPv4, or 
>> spend valuable time on applying for IPv6 space. IPv6 space is clearly in 
>> abundance - and this could potentially help slow the exhaustion of IPv4. 
>> 
> 
> 
> I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and I 
> don't remember having to do much to qualify for them other than ask. Has 
> this changed? 

No. If you have IPv4 space already, it is incredibly easy to get IPv6. Getting the default /48 as an end-user is about as automatic as it could be, and qualifying for more is not much more effort if you have multiple sites. 

The only issue is that for end-users, you now have to pay an additional $100 per year for the IPv6 assignment. 

-Randy 
_______________________________________________ 
PPML 
You are receiving this message because you are subscribed to 
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). 
Unsubscribe or manage your mailing list subscription at: 
http://lists.arin.net/mailman/listinfo/arin-ppml 
Please contact info at arin.net if you experience any issues. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150811/9a6b65dd/attachment.htm>

From josh at rowenetworks.com  Tue Aug 11 22:29:05 2015
From: josh at rowenetworks.com (josh at rowenetworks.com)
Date: Tue, 11 Aug 2015 22:29:05 -0400
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
Message-ID: <E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>

Well here's my scenario. My ISP is in the process of acquiring another ISP, I wrote into arin for advice of how to go about requesting additional ip space as the acquisition will take more IP addresses then what we have left out of our current /21 allotment.

I was advised to apply asap however with the depletion procedures/protocols it didn't seem likely to quickly be able to get enough blocks from the free pool.

If an existing service provider such as myself would be able to get a free ipv6 allocation I would agree it would help transition to ipv6 faster as I need more IPs for my customers, infrastructure, etc. 

I'd at least be more willing to try to make it work for my customer ip space since there would be little or no cost involved, now the problem that remains is the equipment compatibility and third party support of ipv6.

Is it possible to still get a block to use for my ISP for $100/yr? 

Best Regards,
Josh Rowe 


On August 11, 2015 10:11:40 PM EDT, Randy Carpenter <rcarpen at network1.net> wrote:
>
>----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen sethm at rollernet.us
>wrote:
>
>> On 8/11/15 14:43, Alfie Cleveland wrote:
>>> Hello,
>>>
>>> I?m requesting comment in regards to automatically make
>organisations
>>> eligible for IPv6 if they hold justified IPv4 space. This similar to
>>> Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
>>> Policies. I feel that if organisations were able to receive a /48
>for
>>> each /24 they hold, then it would help expedite the rollout of IPv6.
>>> Organisations currently have two choices - continue to use IPv4, or
>>> spend valuable time on applying for IPv6 space. IPv6 space is
>clearly in
>>> abundance - and this could potentially help slow the exhaustion of
>IPv4.
>>>
>> 
>> 
>> I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007
>and I
>> don't remember having to do much to qualify for them other than ask.
>Has
>> this changed?
>
>No. If you have IPv4 space already, it is incredibly easy to get IPv6.
>Getting the default /48 as an end-user is about as automatic as it
>could be, and qualifying for more is not much more effort if you have
>multiple sites.
>
>The only issue is that for end-users, you now have to pay an additional
>$100 per year for the IPv6 assignment.
>
>-Randy
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150811/4a3f6cd5/attachment.htm>

From David.Huberman at microsoft.com  Tue Aug 11 22:35:52 2015
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 12 Aug 2015 02:35:52 +0000
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
Message-ID: <DM2PR03MB398F85D519D579C7F5B2D249B7E0@DM2PR03MB398.namprd03.prod.outlook.com>

Hi Josh,

If you have a /21 allocation from ARIN, then you are paying them $1,000 a year in a subscription fee.  That covers your AS number, and your /21, and it gives you membership to vote.

If you want, you can request a /36 of IPv6 from ARIN, and it will come at no extra charge.  There will be no registration fee, and your annual subscription fee will not change.

From an engineering perspective, many of us do not recommend that.  We recommend getting the full default prefix size ? a /32 ? and deploying that.   Unfortunately, that will cause your annual subscription fee with ARIN to double to $2,000.  You still won?t pay a registration fee for getting the /32, but when your next annual bill is sent, it will be for $2,000 rather than $1,000.

Please keep in mind that the only realistic way I know of to get more IPv4 addresses for your new products and customers is via the IPv4 transfer market, and that?s going to cost many, many times more than ARIN charges.  Many tens of thousands of dollars, probably, depending on what you want to get.   You may wish to balance the cost of obtaining more IPv4 addresses in the market with what revenue opportunities those addresses represent, then factor in how you can (or cannot) leverage IPv6 to make those numbers work better for you.  Just a suggestion, and sorry if I?m overstepping.

David

David R Huberman
Principal, Global IP Addressing
Microsoft Corporation

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of josh at rowenetworks.com
Sent: Tuesday, August 11, 2015 7:29 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Automatic IPv6 Eligibility

Well here's my scenario. My ISP is in the process of acquiring another ISP, I wrote into arin for advice of how to go about requesting additional ip space as the acquisition will take more IP addresses then what we have left out of our current /21 allotment.

I was advised to apply asap however with the depletion procedures/protocols it didn't seem likely to quickly be able to get enough blocks from the free pool.

If an existing service provider such as myself would be able to get a free ipv6 allocation I would agree it would help transition to ipv6 faster as I need more IPs for my customers, infrastructure, etc.

I'd at least be more willing to try to make it work for my customer ip space since there would be little or no cost involved, now the problem that remains is the equipment compatibility and third party support of ipv6.

Is it possible to still get a block to use for my ISP for $100/yr?

Best Regards,
Josh Rowe

On August 11, 2015 10:11:40 PM EDT, Randy Carpenter <rcarpen at network1.net<mailto:rcarpen at network1.net>> wrote:

----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen sethm at rollernet.us<mailto:sethm at rollernet.us> wrote:

 On 8/11/15 14:43, Alfie Cleveland wrote:

 Hello,

 I?m requesting comment in regards to automatically make organisations
 eligible for IPv6 if they hold justified IPv4 space. This similar to
 Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
 Policies. I feel that if organisations were able to receive a /48 for
 each /24 they hold, then it would help expedite the rollout of IPv6.
 Organisations currently have two choices - continue to use IPv4, or
 spend valuable time on applying for IPv6 space. IPv6 space is clearly in
 abundance - and this could potentially help slo

 w the

exhaustion of IPv4.



 I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and I
 don't remember having to do much to qualify for them other than ask. Has
 this changed?

No. If you have IPv4 space already, it is incredibly easy to get IPv6. Getting the default /48 as an end-user is about as automatic as it could be, and qualifying for more is not much more effort if you have multiple sites.

The only issue is that for end-users, you now have to pay an additional $100 per year for the IPv6 assignment.

-Randy

________________________________

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<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7cda43505669344383a23b08d2a2bdd610%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8tB7qrXRyzQxkxErQNddayFfecqCmrp54AhlO7IzCkE%3d>
Please contact info at arin.net<mailto:info at arin.net> if you experi

 ence

any issues.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150812/d04dcd55/attachment.htm>

From pmcnary at cameron.net  Tue Aug 11 22:36:57 2015
From: pmcnary at cameron.net (Paul)
Date: Tue, 11 Aug 2015 21:36:57 -0500
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
Message-ID: <55CAB149.6010708@cameron.net>

Hello

We are getting ready to lose a /22 and /23 and 2 /24's when we switch 
from microwave data center providers
to fiber for our ISP that the data centers have been providing for us 
since the dial-up days .
/22 and /23 are no longer available. Will we have to pay the $100 annual 
fee on each /24 block allocated
even though nothing larger is available? Can we get an IPv6 allocation 
large enough when we file for AS number
for a several month cross over from microwave to fiber?

Thank you
Paul McNary
Internet Associates







On 8/11/2015 9:29 PM, josh at rowenetworks.com wrote:
> Well here's my scenario. My ISP is in the process of acquiring another 
> ISP, I wrote into arin for advice of how to go about requesting 
> additional ip space as the acquisition will take more IP addresses 
> then what we have left out of our current /21 allotment.
>
> I was advised to apply asap however with the depletion 
> procedures/protocols it didn't seem likely to quickly be able to get 
> enough blocks from the free pool.
>
> If an existing service provider such as myself would be able to get a 
> free ipv6 allocation I would agree it would help transition to ipv6 
> faster as I need more IPs for my customers, infrastructure, etc.
>
> I'd at least be more willing to try to make it work for my customer ip 
> space since there would be little or no cost involved, now the problem 
> that remains is the equipment compatibility and third party support of 
> ipv6.
>
> Is it possible to still get a block to use for my ISP for $100/yr?
>
> Best Regards,
> Josh Rowe
>
>
> On August 11, 2015 10:11:40 PM EDT, Randy Carpenter 
> <rcarpen at network1.net> wrote:
>
>     ----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen sethm at rollernet.us wrote:
>
>         On 8/11/15 14:43, Alfie Cleveland wrote:
>
>             Hello, I?m requesting comment in regards to automatically
>             make organisations eligible for IPv6 if they hold
>             justified IPv4 space. This similar to Section 9.3.1. of
>             the [APNIC-127] APNIC Internet Number Resource Policies. I
>             feel that if organisations were able to receive a /48 for
>             each /24 they hold, then it would help expedite the
>             rollout of IPv6. Organisations currently have two choices
>             - continue to use IPv4, or spend valuable time on applying
>             for IPv6 space. IPv6 space is clearly in abundance - and
>             this could potentially help slo w the exhaustion of IPv4.
>
>         I got my /32 IPv6 allocation in late 2009 and end user /48 in
>         2007 and I don't remember having to do much to qualify for
>         them other than ask. Has this changed? 
>
>
>     No. If you have IPv4 space already, it is incredibly easy to get IPv6. Getting the default /48 as an end-user is about as automatic as it could be, and qualifying for more is not much more effort if you have multiple sites.
>
>     The only issue is that for end-users, you now have to pay an additional $100 per year for the IPv6 assignment.
>
>     -Randy
>     ------------------------------------------------------------------------
>
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>     Unsubscribe or manage your mailing list subscription at:
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>     Please contact info at arin.net if you experi
>       ence
>     any issues.
>
> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20150811/04d7f0e1/attachment.htm>

From tsamplonius at ubn.ca  Tue Aug 11 22:47:16 2015
From: tsamplonius at ubn.ca (Tom Samplonius)
Date: Tue, 11 Aug 2015 19:47:16 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <55CAB149.6010708@cameron.net>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
	<55CAB149.6010708@cameron.net>
Message-ID: <66A244E4-0916-49B4-983D-BF442B7547F1@ubn.ca>


> On Aug 11, 2015, at 7:36 PM, Paul <pmcnary at cameron.net> wrote:
> 
> Hello
> 
> We are getting ready to lose a /22 and /23 and 2 /24's when we switch from microwave data center providers
> to fiber for our ISP that the data centers have been providing for us since the dial-up days .
> /22 and /23 are no longer available. Will we have to pay the $100 annual fee on each /24 block allocated
> even though nothing larger is available? Can we get an IPv6 allocation large enough when we file for AS number
> for a several month cross over from microwave to fiber?


  Keep in mind that a IPv6 /32 or /36 are very large blocks in comparison to a /21 worth of IPv4.

  A /32 allows you to assign a /64 each to about 4 billion customers.


Tom



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

From josh at rowenetworks.com  Tue Aug 11 23:02:34 2015
From: josh at rowenetworks.com (josh at rowenetworks.com)
Date: Tue, 11 Aug 2015 23:02:34 -0400
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <DM2PR03MB398F85D519D579C7F5B2D249B7E0@DM2PR03MB398.namprd03.prod.outlook.com>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
	<DM2PR03MB398F85D519D579C7F5B2D249B7E0@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <B5C53E40-C2C7-43B7-8EE0-5E710CA8E235@rowenetworks.com>

David,
Thank very much for taking the time to respond and with so much detail. It is very helpful information.

I noticed I had a typo on our current allocation, /22 is what we have not /21. 

Regardless, I understand what you're saying as to engineer it properly so that as ipv6 adoption and services increase I'm not stuck with an inferior design or a broken network. 100% agree. 

Now we're talking about a $1500 increase in annual fees, which is not ideal but provides access to over 65k /48,,, I can see this being a better long term solution compared to ipv4 space being leased from someone else long term.

Now to start evaluating our infrastructure and the new acquisition for ipv6 capabilities and upgrade path, just when I thought I had enough work to do!

Thanks again for your time and advice! 

Best Regards, 
Josh Rowe 



On August 11, 2015 10:35:52 PM EDT, David Huberman <David.Huberman at microsoft.com> wrote:
>Hi Josh,
>
>If you have a /21 allocation from ARIN, then you are paying them $1,000
>a year in a subscription fee.  That covers your AS number, and your
>/21, and it gives you membership to vote.
>
>If you want, you can request a /36 of IPv6 from ARIN, and it will come
>at no extra charge.  There will be no registration fee, and your annual
>subscription fee will not change.
>
>From an engineering perspective, many of us do not recommend that.  We
>recommend getting the full default prefix size ? a /32 ? and deploying
>that.   Unfortunately, that will cause your annual subscription fee
>with ARIN to double to $2,000.  You still won?t pay a registration fee
>for getting the /32, but when your next annual bill is sent, it will be
>for $2,000 rather than $1,000.
>
>Please keep in mind that the only realistic way I know of to get more
>IPv4 addresses for your new products and customers is via the IPv4
>transfer market, and that?s going to cost many, many times more than
>ARIN charges.  Many tens of thousands of dollars, probably, depending
>on what you want to get.   You may wish to balance the cost of
>obtaining more IPv4 addresses in the market with what revenue
>opportunities those addresses represent, then factor in how you can (or
>cannot) leverage IPv6 to make those numbers work better for you.  Just
>a suggestion, and sorry if I?m overstepping.
>
>David
>
>David R Huberman
>Principal, Global IP Addressing
>Microsoft Corporation
>
>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>Behalf Of josh at rowenetworks.com
>Sent: Tuesday, August 11, 2015 7:29 PM
>To: arin-ppml at arin.net
>Subject: Re: [arin-ppml] Automatic IPv6 Eligibility
>
>Well here's my scenario. My ISP is in the process of acquiring another
>ISP, I wrote into arin for advice of how to go about requesting
>additional ip space as the acquisition will take more IP addresses then
>what we have left out of our current /21 allotment.
>
>I was advised to apply asap however with the depletion
>procedures/protocols it didn't seem likely to quickly be able to get
>enough blocks from the free pool.
>
>If an existing service provider such as myself would be able to get a
>free ipv6 allocation I would agree it would help transition to ipv6
>faster as I need more IPs for my customers, infrastructure, etc.
>
>I'd at least be more willing to try to make it work for my customer ip
>space since there would be little or no cost involved, now the problem
>that remains is the equipment compatibility and third party support of
>ipv6.
>
>Is it possible to still get a block to use for my ISP for $100/yr?
>
>Best Regards,
>Josh Rowe
>
>On August 11, 2015 10:11:40 PM EDT, Randy Carpenter
><rcarpen at network1.net<mailto:rcarpen at network1.net>> wrote:
>
>----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen
>sethm at rollernet.us<mailto:sethm at rollernet.us> wrote:
>
> On 8/11/15 14:43, Alfie Cleveland wrote:
>
> Hello,
>
> I?m requesting comment in regards to automatically make organisations
> eligible for IPv6 if they hold justified IPv4 space. This similar to
> Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
> Policies. I feel that if organisations were able to receive a /48 for
> each /24 they hold, then it would help expedite the rollout of IPv6.
> Organisations currently have two choices - continue to use IPv4, or
>spend valuable time on applying for IPv6 space. IPv6 space is clearly
>in
> abundance - and this could potentially help slo
>
> w the
>
>exhaustion of IPv4.
>
>
>
>I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and
>I
>don't remember having to do much to qualify for them other than ask.
>Has
> this changed?
>
>No. If you have IPv4 space already, it is incredibly easy to get IPv6.
>Getting the default /48 as an end-user is about as automatic as it
>could be, and qualifying for more is not much more effort if you have
>multiple sites.
>
>The only issue is that for end-users, you now have to pay an additional
>$100 per year for the IPv6 assignment.
>
>-Randy
>
>________________________________
>
>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<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7cda43505669344383a23b08d2a2bdd610%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8tB7qrXRyzQxkxErQNddayFfecqCmrp54AhlO7IzCkE%3d>
>Please contact info at arin.net<mailto:info at arin.net> if you experi
>
> ence
>
>any issues.
>
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150811/5189ed37/attachment.htm>

From matthew at matthew.at  Tue Aug 11 23:31:55 2015
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 11 Aug 2015 20:31:55 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <66A244E4-0916-49B4-983D-BF442B7547F1@ubn.ca>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
	<55CAB149.6010708@cameron.net>
	<66A244E4-0916-49B4-983D-BF442B7547F1@ubn.ca>
Message-ID: <2879C5CB-C48B-416B-9460-896CCC994F35@matthew.at>





> On Aug 11, 2015, at 7:47 PM, Tom Samplonius <tsamplonius at ubn.ca> wrote:
> 
> 
>> On Aug 11, 2015, at 7:36 PM, Paul <pmcnary at cameron.net> wrote:
>> 
>> Hello
>> 
>> We are getting ready to lose a /22 and /23 and 2 /24's when we switch from microwave data center providers
>> to fiber for our ISP that the data centers have been providing for us since the dial-up days .
>> /22 and /23 are no longer available. Will we have to pay the $100 annual fee on each /24 block allocated
>> even though nothing larger is available? Can we get an IPv6 allocation large enough when we file for AS number
>> for a several month cross over from microwave to fiber?
> 
> 
>   Keep in mind that a IPv6 /32 or /36 are very large blocks in comparison to a /21 worth of IPv4.
> 
>   A /32 allows you to assign a /64 each to about 4 billion customers.
> 

If you're assigning /64s to your customers, you shouldn't be allowed to have any addresses, never mind a /32

Matthew Kaufman

(Sent from my iPhone)


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

From jschiller at google.com  Wed Aug 12 00:22:56 2015
From: jschiller at google.com (Jason Schiller)
Date: Wed, 12 Aug 2015 00:22:56 -0400
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <DM2PR03MB398F85D519D579C7F5B2D249B7E0@DM2PR03MB398.namprd03.prod.outlook.com>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
	<DM2PR03MB398F85D519D579C7F5B2D249B7E0@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAC4yj2U6bz0r5yXKYY0KY9eZ4K1_oUuFuDikg3jucqMM-Ad3dA@mail.gmail.com>

For ISPs a /22 is billed at XX-small at $500 annually.
(this includes ASNs and membership vote)

adding up to a /40 keeps the ISP in the XX-small category and does not
change the annual fee.

An IPv4 /32 bumps the ISP up to a small with an annual fee of $2,000.  (a
$1,500 increase).
(If the ISP already had more than a /20 there would be no increase in fees)


End sites are billed differently
End sites pay $100 per resource.
one /22 costs $100.
two /24s cost $200.
one /20, two /23s, and two ASNs cost $500 annually.

There is an additional one time fee for new resources based on the size of
the resource.

So an end user with one /22 and one ASN the annual fee is $200.

There is a one time initial fee of of $500 for a single block that is a /40
or smaller
(this is in addition to the $200 annual fee for IPv4 and ASN)

The following year the annual fee will go up by $100 for a total of $300.

___Jason




On Tue, Aug 11, 2015 at 10:35 PM, David Huberman <
David.Huberman at microsoft.com> wrote:

> Hi Josh,
>
>
>
> If you have a /21 allocation from ARIN, then you are paying them $1,000 a
> year in a subscription fee.  That covers your AS number, and your /21, and
> it gives you membership to vote.
>
>
>
> If you want, you can request a /36 of IPv6 from ARIN, and it will come at
> no extra charge.  There will be no registration fee, and your annual
> subscription fee will not change.
>
>
>
> From an engineering perspective, many of us do not recommend that.  We
> recommend getting the full default prefix size ? a /32 ? and deploying
> that.   Unfortunately, that will cause your annual subscription fee with
> ARIN to double to $2,000.  You still won?t pay a registration fee for
> getting the /32, but when your next annual bill is sent, it will be for
> $2,000 rather than $1,000.
>
>
>
> Please keep in mind that the only realistic way I know of to get more IPv4
> addresses for your new products and customers is via the IPv4 transfer
> market, and that?s going to cost many, many times more than ARIN charges.
> Many tens of thousands of dollars, probably, depending on what you want to
> get.   You may wish to balance the cost of obtaining more IPv4 addresses in
> the market with what revenue opportunities those addresses represent, then
> factor in how you can (or cannot) leverage IPv6 to make those numbers work
> better for you.  Just a suggestion, and sorry if I?m overstepping.
>
>
>
> David
>
>
>
> *David R Huberman*
> Principal, Global IP Addressing
>
> Microsoft Corporation
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *josh at rowenetworks.com
> *Sent:* Tuesday, August 11, 2015 7:29 PM
> *To:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] Automatic IPv6 Eligibility
>
>
>
> Well here's my scenario. My ISP is in the process of acquiring another
> ISP, I wrote into arin for advice of how to go about requesting additional
> ip space as the acquisition will take more IP addresses then what we have
> left out of our current /21 allotment.
>
>
> I was advised to apply asap however with the depletion
> procedures/protocols it didn't seem likely to quickly be able to get enough
> blocks from the free pool.
>
> If an existing service provider such as myself would be able to get a free
> ipv6 allocation I would agree it would help transition to ipv6 faster as I
> need more IPs for my customers, infrastructure, etc.
>
> I'd at least be more willing to try to make it work for my customer ip
> space since there would be little or no cost involved, now the problem that
> remains is the equipment compatibility and third party support of ipv6.
>
> Is it possible to still get a block to use for my ISP for $100/yr?
>
> Best Regards,
> Josh Rowe
>
> On August 11, 2015 10:11:40 PM EDT, Randy Carpenter <rcarpen at network1.net>
> wrote:
>
>
> ----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen sethm at rollernet.us wrote:
>
>  On 8/11/15 14:43, Alfie Cleveland wrote:
>
>  Hello,
>
>  I?m requesting comment in regards to automatically make organisations
>  eligible for IPv6 if they hold justified IPv4 space. This similar to
>  Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
>  Policies. I feel that if organisations were able to receive a /48 for
>  each /24 they hold, then it would help expedite the rollout of IPv6.
>  Organisations currently have two choices - continue to use IPv4, or
>  spend valuable time on applying for IPv6 space. IPv6 space is clearly in
>  abundance - and this could potentially help slo
>
>  w the
>
> exhaustion of IPv4.
>
>
>
>
>  I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and I
>  don't remember having to do much to qualify for them other than ask. Has
>  this changed?
>
>
> No. If you have IPv4 space already, it is incredibly easy to get IPv6. Getting the default /48 as an end-user is about as automatic as it could be, and qualifying for more is not much more effort if you have multiple sites.
>
> The only issue is that for end-users, you now have to pay an additional $100 per year for the IPv6 assignment.
>
> -Randy
>
> ------------------------------
>
>
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7cda43505669344383a23b08d2a2bdd610%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8tB7qrXRyzQxkxErQNddayFfecqCmrp54AhlO7IzCkE%3d>
> Please contact info at arin.net if you experi
>
>  ence
>
> any issues.
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150812/e0aadb75/attachment.htm>

From pmcnary at cameron.net  Wed Aug 12 00:42:07 2015
From: pmcnary at cameron.net (Paul)
Date: Tue, 11 Aug 2015 23:42:07 -0500
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <CAC4yj2U6bz0r5yXKYY0KY9eZ4K1_oUuFuDikg3jucqMM-Ad3dA@mail.gmail.com>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
	<DM2PR03MB398F85D519D579C7F5B2D249B7E0@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC4yj2U6bz0r5yXKYY0KY9eZ4K1_oUuFuDikg3jucqMM-Ad3dA@mail.gmail.com>
Message-ID: <55CACE9F.1060206@cameron.net>

We are an ISP.
Will 4 different non-contiguous blocks be counted as 1 or 4 blocks for fees.
Or is the block count the total of all combined /24's that we would get 
allocated?
So a /22 (or 4 /24's)  plus a /40 plus ASN for an ISP would be $500 
annually?

Thanks



On 8/11/2015 11:22 PM, Jason Schiller wrote:
> For ISPs a /22 is billed at XX-small at $500 annually.
> (this includes ASNs and membership vote)
>
> adding up to a /40 keeps the ISP in the XX-small category and does not 
> change the annual fee.
>
> An IPv4 /32 bumps the ISP up to a small with an annual fee of $2,000. 
>  (a $1,500 increase).
> (If the ISP already had more than a /20 there would be no increase in 
> fees)
>
>
> End sites are billed differently
> End sites pay $100 per resource.
> one /22 costs $100.
> two /24s cost $200.
> one /20, two /23s, and two ASNs cost $500 annually.
>
> There is an additional one time fee for new resources based on the 
> size of the resource.
>
> So an end user with one /22 and one ASN the annual fee is $200.
>
> There is a one time initial fee of of $500 for a single block that is 
> a /40 or smaller
> (this is in addition to the $200 annual fee for IPv4 and ASN)
>
> The following year the annual fee will go up by $100 for a total of $300.
>
> ___Jason
>
>
>
> On Tue, Aug 11, 2015 at 10:35 PM, David Huberman 
> <David.Huberman at microsoft.com <mailto:David.Huberman at microsoft.com>> 
> wrote:
>
>     Hi Josh,
>
>     If you have a /21 allocation from ARIN, then you are paying them
>     $1,000 a year in a subscription fee. That covers your AS number,
>     and your /21, and it gives you membership to vote.
>
>     If you want, you can request a /36 of IPv6 from ARIN, and it will
>     come at no extra charge.  There will be no registration fee, and
>     your annual subscription fee will not change.
>
>     From an engineering perspective, many of us do not recommend
>     that.  We recommend getting the full default prefix size ? a /32 ?
>     and deploying that.   Unfortunately, that will cause your annual
>     subscription fee with ARIN to double to $2,000.  You still won?t
>     pay a registration fee for getting the /32, but when your next
>     annual bill is sent, it will be for $2,000 rather than $1,000.
>
>     Please keep in mind that the only realistic way I know of to get
>     more IPv4 addresses for your new products and customers is via the
>     IPv4 transfer market, and that?s going to cost many, many times
>     more than ARIN charges.  Many tens of thousands of dollars,
>     probably, depending on what you want to get.   You may wish to
>     balance the cost of obtaining more IPv4 addresses in the market
>     with what revenue opportunities those addresses represent, then
>     factor in how you can (or cannot) leverage IPv6 to make those
>     numbers work better for you.  Just a suggestion, and sorry if I?m
>     overstepping.
>
>     David
>
>     *David R Huberman*
>     Principal, Global IP Addressing
>
>     Microsoft Corporation
>
>     *From:*arin-ppml-bounces at arin.net
>     <mailto:arin-ppml-bounces at arin.net>
>     [mailto:arin-ppml-bounces at arin.net
>     <mailto:arin-ppml-bounces at arin.net>] *On Behalf Of
>     *josh at rowenetworks.com <mailto:josh at rowenetworks.com>
>     *Sent:* Tuesday, August 11, 2015 7:29 PM
>     *To:* arin-ppml at arin.net <mailto:arin-ppml at arin.net>
>     *Subject:* Re: [arin-ppml] Automatic IPv6 Eligibility
>
>     Well here's my scenario. My ISP is in the process of acquiring
>     another ISP, I wrote into arin for advice of how to go about
>     requesting additional ip space as the acquisition will take more
>     IP addresses then what we have left out of our current /21 allotment.
>
>
>
>     I was advised to apply asap however with the depletion
>     procedures/protocols it didn't seem likely to quickly be able to
>     get enough blocks from the free pool.
>
>     If an existing service provider such as myself would be able to
>     get a free ipv6 allocation I would agree it would help transition
>     to ipv6 faster as I need more IPs for my customers,
>     infrastructure, etc.
>
>     I'd at least be more willing to try to make it work for my
>     customer ip space since there would be little or no cost involved,
>     now the problem that remains is the equipment compatibility and
>     third party support of ipv6.
>
>     Is it possible to still get a block to use for my ISP for $100/yr?
>
>     Best Regards,
>     Josh Rowe
>
>     On August 11, 2015 10:11:40 PM EDT, Randy Carpenter
>     <rcarpen at network1.net <mailto:rcarpen at network1.net>> wrote:
>
>         ----- On Aug 11, 2015, at 8:43 PM, Seth Mattinensethm at rollernet.us <mailto:sethm at rollernet.us>  wrote:
>
>               On 8/11/15 14:43, Alfie Cleveland wrote:
>
>                   Hello,
>
>                   I?m requesting comment in regards to automatically make organisations
>                   eligible for IPv6 if they hold justified IPv4 space. This similar to
>                   Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
>                   Policies. I feel that if organisations were able to receive a /48 for
>                   each /24 they hold, then it would help expedite the rollout of IPv6.
>                   Organisations currently have two choices - continue to use IPv4, or
>                   spend valuable time on applying for IPv6 space. IPv6 space is clearly in
>                   abundance - and this could potentially help slo
>
>                   w the
>
>                 exhaustion of IPv4.
>
>               
>               
>               I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and I
>               don't remember having to do much to qualify for them other than ask. Has
>               this changed?
>
>         No. If you have IPv4 space already, it is incredibly easy to get IPv6. Getting the default /48 as an end-user is about as automatic as it could be, and qualifying for more is not much more effort if you have multiple sites.
>
>         The only issue is that for end-users, you now have to pay an additional $100 per year for the IPv6 assignment.
>
>         -Randy
>
>         ------------------------------------------------------------------------
>
>         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
>         <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7cda43505669344383a23b08d2a2bdd610%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8tB7qrXRyzQxkxErQNddayFfecqCmrp54AhlO7IzCkE%3d>
>         Please contactinfo at arin.net <mailto:info at arin.net>  if you experi
>
>           ence
>
>         any issues.
>
>     -- Sent from my Android device with K-9 Mail. Please excuse my
>     brevity.
>
>     _______________________________________________ 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. 
>
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com 
> <mailto:jschiller at google.com>|571-266-0006
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20150811/9aa52216/attachment.htm>

From arin at ics-il.net  Wed Aug 12 05:14:29 2015
From: arin at ics-il.net (Mike Hammett)
Date: Wed, 12 Aug 2015 04:14:29 -0500 (CDT)
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <55CACE9F.1060206@cameron.net>
Message-ID: <2060462515.91.1439370909045.JavaMail.mhammett@ThunderFuck>

Maybe the lesson in all of this is that ARIN needs a calculator on their web site? ;-) 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "Paul" <pmcnary at cameron.net> 
To: arin-ppml at arin.net 
Sent: Tuesday, August 11, 2015 11:42:07 PM 
Subject: Re: [arin-ppml] Automatic IPv6 Eligibility 


We are an ISP. 
Will 4 different non-contiguous blocks be counted as 1 or 4 blocks for fees. 
Or is the block count the total of all combined /24's that we would get allocated? 
So a /22 (or 4 /24's) plus a /40 plus ASN for an ISP would be $500 annually? 

Thanks 



On 8/11/2015 11:22 PM, Jason Schiller wrote: 



For ISPs a /22 is billed at XX-small at $500 annually. 
(this includes ASNs and membership vote) 



adding up to a /40 keeps the ISP in the XX-small category and does not change the annual fee. 


An IPv4 /32 bumps the ISP up to a small with an annual fee of $2,000. (a $1,500 increase). 
(If the ISP already had more than a /20 there would be no increase in fees) 




End sites are billed differently 
End sites pay $100 per resource. 
one /22 costs $100. 
two /24s cost $200. 
one /20, two /23s, and two ASNs cost $500 annually. 


There is an additional one time fee for new resources based on the size of the resource. 


So an end user with one /22 and one ASN the annual fee is $200. 


There is a one time initial fee of of $500 for a single block that is a /40 or smaller 
(this is in addition to the $200 annual fee for IPv4 and ASN) 


The following year the annual fee will go up by $100 for a total of $300. 


___Jason 







On Tue, Aug 11, 2015 at 10:35 PM, David Huberman < David.Huberman at microsoft.com > wrote: 

<blockquote>



Hi Josh, 

If you have a /21 allocation from ARIN, then you are paying them $1,000 a year in a subscription fee. That covers your AS number, and your /21, and it gives you membership to vote. 

If you want, you can request a /36 of IPv6 from ARIN, and it will come at no extra charge. There will be no registration fee, and your annual subscription fee will not change. 

>From an engineering perspective, many of us do not recommend that. We recommend getting the full default prefix size ? a /32 ? and deploying that. Unfortunately, that will cause your annual subscription fee with ARIN to double to $2,000. You still won?t pay a registration fee for getting the /32, but when your next annual bill is sent, it will be for $2,000 rather than $1,000. 

Please keep in mind that the only realistic way I know of to get more IPv4 addresses for your new products and customers is via the IPv4 transfer market, and that?s going to cost many, many times more than ARIN charges. Many tens of thousands of dollars, probably, depending on what you want to get. You may wish to balance the cost of obtaining more IPv4 addresses in the market with what revenue opportunities those addresses represent, then factor in how you can (or cannot) leverage IPv6 to make those numbers work better for you. Just a suggestion, and sorry if I?m overstepping. 

David 


David R Huberman 
Principal, Global IP Addressing 
Microsoft Corporation 




From: arin-ppml-bounces at arin.net [mailto: arin-ppml-bounces at arin.net ] On Behalf Of josh at rowenetworks.com 
Sent: Tuesday, August 11, 2015 7:29 PM 
To: arin-ppml at arin.net 
Subject: Re: [arin-ppml] Automatic IPv6 Eligibility 

Well here's my scenario. My ISP is in the process of acquiring another ISP, I wrote into arin for advice of how to go about requesting additional ip space as the acquisition will take more IP addresses then what we have left out of our current /21 allotment. 



I was advised to apply asap however with the depletion procedures/protocols it didn't seem likely to quickly be able to get enough blocks from the free pool. 

If an existing service provider such as myself would be able to get a free ipv6 allocation I would agree it would help transition to ipv6 faster as I need more IPs for my customers, infrastructure, etc. 

I'd at least be more willing to try to make it work for my customer ip space since there would be little or no cost involved, now the problem that remains is the equipment compatibility and third party support of ipv6. 

Is it possible to still get a block to use for my ISP for $100/yr? 

Best Regards, 
Josh Rowe 





On August 11, 2015 10:11:40 PM EDT, Randy Carpenter < rcarpen at network1.net > wrote: 
<blockquote>
----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen sethm at rollernet.us wrote: 
<blockquote>
On 8/11/15 14:43, Alfie Cleveland wrote: 
<blockquote>
Hello,

 I?m requesting comment in regards to automatically make organisations
 eligible for IPv6 if they hold justified IPv4 space. This similar to
 Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
 Policies. I feel that if organisations were able to receive a /48 for
 each /24 they hold, then it would help expedite the rollout of IPv6.
 Organisations currently have two choices - continue to use IPv4, or
 spend valuable time on applying for IPv6 space. IPv6 space is clearly in
 abundance - and this could potentially help slo w the exhaustion of IPv4. 

I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and I
 don't remember having to do much to qualify for them other than ask. Has
 this changed? 
</blockquote>
No. If you have IPv4 space already, it is incredibly easy to get IPv6. Getting the default /48 as an end-user is about as automatic as it could be, and qualifying for more is not much more effort if you have multiple sites.

The only issue is that for end-users, you now have to pay an additional $100 per year for the IPv6 assignment.

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

-- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. 
</blockquote>

-- 

_______________________________________________________ 
Jason Schiller|NetOps| jschiller at google.com |571-266-0006 
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ).
Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. 
</blockquote>

_______________________________________________ 
PPML 
You are receiving this message because you are subscribed to 
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). 
Unsubscribe or manage 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/20150812/0c14f6fa/attachment.htm>

From jcurran at arin.net  Wed Aug 12 11:33:04 2015
From: jcurran at arin.net (John Curran)
Date: Wed, 12 Aug 2015 15:33:04 +0000
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <55CACE9F.1060206@cameron.net>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
	<DM2PR03MB398F85D519D579C7F5B2D249B7E0@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC4yj2U6bz0r5yXKYY0KY9eZ4K1_oUuFuDikg3jucqMM-Ad3dA@mail.gmail.com>
	<55CACE9F.1060206@cameron.net>
Message-ID: <FEC60A6D-C6B7-4791-9B4B-7A14DDE10930@corp.arin.net>

On Aug 11, 2015, at 11:42 PM, Paul <pmcnary at cameron.net<mailto:pmcnary at cameron.net>> wrote:

We are an ISP.
Will 4 different non-contiguous blocks be counted as 1 or 4 blocks for fees.
Or is the block count the total of all combined /24's that we would get allocated?
So a /22 (or 4 /24's)  plus a /40 plus ASN for an ISP would be $500 annually?

Paul -

   Each ISP's fee category is set to the largest category which will accommodate
   their IPv4 and IPv6 resource holdings;  i.e. it is the sum of the IPv4 blocks which
   is looked up on the fee schedule <https://www.arin.net/fees/fee_schedule.html>

   A /22 of total IPv4 holdings (and up to /40 for IPv6) is XX-Small, paying $500/year.
   (maintenance fees for any number of ASN?s are also included in that amount)

Please do not hesitate to ask myself (or the ARIN helpdesk) if you have any
questions on the fee schedule.

Thanks!
/John

John Curran
President and CEO
ARIN



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

From bill at herrin.us  Wed Aug 12 11:53:58 2015
From: bill at herrin.us (William Herrin)
Date: Wed, 12 Aug 2015 11:53:58 -0400
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <CAP-guGWTuBUh-poLaZAGEu8vPQ2o+18FJRijDNg_p876LPG9yw@mail.gmail.com>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<109AB34A-74ED-4209-B2A4-90BC8ACD10A3@corp.arin.net>
	<408F4B53-FCC7-4ACE-B4F3-8044EC134E44@me.com>
	<CAP-guGWTuBUh-poLaZAGEu8vPQ2o+18FJRijDNg_p876LPG9yw@mail.gmail.com>
Message-ID: <CAP-guGVPYdUGodyFCrvMph0UH_nz=v5Pj3+7Zdynxatbz7B2rg@mail.gmail.com>

Gmail has failed me. :( It reverted my accounts->send-mail-as settings
to use an email server that hasn't been valid for the better part of a
year and then neglected to report that it couldn't connect and send my
email messages. Just lovely to discover that no one received mail from
me for 6 days. I guess my reputation for "prompt" replies is just that
bad.


On Tue, Aug 11, 2015 at 5:57 PM, William Herrin <bill at herrin.us> wrote:
> On Tue, Aug 11, 2015 at 5:43 PM, Alfie Cleveland <alfeh at me.com> wrote:
>> I?m requesting comment in regards to automatically make organisations
>> eligible for IPv6 if they hold justified IPv4 space. This similar to
>> Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource Policies. I
>> feel that if organisations were able to receive a /48 for each /24 they
>> hold, then it would help expedite the rollout of IPv6. Organisations
>> currently have two choices - continue to use IPv4, or spend valuable time on
>> applying for IPv6 space. IPv6 space is clearly in abundance - and this could
>> potentially help slow the exhaustion of IPv4.
>
> Howdy,
>
> https://www.arin.net/policy/nrpm.html#six581
> part a
>
> That's pretty much automatic.
>
> Making a sort of "a priori" assignment has been considered, but as I
> recall the problem was that IPv6 sizing works differently than IPv4
> sizing so the registry can't "a priori" know what size IPv6 assignment
> or allocation is right for a particular organization. We prefer they
> get all the IPv6 addresses they need in a single assignment so they
> don't ever need discontiguous assignments. So, ARIN has to wait until
> the registrant tells it what size they want.



> On Tue, Aug 11, 2015 at 6:05 PM, Alfie Cleveland <alfeh at me.com> wrote:
>> Apologies if I wasn?t entirely clear. As referenced in Section 9.3.1. of the
>> APNIC INPP, I propose that this also applies to end users - allowing end
>> users to, free of charge, receive a /48 for each /24 they hold.

Hi Alfie,

Two pieces to that:

1. free of charge
2. assign w/o consulting the user organization

#1 is something the I think current board of trustees gets wrong. ISPs
usually get the addresses free. They pay a single fee based on the
higher fee for their v4 or v6 allocation and the v4 allocation is
usually higher. End users pay $500+ and an extra $100 per year. $1000+
until recently.

I know this has put people off deploying IPv6 because it has put me
off deploying IPv6 on behalf of four different networks now. One time
the network owner flat-out told me that he had better ways to spend
the money.

Setting the fee to zero until IPv6 is well launched was the foundation
of my unsuccessful candidacy for the board
a couple years ago.

There have been fee discussions in this forum before, but we've been
told in very clear terms that whether or not ARIN charges for IPv6
addresses is off-limits as a number policy matter.


#2 is unworkable without #1 and may be unnecessary if #1 were in place.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From owen at delong.com  Thu Aug 13 17:31:24 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Aug 2015 14:31:24 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1782869989.7058.1439345712136.JavaMail.mhammett@ThunderFuck>
References: <1782869989.7058.1439345712136.JavaMail.mhammett@ThunderFuck>
Message-ID: <40E235B1-B8D8-4D28-AFC0-D8AD8C6F66FE@delong.com>

As an ISP, you pay the higher of the two annual fees, so if your IPv4 is $16,000/year and your IPv6 is $2,000, you pay $16,000.
If your IPv4 is $500/year and your IPv6 is $2,000, you pay $2,000.

Owen

> On Aug 11, 2015, at 19:14 , Mike Hammett <arin at ics-il.net> wrote:
> 
> I had thought that at one point the IPv6 allocation was free for ISPs, but that deal expired at one point and it was now up to us to pay for both allocations. I'm not complaining, just seeking clarification since we're talking about getting IPv6 eligibility, costs, etc.
> 
> 
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com <http://www.ics-il.com/>
> 
>  <https://www.facebook.com/ICSIL> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> <https://www.linkedin.com/company/intelligent-computing-solutions> <https://twitter.com/ICSIL>
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com <http://www.midwest-ix.com/>
> 
>  <https://www.facebook.com/mdwestix> <https://www.linkedin.com/company/midwest-internet-exchange> <https://twitter.com/mdwestix>
> 
> From: "Randy Carpenter" <rcarpen at network1.net>
> To: "Seth Mattinen" <sethm at rollernet.us>
> Cc: arin-ppml at arin.net
> Sent: Tuesday, August 11, 2015 9:11:40 PM
> Subject: Re: [arin-ppml] Automatic IPv6 Eligibility
> 
> 
> ----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen sethm at rollernet.us wrote:
> 
> > On 8/11/15 14:43, Alfie Cleveland wrote:
> >> Hello,
> >>
> >> I?m requesting comment in regards to automatically make organisations
> >> eligible for IPv6 if they hold justified IPv4 space. This similar to
> >> Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
> >> Policies. I feel that if organisations were able to receive a /48 for
> >> each /24 they hold, then it would help expedite the rollout of IPv6.
> >> Organisations currently have two choices - continue to use IPv4, or
> >> spend valuable time on applying for IPv6 space. IPv6 space is clearly in
> >> abundance - and this could potentially help slow the exhaustion of IPv4.
> >>
> > 
> > 
> > I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and I
> > don't remember having to do much to qualify for them other than ask. Has
> > this changed?
> 
> No. If you have IPv4 space already, it is incredibly easy to get IPv6. Getting the default /48 as an end-user is about as automatic as it could be, and qualifying for more is not much more effort if you have multiple sites.
> 
> The only issue is that for end-users, you now have to pay an additional $100 per year for the IPv6 assignment.
> 
> -Randy
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <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.

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

From owen at delong.com  Thu Aug 13 17:35:15 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Aug 2015 14:35:15 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <66A244E4-0916-49B4-983D-BF442B7547F1@ubn.ca>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
	<55CAB149.6010708@cameron.net>
	<66A244E4-0916-49B4-983D-BF442B7547F1@ubn.ca>
Message-ID: <865D8634-AA1D-4E28-854A-8B8C2098F05C@delong.com>


> On Aug 11, 2015, at 19:47 , Tom Samplonius <tsamplonius at ubn.ca> wrote:
> 
> 
>> On Aug 11, 2015, at 7:36 PM, Paul <pmcnary at cameron.net <mailto:pmcnary at cameron.net>> wrote:
>> 
>> Hello
>> 
>> We are getting ready to lose a /22 and /23 and 2 /24's when we switch from microwave data center providers
>> to fiber for our ISP that the data centers have been providing for us since the dial-up days .
>> /22 and /23 are no longer available. Will we have to pay the $100 annual fee on each /24 block allocated
>> even though nothing larger is available? Can we get an IPv6 allocation large enough when we file for AS number
>> for a several month cross over from microwave to fiber?
> 
> 
>   Keep in mind that a IPv6 /32 or /36 are very large blocks in comparison to a /21 worth of IPv4.
> 
>   A /32 allows you to assign a /64 each to about 4 billion customers.

That?s really not a good idea in most cases.

For the most part, you should be assigning /48s to each customer end site. Some customers may have
multiple end sites (more than one building, for example).

Still, a /36 is enough to assign 4096 /48s and a /32 is 65,536 /48s, so they are still significantly larger
than a /21 of IPv4.

Owen


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

From owen at delong.com  Thu Aug 13 17:40:41 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Aug 2015 14:40:41 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <55CACE9F.1060206@cameron.net>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<55CA96BC.6040308@rollernet.us>
	<1902847210.2165.1439345500829.JavaMail.zimbra@network1.net>
	<E0B7D7C5-521B-415B-BDEC-E3460EC65282@rowenetworks.com>
	<DM2PR03MB398F85D519D579C7F5B2D249B7E0@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC4yj2U6bz0r5yXKYY0KY9eZ4K1_oUuFuDikg3jucqMM-Ad3dA@mail.gmail.com>
	<55CACE9F.1060206@cameron.net>
Message-ID: <E7DDBD38-7312-4657-928E-F91FE6C42543@delong.com>

As an ISP, you are billed on your total address holdings, not individual blocks.

So, a /22 and 4 /24s would be billed identically.

ISPs do not pay separate annual fees for ASNs. There is a one time fee for each ASN
the same as end-users (currently $500).

In your example, 4 /24s, a /40, and an ASN, you would pay the greater of $500 (IPv4 /22)
or $500 (IPv6 /40) if you could somehow get a /40.

However, under current policy, the smallest block available to an ISP directly from ARIN
is a /36. A /36 is $1,000 annually, so if you got a /36, your fees would go up to $1,000.
The smallest recommended (and default minimum) is /32, which is currently $2,000.

Owen

> On Aug 11, 2015, at 21:42 , Paul <pmcnary at cameron.net> wrote:
> 
> We are an ISP.
> Will 4 different non-contiguous blocks be counted as 1 or 4 blocks for fees.
> Or is the block count the total of all combined /24's that we would get allocated?
> So a /22 (or 4 /24's)  plus a /40 plus ASN for an ISP would be $500 annually?
> 
> Thanks
> 
> 
> 
> On 8/11/2015 11:22 PM, Jason Schiller wrote:
>> For ISPs a /22 is billed at XX-small at $500 annually.
>> (this includes ASNs and membership vote)
>> 
>> adding up to a /40 keeps the ISP in the XX-small category and does not change the annual fee.
>> 
>> An IPv4 /32 bumps the ISP up to a small with an annual fee of $2,000.  (a $1,500 increase).
>> (If the ISP already had more than a /20 there would be no increase in fees)
>> 
>> 
>> End sites are billed differently 
>> End sites pay $100 per resource.  
>> one /22 costs $100.
>> two /24s cost $200.
>> one /20, two /23s, and two ASNs cost $500 annually.
>> 
>> There is an additional one time fee for new resources based on the size of the resource.
>> 
>> So an end user with one /22 and one ASN the annual fee is $200.
>> 
>> There is a one time initial fee of of $500 for a single block that is a /40 or smaller
>> (this is in addition to the $200 annual fee for IPv4 and ASN) 
>> 
>> The following year the annual fee will go up by $100 for a total of $300.
>> 
>> ___Jason
>> 
>> 
>>  
>> 
>> On Tue, Aug 11, 2015 at 10:35 PM, David Huberman <David.Huberman at microsoft.com <mailto:David.Huberman at microsoft.com>> wrote:
>> Hi Josh, <>
>>  
>> If you have a /21 allocation from ARIN, then you are paying them $1,000 a year in a subscription fee.  That covers your AS number, and your /21, and it gives you membership to vote.
>> 
>>  
>> If you want, you can request a /36 of IPv6 from ARIN, and it will come at no extra charge.  There will be no registration fee, and your annual subscription fee will not change.
>> 
>>  
>> From an engineering perspective, many of us do not recommend that.  We recommend getting the full default prefix size ? a /32 ? and deploying that.   Unfortunately, that will cause your annual subscription fee with ARIN to double to $2,000.  You still won?t pay a registration fee for getting the /32, but when your next annual bill is sent, it will be for $2,000 rather than $1,000.
>> 
>>  
>> Please keep in mind that the only realistic way I know of to get more IPv4 addresses for your new products and customers is via the IPv4 transfer market, and that?s going to cost many, many times more than ARIN charges.  Many tens of thousands of dollars, probably, depending on what you want to get.   You may wish to balance the cost of obtaining more IPv4 addresses in the market with what revenue opportunities those addresses represent, then factor in how you can (or cannot) leverage IPv6 to make those numbers work better for you.  Just a suggestion, and sorry if I?m overstepping.
>> 
>>  
>> David
>> 
>>  
>> David R Huberman
>> Principal, Global IP Addressing
>> 
>> Microsoft Corporation
>> 
>>  
>> From:  <mailto:arin-ppml-bounces at arin.net>arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>] On Behalf Of josh at rowenetworks.com <mailto:josh at rowenetworks.com>
>> Sent: Tuesday, August 11, 2015 7:29 PM
>> To: arin-ppml at arin.net <mailto:arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] Automatic IPv6 Eligibility
>> 
>>  
>> Well here's my scenario. My ISP is in the process of acquiring another ISP, I wrote into arin for advice of how to go about requesting additional ip space as the acquisition will take more IP addresses then what we have left out of our current /21 allotment.
>> 
>> 
>> 
>> I was advised to apply asap however with the depletion procedures/protocols it didn't seem likely to quickly be able to get enough blocks from the free pool.
>> 
>> If an existing service provider such as myself would be able to get a free ipv6 allocation I would agree it would help transition to ipv6 faster as I need more IPs for my customers, infrastructure, etc. 
>> 
>> I'd at least be more willing to try to make it work for my customer ip space since there would be little or no cost involved, now the problem that remains is the equipment compatibility and third party support of ipv6.
>> 
>> Is it possible to still get a block to use for my ISP for $100/yr? 
>> 
>> Best Regards,
>> Josh Rowe 
>> 
>> On August 11, 2015 10:11:40 PM EDT, Randy Carpenter < <mailto:rcarpen at network1.net>rcarpen at network1.net <mailto:rcarpen at network1.net>> wrote:
>> 
>> ----- On Aug 11, 2015, at 8:43 PM, Seth Mattinen sethm at rollernet.us <mailto:sethm at rollernet.us> wrote:
>>  On 8/11/15 14:43, Alfie Cleveland wrote:
>>  Hello,
>> 
>>  I?m requesting comment in regards to automatically make organisations
>>  eligible for IPv6 if they hold justified IPv4 space. This similar to
>>  Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource
>>  Policies. I feel that if organisations were able to receive a /48 for
>>  each /24 they hold, then it would help expedite the rollout of IPv6.
>>  Organisations currently have two choices - continue to use IPv4, or
>>  spend valuable time on applying for IPv6 space. IPv6 space is clearly in
>>  abundance - and this could potentially help slo
>>  w the
>> exhaustion of IPv4.
>>  
>>  
>>  I got my /32 IPv6 allocation in late 2009 and end user /48 in 2007 and I
>>  don't remember having to do much to qualify for them other than ask. Has
>>  this changed?
>> No. If you have IPv4 space already, it is incredibly easy to get IPv6. Getting the default /48 as an end-user is about as automatic as it could be, and qualifying for more is not much more effort if you have multiple sites.
>> 
>> The only issue is that for end-users, you now have to pay an additional $100 per year for the IPv6 assignment.
>> 
>> -Randy
>> 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 <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7cda43505669344383a23b08d2a2bdd610%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8tB7qrXRyzQxkxErQNddayFfecqCmrp54AhlO7IzCkE%3d>
>> Please contact info at arin.net <mailto:info at arin.net> if you experi
>>  ence
>> any issues.
>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> 
>> _______________________________________________ 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.
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com>|571-266-0006
>>  
>> _______________________________________________
>> 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.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20150813/5b0a0669/attachment.htm>

From JOHN at egh.com  Thu Aug 13 18:59:56 2015
From: JOHN at egh.com (John Santos)
Date: Thu, 13 Aug 2015 18:59:56 -0400
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <865D8634-AA1D-4E28-854A-8B8C2098F05C@delong.com>
Message-ID: <1150813185048.15789A-100000@joonya.egh.com>


Maybe off-topic, but the recommendation for assigning a /48 to each of
the ISP's customers...  Does that apply only to business customers 
and organizations, etc., or does it also apply to residential customers?
Why would a residence (unless they're network hackers like most of us)
ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious 
use case for people subnetting their house or appartment :-)

I'm sure this has been discussed to death here and elsewhere.  I've not
yet been involved in any large-scale IPv6 deployments (just our lone LAN
that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
connectivity), so I'm trying to internalize IPv6 best practices before
screwing up too badly.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

From ikiris at gmail.com  Thu Aug 13 19:08:50 2015
From: ikiris at gmail.com (Blake Dunlap)
Date: Thu, 13 Aug 2015 16:08:50 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813185048.15789A-100000@joonya.egh.com>
References: <865D8634-AA1D-4E28-854A-8B8C2098F05C@delong.com>
	<1150813185048.15789A-100000@joonya.egh.com>
Message-ID: <CAJvB4tkxH-qhz+u64qherDwjE2B9CDBs+oNSo0XWZ=bVdOmkyg@mail.gmail.com>

Everyone. Automatic prefix delegation for multiple home subnets by devices.

On Thu, Aug 13, 2015 at 3:59 PM, John Santos <JOHN at egh.com> wrote:
>
> Maybe off-topic, but the recommendation for assigning a /48 to each of
> the ISP's customers...  Does that apply only to business customers
> and organizations, etc., or does it also apply to residential customers?
> Why would a residence (unless they're network hackers like most of us)
> ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious
> use case for people subnetting their house or appartment :-)
>
> I'm sure this has been discussed to death here and elsewhere.  I've not
> yet been involved in any large-scale IPv6 deployments (just our lone LAN
> that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
> connectivity), so I'm trying to internalize IPv6 best practices before
> screwing up too badly.
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 rgrant at skywaywest.com  Thu Aug 13 19:10:28 2015
From: rgrant at skywaywest.com (Ron Grant)
Date: Thu, 13 Aug 2015 16:10:28 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813185048.15789A-100000@joonya.egh.com>
References: <1150813185048.15789A-100000@joonya.egh.com>
Message-ID: <677F2D59-1C32-4C85-83BC-1EBC291AB554@skywaywest.com>

A /56 has been suggested as a residential allocation, which is what we're doing. I think it's also sufficient for a "business suite" - I.e. One office in a multi-office building.

> On Aug 13, 2015, at 3:59 PM, John Santos <JOHN at egh.com> wrote:
> 
> 
> Maybe off-topic, but the recommendation for assigning a /48 to each of
> the ISP's customers...  Does that apply only to business customers 
> and organizations, etc., or does it also apply to residential customers?
> Why would a residence (unless they're network hackers like most of us)
> ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious 
> use case for people subnetting their house or appartment :-)
> 
> I'm sure this has been discussed to death here and elsewhere.  I've not
> yet been involved in any large-scale IPv6 deployments (just our lone LAN
> that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
> connectivity), so I'm trying to internalize IPv6 best practices before
> screwing up too badly.
> 
> -- 
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From arin at ics-il.net  Thu Aug 13 19:11:43 2015
From: arin at ics-il.net (Mike Hammett)
Date: Thu, 13 Aug 2015 18:11:43 -0500 (CDT)
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813185048.15789A-100000@joonya.egh.com>
Message-ID: <1594200774.4395.1439507506927.JavaMail.mhammett@ThunderFuck>

It's a fantasy world where every thought has its own subnet. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "John Santos" <JOHN at egh.com> 
To: "Owen DeLong" <owen at delong.com> 
Cc: arin-ppml at arin.net 
Sent: Thursday, August 13, 2015 5:59:56 PM 
Subject: Re: [arin-ppml] Automatic IPv6 Eligibility 


Maybe off-topic, but the recommendation for assigning a /48 to each of 
the ISP's customers... Does that apply only to business customers 
and organizations, etc., or does it also apply to residential customers? 
Why would a residence (unless they're network hackers like most of us) 
ever need more than a /64, let alone 2^16 /64's? I don't see any obvious 
use case for people subnetting their house or appartment :-) 

I'm sure this has been discussed to death here and elsewhere. I've not 
yet been involved in any large-scale IPv6 deployments (just our lone LAN 
that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6 
connectivity), so I'm trying to internalize IPv6 best practices before 
screwing up too badly. 

-- 
John Santos 
Evans Griffiths & Hart, Inc. 
781-861-0670 ext 539 

_______________________________________________ 
PPML 
You are receiving this message because you are subscribed to 
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). 
Unsubscribe or manage 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/20150813/1d8b6730/attachment.htm>

From hvgeekwtrvl at gmail.com  Thu Aug 13 19:15:18 2015
From: hvgeekwtrvl at gmail.com (james machado)
Date: Thu, 13 Aug 2015 16:15:18 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813185048.15789A-100000@joonya.egh.com>
References: <865D8634-AA1D-4E28-854A-8B8C2098F05C@delong.com>
	<1150813185048.15789A-100000@joonya.egh.com>
Message-ID: <CADVasu4JVLiHfJOu3Xg=3GAixwoq32_Bb6_hWQCW32Qa9Maiog@mail.gmail.com>

John,

A /64 is just one network.  Arguments have been made that a smart
phone "needs" multiple /64's just to run IPv6 much less a "site" or
building.  The current fight is between a /56 and a /48 for each
customer as internal networking in v6 is going to happen.  Much
discussion has been happening on both Nanog and IPv6-ops mailing
lists.

James

On Thu, Aug 13, 2015 at 3:59 PM, John Santos <JOHN at egh.com> wrote:
>
> Maybe off-topic, but the recommendation for assigning a /48 to each of
> the ISP's customers...  Does that apply only to business customers
> and organizations, etc., or does it also apply to residential customers?
> Why would a residence (unless they're network hackers like most of us)
> ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious
> use case for people subnetting their house or appartment :-)
>
> I'm sure this has been discussed to death here and elsewhere.  I've not
> yet been involved in any large-scale IPv6 deployments (just our lone LAN
> that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
> connectivity), so I'm trying to internalize IPv6 best practices before
> screwing up too badly.
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 rjletts at uw.edu  Thu Aug 13 19:17:42 2015
From: rjletts at uw.edu (Richard J. Letts)
Date: Thu, 13 Aug 2015 23:17:42 +0000
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813185048.15789A-100000@joonya.egh.com>
References: <865D8634-AA1D-4E28-854A-8B8C2098F05C@delong.com>
	<1150813185048.15789A-100000@joonya.egh.com>
Message-ID: <SN1PR08MB1823FFD35BB4480D1011F275C07D0@SN1PR08MB1823.namprd08.prod.outlook.com>

Comcast gives their customers a /60 -- 16 -- which should be enough for almost all home users

Personally, I use four at home:
Wireless has two (guest SSID + my SSID)
Wired has two (guest room wired ports + home wired network)

Richard Letts

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of John Santos
> Sent: 13 August 2015 4:00 PM
> To: Owen DeLong <owen at delong.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Automatic IPv6 Eligibility
> 
> 
> Maybe off-topic, but the recommendation for assigning a /48 to each of the
> ISP's customers...  Does that apply only to business customers and
> organizations, etc., or does it also apply to residential customers?
> Why would a residence (unless they're network hackers like most of us)
> ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious
> use case for people subnetting their house or appartment :-)
> 
> I'm sure this has been discussed to death here and elsewhere.  I've not
> yet been involved in any large-scale IPv6 deployments (just our lone LAN
> that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
> connectivity), so I'm trying to internalize IPv6 best practices before
> screwing up too badly.
> 
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539


From David.Huberman at microsoft.com  Thu Aug 13 19:21:09 2015
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 13 Aug 2015 23:21:09 +0000
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <CADVasu4JVLiHfJOu3Xg=3GAixwoq32_Bb6_hWQCW32Qa9Maiog@mail.gmail.com>
References: <865D8634-AA1D-4E28-854A-8B8C2098F05C@delong.com>
	<1150813185048.15789A-100000@joonya.egh.com>,
	<CADVasu4JVLiHfJOu3Xg=3GAixwoq32_Bb6_hWQCW32Qa9Maiog@mail.gmail.com>
Message-ID: <DM2PR03MB39865A01EFC77B7745852809B7D0@DM2PR03MB398.namprd03.prod.outlook.com>

ARIN does sparse allocation, where every /32 has 15 more /32s reserved for you (a /28).   Since almost no one really knows what they're doing yet (in my opinion; it's all first generation greenfield deployments we are doing), I say go ahead and give a /48 to each customer and re evaluate in the future when you have more data.  Being liberal with customers is better for them than being overly stingy. And you aren't harming the "free pool" since the first /32 is one sixteenth of what is already held for you.

Sent using OWA for iPhone
________________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of james machado <hvgeekwtrvl at gmail.com>
Sent: Thursday, August 13, 2015 4:15:18 PM
To: John Santos; arin-ppml at arin.net
Subject: Re: [arin-ppml] Automatic IPv6 Eligibility

John,

A /64 is just one network.  Arguments have been made that a smart
phone "needs" multiple /64's just to run IPv6 much less a "site" or
building.  The current fight is between a /56 and a /48 for each
customer as internal networking in v6 is going to happen.  Much
discussion has been happening on both Nanog and IPv6-ops mailing
lists.

James

On Thu, Aug 13, 2015 at 3:59 PM, John Santos <JOHN at egh.com> wrote:
>
> Maybe off-topic, but the recommendation for assigning a /48 to each of
> the ISP's customers...  Does that apply only to business customers
> and organizations, etc., or does it also apply to residential customers?
> Why would a residence (unless they're network hackers like most of us)
> ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious
> use case for people subnetting their house or appartment :-)
>
> I'm sure this has been discussed to death here and elsewhere.  I've not
> yet been involved in any large-scale IPv6 deployments (just our lone LAN
> that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
> connectivity), so I'm trying to internalize IPv6 best practices before
> screwing up too badly.
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c06e8fab9a69144071e9a08d2a4351821%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VernkETOP5Y%2bDrncl9%2f4WwqYm6eBqjiAZvlTa4M0Mx4%3d
> 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:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c06e8fab9a69144071e9a08d2a4351821%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VernkETOP5Y%2bDrncl9%2f4WwqYm6eBqjiAZvlTa4M0Mx4%3d
Please contact info at arin.net if you experience any issues.


From bill at herrin.us  Thu Aug 13 19:41:13 2015
From: bill at herrin.us (William Herrin)
Date: Thu, 13 Aug 2015 19:41:13 -0400
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813185048.15789A-100000@joonya.egh.com>
References: <865D8634-AA1D-4E28-854A-8B8C2098F05C@delong.com>
	<1150813185048.15789A-100000@joonya.egh.com>
Message-ID: <CAP-guGUEjB97iBwH0nhGUZZ6WDTAop1t22V2yKz6kf01qjRptw@mail.gmail.com>

On Thu, Aug 13, 2015 at 6:59 PM, John Santos <JOHN at egh.com> wrote:
> Maybe off-topic, but the recommendation for assigning a /48 to each of
> the ISP's customers...  Does that apply only to business customers
> and organizations, etc., or does it also apply to residential customers?

Hi John,

It has been discussed to death. Here's a summary of the results:

/48 to business customers by default: strong consensus
/48 to all customers by default: IETF likes. Owen likes. Healthy mix of others.
/56 to residential customers by default: I like. Healthy mix of others.
Never less than a /60 to any external customer (not /128, not /64):
strong consensus
Always on a nibble boundary (mask divisible by 4): strong consensus

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From farmer at umn.edu  Thu Aug 13 19:45:02 2015
From: farmer at umn.edu (David Farmer)
Date: Thu, 13 Aug 2015 18:45:02 -0500
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813185048.15789A-100000@joonya.egh.com>
References: <1150813185048.15789A-100000@joonya.egh.com>
Message-ID: <08696A50-12B6-4137-BF31-9D7A91EDB18D@umn.edu>


I'm not going to tell what you size you should give your customers, you should determine that for yourself.  But others on this thread have suggested /48, /56, and /60, those all seem reasonable to me depending on the situation.  What I will beg you, do not limit your customers to a single /64 subnet in there homes.  There are many valid reason to have more than one subnet in a home, easiest example is a separate Guest WiFi subnet.

See the following for way more details;
https://tools.ietf.org/html/rfc7421
https://tools.ietf.org/html/rfc7368
https://tools.ietf.org/html/rfc6177

Hope that helps.

> On Aug 13, 2015, at 17:59, John Santos <JOHN at egh.com> wrote:
> 
> Maybe off-topic, but the recommendation for assigning a /48 to each of
> the ISP's customers...  Does that apply only to business customers 
> and organizations, etc., or does it also apply to residential customers?
> Why would a residence (unless they're network hackers like most of us)
> ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious 
> use case for people subnetting their house or appartment :-)
> 
> I'm sure this has been discussed to death here and elsewhere.  I've not
> yet been involved in any large-scale IPv6 deployments (just our lone LAN
> that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
> connectivity), so I'm trying to internalize IPv6 best practices before
> screwing up too badly.
> 
> -- 
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539

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



From rgrant at skywaywest.com  Thu Aug 13 19:47:21 2015
From: rgrant at skywaywest.com (Ron Grant)
Date: Thu, 13 Aug 2015 16:47:21 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <CAP-guGUEjB97iBwH0nhGUZZ6WDTAop1t22V2yKz6kf01qjRptw@mail.gmail.com>
References: <865D8634-AA1D-4E28-854A-8B8C2098F05C@delong.com>
	<1150813185048.15789A-100000@joonya.egh.com>
	<CAP-guGUEjB97iBwH0nhGUZZ6WDTAop1t22V2yKz6kf01qjRptw@mail.gmail.com>
Message-ID: <55CD2C89.9040103@skywaywest.com>

Based on that new nibble of info about ARIN "sparse allocating", I would 
probably bump my "default smallest" alloc from /56 to /48. Makes things 
so much easier - almost like classful routing!!! Anyone remember that, 
or am I dating myself? :-)



On 2015-08-13 4:41 PM, William Herrin wrote:
> On Thu, Aug 13, 2015 at 6:59 PM, John Santos <JOHN at egh.com> wrote:
>> Maybe off-topic, but the recommendation for assigning a /48 to each of
>> the ISP's customers...  Does that apply only to business customers
>> and organizations, etc., or does it also apply to residential customers?
> Hi John,
>
> It has been discussed to death. Here's a summary of the results:
>
> /48 to business customers by default: strong consensus
> /48 to all customers by default: IETF likes. Owen likes. Healthy mix of others.
> /56 to residential customers by default: I like. Healthy mix of others.
> Never less than a /60 to any external customer (not /128, not /64):
> strong consensus
> Always on a nibble boundary (mask divisible by 4): strong consensus
>
> Regards,
> Bill Herrin
>
>

-- 
Ron Grant                                Managed DSL/T1/Wireless/Fibre
Skyway West Business Internet          Internet and Private Networking
rgrant at skywaywest.com                  Bonding and Fail Over Solutions
ph:  604 737 2113               Virtual Data Centre and Private Clouds
fax: 604 482 1299                            http://www.skywaywest.com

Sales, Support and Billing    http://www.skywaywest.com/contact-us.htm

ca.linkedin.com/in/obiron



From JOHN at egh.com  Thu Aug 13 19:49:19 2015
From: JOHN at egh.com (John Santos)
Date: Thu, 13 Aug 2015 19:49:19 -0400
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <DM2PR03MB39865A01EFC77B7745852809B7D0@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <1150813193959.31908A-100000@joonya.egh.com>


Sounds like "no one knows yet, so lets not shoot ourselves in the foot
by underallocating prematurely"

Would it make more sense to allocate a smaller chunk, but sparsely?  If it
turns out the smaller chunk suffices (e.g. a /60* is more than almost
anyone needs), then the remaing 15 /60s** can be allocated to other
users, but if everyone really needs a /56, the existing allocations
can be bumped up in place (no renumbering, just access to a larger block.)

Or is 64 bits so huge that the mind can't cope and everyone really does
need a /48 for home use and this won't force IPv7(?) with 512-bit addresses
before anyone suspects?

Does every proton in the universe need its own subnet?


* or a /56 or whatever

** or the remaining 254 /56's as the case may be



On Thu, 13 Aug 2015, David Huberman wrote:

> ARIN does sparse allocation, where every /32 has 15 more /32s reserved for you (a /28).   Since almost no one really knows what they're doing yet (in my opinion; it's all first generation greenfield deployments we are doing), I say go ahead and give a /48 to each customer and re evaluate in the future when you have more data.  Being liberal with customers is better for them than being overly stingy. And you aren't harming the "free pool" since the first /32 is one sixteenth of what is already held for you.
> 
> Sent using OWA for iPhone
> ________________________________________
> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of james machado <hvgeekwtrvl at gmail.com>
> Sent: Thursday, August 13, 2015 4:15:18 PM
> To: John Santos; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Automatic IPv6 Eligibility
> 
> John,
> 
> A /64 is just one network.  Arguments have been made that a smart
> phone "needs" multiple /64's just to run IPv6 much less a "site" or
> building.  The current fight is between a /56 and a /48 for each
> customer as internal networking in v6 is going to happen.  Much
> discussion has been happening on both Nanog and IPv6-ops mailing
> lists.
> 
> James
> 
> On Thu, Aug 13, 2015 at 3:59 PM, John Santos <JOHN at egh.com> wrote:
> >
> > Maybe off-topic, but the recommendation for assigning a /48 to each of
> > the ISP's customers...  Does that apply only to business customers
> > and organizations, etc., or does it also apply to residential customers?
> > Why would a residence (unless they're network hackers like most of us)
> > ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious
> > use case for people subnetting their house or appartment :-)
> >
> > I'm sure this has been discussed to death here and elsewhere.  I've not
> > yet been involved in any large-scale IPv6 deployments (just our lone LAN
> > that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
> > connectivity), so I'm trying to internalize IPv6 best practices before
> > screwing up too badly.
> >
> > --
> > John Santos
> > Evans Griffiths & Hart, Inc.
> > 781-861-0670 ext 539
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c06e8fab9a69144071e9a08d2a4351821%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VernkETOP5Y%2bDrncl9%2f4WwqYm6eBqjiAZvlTa4M0Mx4%3d
> > 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:
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c06e8fab9a69144071e9a08d2a4351821%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VernkETOP5Y%2bDrncl9%2f4WwqYm6eBqjiAZvlTa4M0Mx4%3d
> Please contact info at arin.net if you experience any issues.
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From JOHN at egh.com  Thu Aug 13 19:50:39 2015
From: JOHN at egh.com (John Santos)
Date: Thu, 13 Aug 2015 19:50:39 -0400
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <CAP-guGUEjB97iBwH0nhGUZZ6WDTAop1t22V2yKz6kf01qjRptw@mail.gmail.com>
Message-ID: <1150813195008.31908A-100000@joonya.egh.com>


Thanks Bill (and everyone else) for indulging me.

On Thu, 13 Aug 2015, William Herrin wrote:

> On Thu, Aug 13, 2015 at 6:59 PM, John Santos <JOHN at egh.com> wrote:
> > Maybe off-topic, but the recommendation for assigning a /48 to each of
> > the ISP's customers...  Does that apply only to business customers
> > and organizations, etc., or does it also apply to residential customers?
> 
> Hi John,
> 
> It has been discussed to death. Here's a summary of the results:
> 
> /48 to business customers by default: strong consensus
> /48 to all customers by default: IETF likes. Owen likes. Healthy mix of others.
> /56 to residential customers by default: I like. Healthy mix of others.
> Never less than a /60 to any external customer (not /128, not /64):
> strong consensus
> Always on a nibble boundary (mask divisible by 4): strong consensus
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From mcr at sandelman.ca  Thu Aug 13 20:32:55 2015
From: mcr at sandelman.ca (mcr at sandelman.ca)
Date: Thu, 13 Aug 2015 20:32:55 -0400
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813185048.15789A-100000@joonya.egh.com>
References: <1150813185048.15789A-100000@joonya.egh.com>
Message-ID: <9499.1439512375@sandelman.ca>


John Santos <JOHN at egh.com> wrote:
    > Maybe off-topic, but the recommendation for assigning a /48 to each of
    > the ISP's customers...  Does that apply only to business customers and
    > organizations, etc., or does it also apply to residential customers?
    > Why would a residence (unless they're network hackers like most of us)
    > ever need more than a /64, let alone 2^16 /64's?  I don't see any

Because residents will have multiple subnets, please see IETF Homenet WG.
A minimum of a /60 from each ISP is acceptable, but a /56 is recommended.



From owen at delong.com  Thu Aug 13 23:10:57 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Aug 2015 20:10:57 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813185048.15789A-100000@joonya.egh.com>
References: <1150813185048.15789A-100000@joonya.egh.com>
Message-ID: <95D3C2C3-165A-4E02-AA81-2B2931EEF975@delong.com>


> On Aug 13, 2015, at 15:59 , John Santos <JOHN at egh.com> wrote:
> 
> 
> Maybe off-topic, but the recommendation for assigning a /48 to each of
> the ISP's customers...  Does that apply only to business customers 
> and organizations, etc., or does it also apply to residential customers?
> Why would a residence (unless they're network hackers like most of us)
> ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious 
> use case for people subnetting their house or appartment :-)

I believe it applies universally to all end sites, including residential customers.

I?m running a /48 in my home.

The question you are asking reflects a vision of the household as it is today.
A relatively flat network with a few devices on it.

The reality of tomorrow is going to be quite different. We don?t know exactly
what it will be. By giving residential end-users /48s, we have very near zero
risk of running out of IPv6 addresses (this has been rehashed many times
in many fora) and yet we allow for quite a bit of latitude for innovation in home
networking.

In the future, lots of things that aren?t routers today will, in fact, likely be routers
and they will likely create subnets behind them. This is one of the reasons to
have DHCP-PD.

> I'm sure this has been discussed to death here and elsewhere.  I've not
> yet been involved in any large-scale IPv6 deployments (just our lone LAN
> that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
> connectivity), so I'm trying to internalize IPv6 best practices before
> screwing up too badly.

Do not make the mistake of engineering your IPv6 deployment to only meet your
past or present needs, but instead design it to be flexible and ready to meet
your future needs as well.

Owen



From owen at delong.com  Thu Aug 13 23:17:40 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Aug 2015 20:17:40 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <55CD2C89.9040103@skywaywest.com>
References: <865D8634-AA1D-4E28-854A-8B8C2098F05C@delong.com>
	<1150813185048.15789A-100000@joonya.egh.com>
	<CAP-guGUEjB97iBwH0nhGUZZ6WDTAop1t22V2yKz6kf01qjRptw@mail.gmail.com>
	<55CD2C89.9040103@skywaywest.com>
Message-ID: <DEF4B5CB-1FDB-4616-BCEE-DC9B8C40D4AD@delong.com>

Also consider this?

Your ability to get additional space from ARIN is tied to the smallest block size
you give out to customers by default?

From NRPM:

2.15. Provider Assignment Unit (IPv6)

When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48).
6.5.2.1. Size
All allocations shall be made on nibble boundaries. 
In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. In no case shall an ISP receive more than a /16 initial allocation. 
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 = P-(X+Y) and P is the organization's Provider Allocation Unit 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.
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. 
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. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. 
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.


So it is worth noting that if you hand out /56 to residential customers, when you go back to ARIN for more for your business customers, you?re going to have to explain why each and every business you gave a /48 to needed 256 /56s instead of being able to just say ?I gave out X /48s?.

OTOH, if you just give out /48s to everyone, life is good and you can just go back to ARIN with ?I gave out x /48s? no questions asked (about various sizes of subnets).

Owen


> On Aug 13, 2015, at 16:47 , Ron Grant <rgrant at skywaywest.com> wrote:
> 
> Based on that new nibble of info about ARIN "sparse allocating", I would probably bump my "default smallest" alloc from /56 to /48. Makes things so much easier - almost like classful routing!!! Anyone remember that, or am I dating myself? :-)
> 
> 
> 
> On 2015-08-13 4:41 PM, William Herrin wrote:
>> On Thu, Aug 13, 2015 at 6:59 PM, John Santos <JOHN at egh.com> wrote:
>>> Maybe off-topic, but the recommendation for assigning a /48 to each of
>>> the ISP's customers...  Does that apply only to business customers
>>> and organizations, etc., or does it also apply to residential customers?
>> Hi John,
>> 
>> It has been discussed to death. Here's a summary of the results:
>> 
>> /48 to business customers by default: strong consensus
>> /48 to all customers by default: IETF likes. Owen likes. Healthy mix of others.
>> /56 to residential customers by default: I like. Healthy mix of others.
>> Never less than a /60 to any external customer (not /128, not /64):
>> strong consensus
>> Always on a nibble boundary (mask divisible by 4): strong consensus
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
> 
> -- 
> Ron Grant                                Managed DSL/T1/Wireless/Fibre
> Skyway West Business Internet          Internet and Private Networking
> rgrant at skywaywest.com <mailto:rgrant at skywaywest.com>                  Bonding and Fail Over Solutions
> ph:  604 737 2113               Virtual Data Centre and Private Clouds
> fax: 604 482 1299                            http://www.skywaywest.com <http://www.skywaywest.com/>
> 
> Sales, Support and Billing    http://www.skywaywest.com/contact-us.htm <http://www.skywaywest.com/contact-us.htm>
> 
> ca.linkedin.com/in/obiron <http://ca.linkedin.com/in/obiron>
> 
> _______________________________________________
> 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.

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

From owen at delong.com  Thu Aug 13 23:20:35 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 13 Aug 2015 20:20:35 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <1150813193959.31908A-100000@joonya.egh.com>
References: <1150813193959.31908A-100000@joonya.egh.com>
Message-ID: <8E07183E-47A8-4605-A8D7-6602A34A8ADD@delong.com>

Not really? If you?re going to allocate smaller chunks, allocate sparsely, but that?s still
harmful in my opinion.

Developers will always develop to the lowest common denominator of home networking.

For example, I don?t run NAT at home for IPv4 (with a couple of minor exceptions for testing).

All of my internet-facing devices (including several desktops, audio amplifiers, TiVO, etc.) have
unique public IPv4 addresses.

There isn?t an application on the planet for any of these home media devices that can even
comprehend the basic idea of being able to reach the device directly rather than going through
some sort of polled rendezvous point to get past the NAT.

If we deploy small networks in a significant number of places, then that?s what developers
will develop for and innovation will again be stifled by arbitrary limitations that are unnecessary.

Owen

> On Aug 13, 2015, at 16:49 , John Santos <JOHN at egh.com> wrote:
> 
> 
> Sounds like "no one knows yet, so lets not shoot ourselves in the foot
> by underallocating prematurely"
> 
> Would it make more sense to allocate a smaller chunk, but sparsely?  If it
> turns out the smaller chunk suffices (e.g. a /60* is more than almost
> anyone needs), then the remaing 15 /60s** can be allocated to other
> users, but if everyone really needs a /56, the existing allocations
> can be bumped up in place (no renumbering, just access to a larger block.)
> 
> Or is 64 bits so huge that the mind can't cope and everyone really does
> need a /48 for home use and this won't force IPv7(?) with 512-bit addresses
> before anyone suspects?
> 
> Does every proton in the universe need its own subnet?
> 
> 
> * or a /56 or whatever
> 
> ** or the remaining 254 /56's as the case may be
> 
> 
> 
> On Thu, 13 Aug 2015, David Huberman wrote:
> 
>> ARIN does sparse allocation, where every /32 has 15 more /32s reserved for you (a /28).   Since almost no one really knows what they're doing yet (in my opinion; it's all first generation greenfield deployments we are doing), I say go ahead and give a /48 to each customer and re evaluate in the future when you have more data.  Being liberal with customers is better for them than being overly stingy. And you aren't harming the "free pool" since the first /32 is one sixteenth of what is already held for you.
>> 
>> Sent using OWA for iPhone
>> ________________________________________
>> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of james machado <hvgeekwtrvl at gmail.com>
>> Sent: Thursday, August 13, 2015 4:15:18 PM
>> To: John Santos; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Automatic IPv6 Eligibility
>> 
>> John,
>> 
>> A /64 is just one network.  Arguments have been made that a smart
>> phone "needs" multiple /64's just to run IPv6 much less a "site" or
>> building.  The current fight is between a /56 and a /48 for each
>> customer as internal networking in v6 is going to happen.  Much
>> discussion has been happening on both Nanog and IPv6-ops mailing
>> lists.
>> 
>> James
>> 
>> On Thu, Aug 13, 2015 at 3:59 PM, John Santos <JOHN at egh.com> wrote:
>>> 
>>> Maybe off-topic, but the recommendation for assigning a /48 to each of
>>> the ISP's customers...  Does that apply only to business customers
>>> and organizations, etc., or does it also apply to residential customers?
>>> Why would a residence (unless they're network hackers like most of us)
>>> ever need more than a /64, let alone 2^16 /64's?  I don't see any obvious
>>> use case for people subnetting their house or appartment :-)
>>> 
>>> I'm sure this has been discussed to death here and elsewhere.  I've not
>>> yet been involved in any large-scale IPv6 deployments (just our lone LAN
>>> that easily fits in a IPv4 /24, and doesn't yet have any off-site IPv6
>>> connectivity), so I'm trying to internalize IPv6 best practices before
>>> screwing up too badly.
>>> 
>>> --
>>> John Santos
>>> Evans Griffiths & Hart, Inc.
>>> 781-861-0670 ext 539
>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c06e8fab9a69144071e9a08d2a4351821%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VernkETOP5Y%2bDrncl9%2f4WwqYm6eBqjiAZvlTa4M0Mx4%3d
>>> 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:
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&data=01%7c01%7cdavid.huberman%40microsoft.com%7c06e8fab9a69144071e9a08d2a4351821%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=VernkETOP5Y%2bDrncl9%2f4WwqYm6eBqjiAZvlTa4M0Mx4%3d
>> Please contact info at arin.net if you experience any issues.
>> 
> 
> -- 
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
> 
> _______________________________________________
> 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.

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

From narten at us.ibm.com  Fri Aug 14 00:53:03 2015
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 14 Aug 2015 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201508140453.t7E4r3Rf006085@rotala.raleigh.ibm.com>

Total of 37 messages in the last 7 days.
 
script run at: Fri Aug 14 00:53:03 EDT 2015
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 16.22% |    6 | 28.98% |   162401 | owen at delong.com
  8.11% |    3 | 14.16% |    79343 | arin at ics-il.net
  5.41% |    2 |  8.17% |    45797 | pmcnary at cameron.net
  5.41% |    2 |  7.36% |    41272 | david.huberman at microsoft.com
  5.41% |    2 |  6.57% |    36793 | josh at rowenetworks.com
  8.11% |    3 |  3.78% |    21173 | john at egh.com
  5.41% |    2 |  3.78% |    21159 | jcurran at arin.net
  5.41% |    2 |  3.60% |    20156 | alfeh at me.com
  5.41% |    2 |  2.67% |    14962 | bill at herrin.us
  5.41% |    2 |  2.42% |    13552 | rgrant at skywaywest.com
  2.70% |    1 |  4.61% |    25849 | jschiller at google.com
  2.70% |    1 |  1.91% |    10709 | tsamplonius at ubn.ca
  2.70% |    1 |  1.90% |    10667 | rjletts at uw.edu
  2.70% |    1 |  1.57% |     8816 | matthew at matthew.at
  2.70% |    1 |  1.52% |     8510 | farmer at umn.edu
  2.70% |    1 |  1.28% |     7150 | hvgeekwtrvl at gmail.com
  2.70% |    1 |  1.23% |     6883 | ikiris at gmail.com
  2.70% |    1 |  1.20% |     6737 | rcarpen at network1.net
  2.70% |    1 |  1.18% |     6621 | narten at us.ibm.com
  2.70% |    1 |  1.11% |     6201 | sethm at rollernet.us
  2.70% |    1 |  1.01% |     5680 | mcr at sandelman.ca
--------+------+--------+----------+------------------------
100.00% |   37 |100.00% |   560431 | Total



From arin at ics-il.net  Fri Aug 14 06:19:07 2015
From: arin at ics-il.net (Mike Hammett)
Date: Fri, 14 Aug 2015 05:19:07 -0500 (CDT)
Subject: [arin-ppml] Smalest ISP v6 Allocation
In-Reply-To: <101474537.5026.1439547480262.JavaMail.mhammett@ThunderFuck>
Message-ID: <1674814592.5031.1439547552116.JavaMail.mhammett@ThunderFuck>

If the smallest IPv6 allocation an ISP can get is a /36 (X-small or up to /20 in IPv4), but we have a fee established for XX-small (up to /40 IPv6 and /22 IPv4), why don't we permit an ISP to get a /40? Small providers may not want to increase their ARIN fees to simply be able to get their own IPv6 allocation. Seems counter-intuitive in getting everyone on the IPv6 train. It also falls on a clean boundary, so there shouldn't be any concerns with issued subnets. 

If there's no good reason why we're not doing this, how to we start the process to allow this? 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From farmer at umn.edu  Fri Aug 14 09:13:26 2015
From: farmer at umn.edu (David Farmer)
Date: Fri, 14 Aug 2015 08:13:26 -0500
Subject: [arin-ppml] Smalest ISP v6 Allocation
In-Reply-To: <1674814592.5031.1439547552116.JavaMail.mhammett@ThunderFuck>
References: <1674814592.5031.1439547552116.JavaMail.mhammett@ThunderFuck>
Message-ID: <F6260B47-EF4A-4FDC-9359-2307F72FFDFB@umn.edu>


> On Aug 14, 2015, at 05:19, Mike Hammett <arin at ics-il.net> wrote:
> 
> If the smallest IPv6 allocation an ISP can get is a /36 (X-small or up to /20 in IPv4), but we have a fee established for XX-small (up to /40 IPv6 and /22 IPv4), why don't we permit an ISP to get a /40? Small providers may not want to increase their ARIN fees to simply be able to get their own IPv6 allocation. Seems counter-intuitive in getting everyone on the IPv6 train. It also falls on a clean boundary, so there shouldn't be any concerns with issued subnets.
> 
> If there's no good reason why we're not doing this, how to we start the process to allow this?

A little more than two years ago we considered a policy to do just that;

Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
https://www.arin.net/policy/proposals/2013_3.html

The consensus at the time was that a /40 was too small for an ISP and that we should reconsider the fee structure instead.  That has been in process with the fee committee that was discussed previously.  However, if there is a new consensus in support of allowing ISPs to receive a /40, I'd recommend the text of ARIN-2013-3 as a starting point.

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


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

From David.Huberman at microsoft.com  Fri Aug 14 09:17:43 2015
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 14 Aug 2015 13:17:43 +0000
Subject: [arin-ppml] Smalest ISP v6 Allocation
In-Reply-To: <F6260B47-EF4A-4FDC-9359-2307F72FFDFB@umn.edu>
References: <1674814592.5031.1439547552116.JavaMail.mhammett@ThunderFuck>
	<F6260B47-EF4A-4FDC-9359-2307F72FFDFB@umn.edu>
Message-ID: <DM2PR03MB39842D0E642409C3B13AED19B7C0@DM2PR03MB398.namprd03.prod.outlook.com>

The root problem expressed is one of fees.  We should not make policy that presents inferior network engineering because of fees.  The root problem is for our Board to solve.  According to John Curran on this list, the Board has done so, and will present an attractive fee schedule change in October.

David R Huberman
Principal, Global IP Addressing
Microsoft Corporation

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
Sent: Friday, August 14, 2015 6:13 AM
To: Mike Hammett <arin at ics-il.net>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Smalest ISP v6 Allocation


On Aug 14, 2015, at 05:19, Mike Hammett <arin at ics-il.net<mailto:arin at ics-il.net>> wrote:
If the smallest IPv6 allocation an ISP can get is a /36 (X-small or up to /20 in IPv4), but we have a fee established for XX-small (up to /40 IPv6 and /22 IPv4), why don't we permit an ISP to get a /40? Small providers may not want to increase their ARIN fees to simply be able to get their own IPv6 allocation. Seems counter-intuitive in getting everyone on the IPv6 train. It also falls on a clean boundary, so there shouldn't be any concerns with issued subnets.

If there's no good reason why we're not doing this, how to we start the process to allow this?

A little more than two years ago we considered a policy to do just that;

Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs

https://www.arin.net/policy/proposals/2013_3.html<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.arin.net%2fpolicy%2fproposals%2f2013_3.html&data=01%7c01%7cdavid.huberman%40microsoft.com%7cb066d589a64a438228a308d2a4aa30ef%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=cgxSpN8%2bCrg9YM7OPQ1Vx5VocrAYmxNzwc7pLBcBi%2bY%3d>

The consensus at the time was that a /40 was too small for an ISP and that we should reconsider the fee structure instead.  That has been in process with the fee committee that was discussed previously.  However, if there is a new consensus in support of allowing ISPs to receive a /40, I'd recommend the text of ARIN-2013-3 as a starting point.

--
===============================================
David Farmer                          Email: farmer at umn.edu<mailto:farmer at umn.edu>
Office of Information Technology
University of Minnesota
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================


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

From David.Huberman at microsoft.com  Fri Aug 14 13:55:51 2015
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 14 Aug 2015 17:55:51 +0000
Subject: [arin-ppml] Smalest ISP v6 Allocation
In-Reply-To: <DM2PR03MB39842D0E642409C3B13AED19B7C0@DM2PR03MB398.namprd03.prod.outlook.com>
References: <1674814592.5031.1439547552116.JavaMail.mhammett@ThunderFuck>
	<F6260B47-EF4A-4FDC-9359-2307F72FFDFB@umn.edu>
	<DM2PR03MB39842D0E642409C3B13AED19B7C0@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <DM2PR03MB3989DEF62239A4CA773703E9B7C0@DM2PR03MB398.namprd03.prod.outlook.com>

I have been corrected privately (thank you), and wanted to set the record straight:

John Curran made the comments I wrote on Reddit (not PPML) during Wednesday?s Ask Me Anything:

https://www.reddit.com/r/IAmA/comments/3gqovv/i_am_john_curran_president_and_ceo_of_the/

David R Huberman
Principal, Global IP Addressing
Microsoft Corporation

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Huberman
Sent: Friday, August 14, 2015 6:18 AM
To: David Farmer <farmer at umn.edu>; Mike Hammett <arin at ics-il.net>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Smalest ISP v6 Allocation

The root problem expressed is one of fees.  We should not make policy that presents inferior network engineering because of fees.  The root problem is for our Board to solve.  According to John Curran on this list, the Board has done so, and will present an attractive fee schedule change in October.

David R Huberman
Principal, Global IP Addressing
Microsoft Corporation

From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
Sent: Friday, August 14, 2015 6:13 AM
To: Mike Hammett <arin at ics-il.net<mailto:arin at ics-il.net>>
Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Smalest ISP v6 Allocation


On Aug 14, 2015, at 05:19, Mike Hammett <arin at ics-il.net<mailto:arin at ics-il.net>> wrote:
If the smallest IPv6 allocation an ISP can get is a /36 (X-small or up to /20 in IPv4), but we have a fee established for XX-small (up to /40 IPv6 and /22 IPv4), why don't we permit an ISP to get a /40? Small providers may not want to increase their ARIN fees to simply be able to get their own IPv6 allocation. Seems counter-intuitive in getting everyone on the IPv6 train. It also falls on a clean boundary, so there shouldn't be any concerns with issued subnets.

If there's no good reason why we're not doing this, how to we start the process to allow this?

A little more than two years ago we considered a policy to do just that;

Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
https://www.arin.net/policy/proposals/2013_3.html<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.arin.net%2fpolicy%2fproposals%2f2013_3.html&data=01%7c01%7cdavid.huberman%40microsoft.com%7cb066d589a64a438228a308d2a4aa30ef%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=cgxSpN8%2bCrg9YM7OPQ1Vx5VocrAYmxNzwc7pLBcBi%2bY%3d>

The consensus at the time was that a /40 was too small for an ISP and that we should reconsider the fee structure instead.  That has been in process with the fee committee that was discussed previously.  However, if there is a new consensus in support of allowing ISPs to receive a /40, I'd recommend the text of ARIN-2013-3 as a starting point.

--
===============================================
David Farmer                          Email: farmer at umn.edu<mailto:farmer at umn.edu>
Office of Information Technology
University of Minnesota
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================


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

From andrew.dul at quark.net  Fri Aug 14 14:25:22 2015
From: andrew.dul at quark.net (Andrew Dul)
Date: Fri, 14 Aug 2015 11:25:22 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <408F4B53-FCC7-4ACE-B4F3-8044EC134E44@me.com>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<109AB34A-74ED-4209-B2A4-90BC8ACD10A3@corp.arin.net>
	<408F4B53-FCC7-4ACE-B4F3-8044EC134E44@me.com>
Message-ID: <55CE3292.5080003@quark.net>

I don't think we want to have a policy where we give out an ipv6 /48 per 
ipv4 /24.  I'm all for giving people the space they need, but v6 is a 
different mindset than v4.   A /48 per site has generally been the goal 
of most ipv6 policies.

Andrew

On 8/11/2015 3:05 PM, Alfie Cleveland wrote:
> John -
>
> Apologies if I wasn?t entirely clear. As referenced in Section 9.3.1. 
> of the APNIC INPP, I propose that this also applies to end users - 
> allowing end users to, free of charge, receive a /48 for each /24 they 
> hold.
>
> Regards,
> Alfie
>
>
>> On 11 Aug 2015, at 23:01, John Curran <jcurran at arin.net 
>> <mailto:jcurran at arin.net>> wrote:
>>
>> On Aug 11, 2015, at 4:43 PM, Alfie Cleveland <alfeh at me.com 
>> <mailto:alfeh at me.com>> wrote:
>>>
>>> Hello,
>>>
>>> I?m requesting comment in regards to automatically make 
>>> organisations eligible for IPv6 if they hold justified IPv4 space. 
>>> This similar to Section 9.3.1. of the [APNIC-127] APNIC Internet 
>>> Number Resource Policies. I feel that if organisations were able to 
>>> receive a /48 for each /24 they hold, then it would help expedite 
>>> the rollout of IPv6. Organisations currently have two choices - 
>>> continue to use IPv4, or spend valuable time on applying for IPv6 
>>> space. IPv6 space is clearly in abundance - and this could 
>>> potentially help slow the exhaustion of IPv4.
>>
>>
>> Alfie -
>>
>> Per NRPM 6.5.2.2, an ISP qualifies for an IPv6 allocation if they 
>> 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; i.e.  this means that they presently are 
>> automatically eligible for IPv6 if they
>> hold IPv4 space, as you suggest above.
>>
>> Perhaps you are proposing that there be a default automatic size of 
>> IPv6 allocation ("a /48 for each
>> /24 they hold?) which would allow for more expeditious preparation of 
>> IPv6 initial requests, for those
>> who choose to receive this default allocation size rather than 
>> calculating 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??
>>
>> /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.

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

From jcurran at arin.net  Fri Aug 14 14:53:03 2015
From: jcurran at arin.net (John Curran)
Date: Fri, 14 Aug 2015 18:53:03 +0000
Subject: [arin-ppml] Smalest ISP v6 Allocation
In-Reply-To: <DM2PR03MB3989DEF62239A4CA773703E9B7C0@DM2PR03MB398.namprd03.prod.outlook.com>
References: <1674814592.5031.1439547552116.JavaMail.mhammett@ThunderFuck>
	<F6260B47-EF4A-4FDC-9359-2307F72FFDFB@umn.edu>
	<DM2PR03MB39842D0E642409C3B13AED19B7C0@DM2PR03MB398.namprd03.prod.outlook.com>
	<DM2PR03MB3989DEF62239A4CA773703E9B7C0@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <EFC867C3-F710-4BBC-B28B-B1AF01B56AA8@corp.arin.net>

On Aug 14, 2015, at 1:55 PM, David Huberman <David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>> wrote:

I have been corrected privately (thank you), and wanted to set the record straight:

John Curran made the comments I wrote on Reddit (not PPML) during Wednesday?s Ask Me Anything:

https://www.reddit.com/r/IAmA/comments/3gqovv/i_am_john_curran_president_and_ceo_of_the/

Indeed.   For the curious, my Reddit remarks were:

        "We will be reviewing several options for new fee at the ARIN Member Meeting which will be taking place in Montreal in October... removing disincentives for IPv6 deployment has been acknowledged as a prime consideration and so you should be pleased with the results.?

As I reviewed with the Advisory Council earlier this week, the Fee Structure Review Panel came out
with two clear principles (both of which were covered in the April 2015 Members Meeting in SFO)
<https://www.arin.net/participate/meetings/reports/ARIN_35/PDF/wednesday/curran_fees.pdf>

These principles were:
? IPv4 Fairness: generally expressed that IPv4 fee categories should be lower for small address holders and larger for larger IPv4 address holders
? IPv6 Support: we should encourage deployment with minimal IPv6 fees and avoid disincentives resulting in smaller IPv6 allocations or fee increases

There are some open questions regarding end-user vs ISP, and about the right long-term revenue
model for ARIN in a world where IPv4 ceases to be relevant.   As a result, I am presently working
with the Board on several different options forward for discussion at the October ARIN Member
Meeting.

Thanks!
/John

John Curran
President and CEO
ARIN



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

From owen at delong.com  Fri Aug 14 19:13:04 2015
From: owen at delong.com (Owen DeLong)
Date: Fri, 14 Aug 2015 16:13:04 -0700
Subject: [arin-ppml] Automatic IPv6 Eligibility
In-Reply-To: <55CE3292.5080003@quark.net>
References: <BCD1EE75-CA05-45F3-810D-58DE35E35020@me.com>
	<109AB34A-74ED-4209-B2A4-90BC8ACD10A3@corp.arin.net>
	<408F4B53-FCC7-4ACE-B4F3-8044EC134E44@me.com>
	<55CE3292.5080003@quark.net>
Message-ID: <9FB8DBFB-01F0-4F6F-ACE4-9B993F37C9D0@delong.com>

+1.

Well said, Andrew.

Owen

> On Aug 14, 2015, at 11:25 , Andrew Dul <andrew.dul at quark.net> wrote:
> 
> I don't think we want to have a policy where we give out an ipv6 /48 per ipv4 /24.  I'm all for giving people the space they need, but v6 is a different mindset than v4.   A /48 per site has generally been the goal of most ipv6 policies.
> 
> Andrew
> 
> On 8/11/2015 3:05 PM, Alfie Cleveland wrote:
>> John -
>> 
>> Apologies if I wasn?t entirely clear. As referenced in Section 9.3.1. of the APNIC INPP, I propose that this also applies to end users - allowing end users to, free of charge, receive a /48 for each /24 they hold.
>> 
>> Regards,
>> Alfie
>> 
>> 
>>> On 11 Aug 2015, at 23:01, John Curran < <mailto:jcurran at arin.net>jcurran at arin.net <mailto:jcurran at arin.net>> wrote:
>>> 
>>> On Aug 11, 2015, at 4:43 PM, Alfie Cleveland < <mailto:alfeh at me.com>alfeh at me.com <mailto:alfeh at me.com>> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> I?m requesting comment in regards to automatically make organisations eligible for IPv6 if they hold justified IPv4 space. This similar to  Section 9.3.1. of the [APNIC-127] APNIC Internet Number Resource Policies. I feel that if organisations were able to receive a /48 for each /24 they hold, then it would help expedite the rollout of IPv6. Organisations currently have two choices - continue to use IPv4, or spend valuable time on applying for IPv6 space. IPv6 space is clearly in abundance - and this could potentially help slow the exhaustion of IPv4.
>>> 
>>> 
>>> Alfie -
>>> 
>>> Per NRPM 6.5.2.2, an ISP qualifies for an IPv6 allocation if they 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; i.e.  this means that they presently are automatically eligible for IPv6 if they 
>>> hold IPv4 space, as you suggest above.
>>> 
>>> Perhaps you are proposing that there be a default automatic size of IPv6 allocation ("a /48 for each
>>> /24 they hold?) which would allow for more expeditious preparation of IPv6 initial requests, for those 
>>> who choose to receive this default allocation size rather than calculating 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??  
>>> 
>>> /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 <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.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20150814/56cedb3c/attachment.htm>

From arin at ics-il.net  Fri Aug 14 20:03:08 2015
From: arin at ics-il.net (Mike Hammett)
Date: Fri, 14 Aug 2015 19:03:08 -0500 (CDT)
Subject: [arin-ppml] Smalest ISP v6 Allocation
In-Reply-To: <F6260B47-EF4A-4FDC-9359-2307F72FFDFB@umn.edu>
Message-ID: <354950420.7007.1439597036882.JavaMail.mhammett@ThunderFuck>

*nods* I think a lot of times people forget about the little ISP that only has a /23 of IPv4. Heck, I know one guy that owns at least a half dozen ISPs, none of them more than 1k customers, most under 300. I think people get caught up in the scale of global carriers, nationwide ISPs, etc. 




----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


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

From: "David Farmer" <farmer at umn.edu> 
To: "Mike Hammett" <arin at ics-il.net> 
Cc: arin-ppml at arin.net 
Sent: Friday, August 14, 2015 8:13:26 AM 
Subject: Re: [arin-ppml] Smalest ISP v6 Allocation 




On Aug 14, 2015, at 05:19, Mike Hammett < arin at ics-il.net > wrote: 




If the smallest IPv6 allocation an ISP can get is a /36 (X-small or up to /20 in IPv4), but we have a fee established for XX-small (up to /40 IPv6 and /22 IPv4), why don't we permit an ISP to get a /40? Small providers may not want to increase their ARIN fees to simply be able to get their own IPv6 allocation. Seems counter-intuitive in getting everyone on the IPv6 train. It also falls on a clean boundary, so there shouldn't be any concerns with issued subnets. 

If there's no good reason why we're not doing this, how to we start the process to allow this? 





A little more than two years ago we considered a policy to do just that; 


Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs 

https://www.arin.net/policy/proposals/2013_3.html 


The consensus at the time was that a /40 was too small for an ISP and that we should reconsider the fee structure instead. That has been in process with the fee committee that was discussed previously. However, if there is a new consensus in support of allowing ISPs to receive a /40, I'd recommend the text of ARIN-2013-3 as a starting point. 


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




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

From pmcnary at cameron.net  Fri Aug 14 20:45:38 2015
From: pmcnary at cameron.net (Paul)
Date: Fri, 14 Aug 2015 19:45:38 -0500
Subject: [arin-ppml] Smalest ISP v6 Allocation
In-Reply-To: <354950420.7007.1439597036882.JavaMail.mhammett@ThunderFuck>
References: <354950420.7007.1439597036882.JavaMail.mhammett@ThunderFuck>
Message-ID: <55CE8BB2.4090405@cameron.net>

+1 What Mike is saying!


On 8/14/2015 7:03 PM, Mike Hammett wrote:
> *nods* I think a lot of times people forget about the little ISP that 
> only has a /23 of IPv4. Heck, I know one guy that owns at least a half 
> dozen ISPs, none of them more than 1k customers, most under 300. I 
> think people get caught up in the scale of global carriers, nationwide 
> ISPs, etc.
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> <https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
> <https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix>
> ------------------------------------------------------------------------
> *From: *"David Farmer" <farmer at umn.edu>
> *To: *"Mike Hammett" <arin at ics-il.net>
> *Cc: *arin-ppml at arin.net
> *Sent: *Friday, August 14, 2015 8:13:26 AM
> *Subject: *Re: [arin-ppml] Smalest ISP v6 Allocation
>
>
> On Aug 14, 2015, at 05:19, Mike Hammett <arin at ics-il.net 
> <mailto:arin at ics-il.net>> wrote:
>
>     If the smallest IPv6 allocation an ISP can get is a /36 (X-small
>     or up to /20 in IPv4), but we have a fee established for XX-small
>     (up to /40 IPv6 and /22 IPv4), why don't we permit an ISP to get a
>     /40? Small providers may not want to increase their ARIN fees to
>     simply be able to get their own IPv6 allocation. Seems
>     counter-intuitive in getting everyone on the IPv6 train. It also
>     falls on a clean boundary, so there shouldn't be any concerns with
>     issued subnets.
>
>     If there's no good reason why we're not doing this, how to we
>     start the process to allow this?
>
>
> A little more than two years ago we considered a policy to do just that;
>
> Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
> https://www.arin.net/policy/proposals/2013_3.html
>
> The consensus at the time was that a /40 was too small for an ISP and 
> that we should reconsider the fee structure instead.  That has been in 
> process with the fee committee that was discussed previously. 
>  However, if there is a new consensus in support of allowing ISPs to 
> receive a /40, I'd recommend the text of ARIN-2013-3 as a starting point.
>
> -- 
> ===============================================
> David Farmer  Email: farmer at umn.edu <mailto:farmer at umn.edu>
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE         Phone: +1-612-626-0815
> Minneapolis, MN 55414-3029   Cell: +1-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.

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

From hannigan at gmail.com  Sun Aug 16 23:06:46 2015
From: hannigan at gmail.com (Martin Hannigan)
Date: Sun, 16 Aug 2015 23:06:46 -0400
Subject: [arin-ppml] ARIN Board members
In-Reply-To: <DM2PR03MB39843F6A6165E053A8508EF9B850@DM2PR03MB398.namprd03.prod.outlook.com>
References: <DM2PR03MB39843F6A6165E053A8508EF9B850@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAMDXq5NBG0Ct1EfrtG=+D1D5q7Ggi-92iXRvcVMfpHi7Z8-qKQ@mail.gmail.com>

FYI, the nominations for all [board, AC and NRO ] are closing on Monday at
1700 EST.

https://www.surveymonkey.com/r/ARIN2015

Best,

-M<






On Mon, Jul 20, 2015 at 12:17 PM, David Huberman <
David.Huberman at microsoft.com> wrote:

> Hello,
>
> This morning's email announcing the opening of the nominations period for
> Board of Trustees seats has me stewing on a topic that's bothered me for a
> while.
>
> What fair and objective data does a voter have to judge how well an
> incumbent is doing?
>
> I have been involved with ARIN in various capacities since 1999 and pay a
> LOT of attention.  But in most cases, I can't tell you how good a Board
> member is.  I suspect that's because so much of our activity as the
> collective ARIN happens in the policy making arena, and the Board has
> chosen to be mostly silent in that arena.  At our April meeting in San
> Francisco, I saw a Board member sit silent for the entire 3 days. Before
> that member was on the board, however, he was a strong, productive,
> effective advocate for good policy who earned my vote.  Now he's silent.
> What am I supposed to think now when he runs for re-election? How do I
> judge if he's earned another term? I read the published minutes of the
> Board meetings, and they're not particularly enlightening.
>
> Does the Board Does the Board conduct any reviews or evaluations of Board
> member performance? Is any of that available to the members?
> I mean, the CEO gets reviewed, yes?  If the Board can review the CEO,
> would it be a stretch to ask for reviews of the other 6 members of the
> Board?
>
> David
>
> David R Huberman
> Principal, Global IP Addressing
> Microsoft Corporation
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20150816/8c1b8e6e/attachment.htm>

From jcurran at arin.net  Wed Aug 19 13:36:50 2015
From: jcurran at arin.net (John Curran)
Date: Wed, 19 Aug 2015 17:36:50 +0000
Subject: [arin-ppml] =?utf-8?q?IMPORTANT_for_ARIN_election_nominees_=28Re?=
 =?utf-8?q?=3A_=5Barin-announce=5D_Call_for_Nominations_=E2=80=93_Reminder?=
 =?utf-8?q?=29?=
In-Reply-To: <55B79927.4070406@arin.net>
References: <55B79927.4070406@arin.net>
Message-ID: <FB2B7C8B-5D03-4F8B-8544-5717157CB550@arin.net>

Folks -

Nominations are now closed for the upcoming ARIN elections, and I would like to thank
those who made nominations for the ARIN Board, Advisory Council and for the Number
Resource Organization Number Council (NRO NC), as well as those who agreed to be
nominated and potentially elected by the community to these important positions.

As a reminder, if you have been nominated for one or more of these positions, you must
complete and return the associated Candidate Questionnaire by 20 August (tomorrow!)
5 PM ET.   If you are a nominee, and unaware of that which I speak, please contact me
or ARIN?s Communications and Member Services team at <info at arin.net<mailto:info at arin.net>> asap.

Thank you!
/John

John Curran
President and CEO
ARIN

On Jul 28, 2015, at 11:00 AM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:

Time is running out to submit nominations for the upcoming ARIN elections. Nominations close on 17 August 2015 at 5pm ET for candidates for the elections to fill two seats on the ARIN Board of Trustees, five seats on the Advisory Council (AC), and one seat on the Number Resource Organization Number Council (NRO NC).

The ARIN Board of Trustees will also appoint an NRO NC representative from the slate of candidates to complete the two years remaining in the term previously held by Ron da Silva.

Who can submit a nomination?

You must be a Trustee or an ARIN General Member in Good Standing to make nominations for the Board and Advisory Council. However, those nominated do not need to be from ARIN member organizations. Self-nominations from General Members in Good Standing are permitted. Any individual, regardless of ARIN membership status, may self-nominate or nominate one or more candidates for any open NRO NC position. You can submit a nomination at:

https://www.arin.net/public/election/index.xhtml

For complete details on the nomination process, click here to visit the ARIN Election System Instructions page at:

https://www.arin.net/participate/elections/instructions.html#nominate

All nominations for the Board and AC elections will be reviewed by the Nomination Committee (NomCom). For more NomCom information, see the NomCom Charter at:

https://www.arin.net/about_us/committeecharters.html#nomcom

Please direct any questions to info at arin.net<mailto:info at arin.net>.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN) _______________________________________________
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (ARIN-announce at arin.net<mailto:ARIN-announce at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-announce
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/20150819/dd9c1d8b/attachment.htm>

From rs-lists at seastrom.com  Thu Aug 20 15:46:08 2015
From: rs-lists at seastrom.com (Rob Seastrom)
Date: Thu, 20 Aug 2015 15:46:08 -0400
Subject: [arin-ppml] Thoughts on 2015-7
Message-ID: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>


Dear Colleagues,

It's been almost two months since ARIN 2015-7 was submitted.  Anyone have thoughts on "Simplified requirements for demonstrated need for IPv4 transfers"?

The AC would love your input.

Draft policy text follows:

Draft Policy ARIN-2015-7
Simplified requirements for demonstrated need for IPv4 transfers

Date: 23 June 2015

Problem statement:

ARIN transfer policy currently inherits all its demonstrated need 
requirements for IPv4 transfers from NRPM sections 4. Because that 
section was written primarily to deal with free pool allocations, it is 
much more complicated than is really necessary for transfers. In 
practice, ARIN staff applies much more lenient needs assessment to 
section 8 IPv4 transfer requests than to free pool requests, as 24-month 
needs are much more difficult to assess to the same level of detail.

This proposal seeks to dramatically simplify the needs assessment 
process for 8.3 transfers, while still allowing organizations with 
corner-case requirements to apply under existing policy if necessary.

Policy statement:

8.1.x Simplified requirements for demonstrated need for IPv4 transfers

IPv4 transfer recipients must demonstrate (and an officer of the 
requesting organization must attest) that they will use at least 50% of 
their aggregate IPv4 addresses (including the requested resources) on an 
operational network within 24 months.

Organizations that do not meet the simplified criteria above may instead 
demonstrate the need for number resources using the criteria in section 
4 of the NRPM.

Comments:

a. Timetable for implementation: Immediate

b. Anything else






From michael at linuxmagic.com  Thu Aug 20 16:01:21 2015
From: michael at linuxmagic.com (Michael Peddemors)
Date: Thu, 20 Aug 2015 13:01:21 -0700
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
Message-ID: <55D63211.7080209@linuxmagic.com>

This still looks too 'weak' IMHO to get behind it..

I attest that I can use a /8 in the next 24 months <sic>
(I dream big)

On 15-08-20 12:46 PM, Rob Seastrom wrote:
>
> Dear Colleagues,
>
> It's been almost two months since ARIN 2015-7 was submitted.  Anyone have thoughts on "Simplified requirements for demonstrated need for IPv4 transfers"?
>
> The AC would love your input.
>
> Draft policy text follows:
>
> Draft Policy ARIN-2015-7
> Simplified requirements for demonstrated need for IPv4 transfers
>
> Date: 23 June 2015
>
> Problem statement:
>
> ARIN transfer policy currently inherits all its demonstrated need
> requirements for IPv4 transfers from NRPM sections 4. Because that
> section was written primarily to deal with free pool allocations, it is
> much more complicated than is really necessary for transfers. In
> practice, ARIN staff applies much more lenient needs assessment to
> section 8 IPv4 transfer requests than to free pool requests, as 24-month
> needs are much more difficult to assess to the same level of detail.
>
> This proposal seeks to dramatically simplify the needs assessment
> process for 8.3 transfers, while still allowing organizations with
> corner-case requirements to apply under existing policy if necessary.
>
> Policy statement:
>
> 8.1.x Simplified requirements for demonstrated need for IPv4 transfers
>
> IPv4 transfer recipients must demonstrate (and an officer of the
> requesting organization must attest) that they will use at least 50% of
> their aggregate IPv4 addresses (including the requested resources) on an
> operational network within 24 months.
>
> Organizations that do not meet the simplified criteria above may instead
> demonstrate the need for number resources using the criteria in section
> 4 of the NRPM.
>
> Comments:
>
> a. Timetable for implementation: Immediate
>
> b. Anything else
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From bill at herrin.us  Thu Aug 20 16:30:56 2015
From: bill at herrin.us (William Herrin)
Date: Thu, 20 Aug 2015 16:30:56 -0400
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
Message-ID: <CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>

On Thu, Aug 20, 2015 at 3:46 PM, Rob Seastrom <rs-lists at seastrom.com> wrote:
> 8.1.x Simplified requirements for demonstrated need for IPv4 transfers
>
> IPv4 transfer recipients must demonstrate (and an officer of the
> requesting organization must attest) that they will use at least 50% of
> their aggregate IPv4 addresses (including the requested resources) on an
> operational network within 24 months.

Howdy,

Still against it because it still applies to out-region transfers
where ARIN no longer has access to it and CAN NOT revoke it for fraud
when the attestation turns out to be untrue.

Regards,
Bill Herrin



-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From David.Huberman at microsoft.com  Thu Aug 20 17:05:19 2015
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 20 Aug 2015 21:05:19 +0000
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
Message-ID: <DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>

Hi Bill,



> Still against it because it still applies to out-region transfers where ARIN no

> longer has access to it and CAN NOT revoke it for fraud when the attestation

> turns out to be untrue.



So I get what you're saying.  And you're right.  You and I petition ARIN, attest
that we forecast to use a /X, we're lying, and we transfer it out of the region and

ARIN is done with it - ARIN has no control over the block transferred out.



The disagreement I have with this view is that I don't want us making policy that

punishes the 99.9% of people who are telling the truth and just want to run their

network, so that we can somehow "catch" the 0.01% of the scammers.  I prefer

making policy which works well for bona fide network operators.  People will always

lie, and I do not believe it's ARIN's job to catch that.



Thanks!
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150820/dd1e6b64/attachment.htm>

From bill at herrin.us  Thu Aug 20 17:30:29 2015
From: bill at herrin.us (William Herrin)
Date: Thu, 20 Aug 2015 17:30:29 -0400
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
	<DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAP-guGVkOV22z=PhYHkg62wqSrby3bQUDJ3ZPC9piSNfvEBkoA@mail.gmail.com>

On Thu, Aug 20, 2015 at 5:05 PM, David Huberman
<David.Huberman at microsoft.com> wrote:
> So I get what you're saying.  And you're right.  You and I petition ARIN,
> attest
> that we forecast to use a /X, we're lying, and we transfer it out of the
> region and
>
> ARIN is done with it - ARIN has no control over the block transferred out.
>
>  [...]
> People will always
> lie, and I do not believe it?s ARIN?s job to catch that.

Hi David,

Whose job is it? No point in public policy that isn't binding, and no
policy can be binding without someone charged with enforcement.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From rjletts at uw.edu  Thu Aug 20 18:32:00 2015
From: rjletts at uw.edu (Richard J. Letts)
Date: Thu, 20 Aug 2015 22:32:00 +0000
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
Message-ID: <SN1PR08MB18237198EE0FF14FF2093FF5C0660@SN1PR08MB1823.namprd08.prod.outlook.com>

I'm unconvinced; the new policy leaves it too open for enabling speculation.

Richard Letts

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Rob Seastrom
> Sent: 20 August 2015 12:46 PM
> To: ppml at arin.net
> Subject: [arin-ppml] Thoughts on 2015-7
> 
> 
> Dear Colleagues,
> 
> It's been almost two months since ARIN 2015-7 was submitted.  Anyone have
> thoughts on "Simplified requirements for demonstrated need for IPv4
> transfers"?
> 
> The AC would love your input.
> 
> Draft policy text follows:
> 
> Draft Policy ARIN-2015-7
> Simplified requirements for demonstrated need for IPv4 transfers
> 
> Date: 23 June 2015
> 
> Problem statement:
> 
> ARIN transfer policy currently inherits all its demonstrated need
> requirements for IPv4 transfers from NRPM sections 4. Because that section
> was written primarily to deal with free pool allocations, it is much more
> complicated than is really necessary for transfers. In practice, ARIN
> staff applies much more lenient needs assessment to section 8 IPv4
> transfer requests than to free pool requests, as 24-month needs are much
> more difficult to assess to the same level of detail.
> 
> This proposal seeks to dramatically simplify the needs assessment process
> for 8.3 transfers, while still allowing organizations with corner-case
> requirements to apply under existing policy if necessary.
> 
> Policy statement:
> 
> 8.1.x Simplified requirements for demonstrated need for IPv4 transfers
> 
> IPv4 transfer recipients must demonstrate (and an officer of the
> requesting organization must attest) that they will use at least 50% of
> their aggregate IPv4 addresses (including the requested resources) on an
> operational network within 24 months.
> 
> Organizations that do not meet the simplified criteria above may instead
> demonstrate the need for number resources using the criteria in section
> 4 of the NRPM.
> 
> Comments:
> 
> a. Timetable for implementation: Immediate
> 
> b. Anything else
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 hannigan at gmail.com  Thu Aug 20 18:50:58 2015
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 20 Aug 2015 18:50:58 -0400
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <SN1PR08MB18237198EE0FF14FF2093FF5C0660@SN1PR08MB1823.namprd08.prod.outlook.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<SN1PR08MB18237198EE0FF14FF2093FF5C0660@SN1PR08MB1823.namprd08.prod.outlook.com>
Message-ID: <8BE49F13-E5E9-4939-94F7-A27CAFBD89F9@gmail.com>



I support this. The attestation, at least for US public companies, is not taken lightly. Its toothless, but not meaningless even if only  symbolic.

Best, 

-M< 

> On Aug 20, 2015, at 18:32, Richard J. Letts <rjletts at uw.edu> wrote:
> 
> I'm unconvinced; the new policy leaves it too open for enabling speculation.
> 
> Richard Letts
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Rob Seastrom
>> Sent: 20 August 2015 12:46 PM
>> To: ppml at arin.net
>> Subject: [arin-ppml] Thoughts on 2015-7
>> 
>> 
>> Dear Colleagues,
>> 
>> It's been almost two months since ARIN 2015-7 was submitted.  Anyone have
>> thoughts on "Simplified requirements for demonstrated need for IPv4
>> transfers"?
>> 
>> The AC would love your input.
>> 
>> Draft policy text follows:
>> 
>> Draft Policy ARIN-2015-7
>> Simplified requirements for demonstrated need for IPv4 transfers
>> 
>> Date: 23 June 2015
>> 
>> Problem statement:
>> 
>> ARIN transfer policy currently inherits all its demonstrated need
>> requirements for IPv4 transfers from NRPM sections 4. Because that section
>> was written primarily to deal with free pool allocations, it is much more
>> complicated than is really necessary for transfers. In practice, ARIN
>> staff applies much more lenient needs assessment to section 8 IPv4
>> transfer requests than to free pool requests, as 24-month needs are much
>> more difficult to assess to the same level of detail.
>> 
>> This proposal seeks to dramatically simplify the needs assessment process
>> for 8.3 transfers, while still allowing organizations with corner-case
>> requirements to apply under existing policy if necessary.
>> 
>> Policy statement:
>> 
>> 8.1.x Simplified requirements for demonstrated need for IPv4 transfers
>> 
>> IPv4 transfer recipients must demonstrate (and an officer of the
>> requesting organization must attest) that they will use at least 50% of
>> their aggregate IPv4 addresses (including the requested resources) on an
>> operational network within 24 months.
>> 
>> Organizations that do not meet the simplified criteria above may instead
>> demonstrate the need for number resources using the criteria in section
>> 4 of the NRPM.
>> 
>> Comments:
>> 
>> a. Timetable for implementation: Immediate
>> 
>> b. Anything else
>> 
>> 
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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 matthew at matthew.at  Thu Aug 20 18:58:00 2015
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 20 Aug 2015 15:58:00 -0700
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
	<DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <55D65B78.7090709@matthew.at>

On 8/20/2015 2:05 PM, David Huberman wrote:
>
> Hi Bill,
>
> > Still against it because it still applies to out-region transfers 
> where ARIN no
>
> > longer has access to it and CAN NOT revoke it for fraud when the 
> attestation
>
> > turns out to be untrue.
>
> So I get what you're saying.  And you're right.  You and I petition 
> ARIN, attest
> that we forecast to use a /X, we're lying, and we transfer it out of 
> the region and
>
> ARIN is done with it - ARIN has no control over the block transferred out.
>

That is true today. ARIN does not have any control over how IP blocks 
are used (or transferred) today.

Which is why I'm supportive of this policy... it makes the right thing 
(recording a transfer properly in the ARIN database) happen.


> The disagreement I have with this view is that I don't want us making 
> policy that
>
> punishes the 99.9% of people who are telling the truth and just want 
> to run their
>
> network, so that we can somehow "catch" the 0.01% of the scammers.  I 
> prefer
>
> making policy which works well for bona fide network operators.  
> People will always
>
> lie, and I do not believe it?s ARIN?s job to catch that.
>

Also agree... writing policy to try to block the wrongdoers always makes 
it harder for the legitimate users... which is the group ARIN should be 
supporting.

Matthew Kaufman

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

From khatfield at socllc.net  Thu Aug 20 18:57:09 2015
From: khatfield at socllc.net (khatfield at socllc.net)
Date: Thu, 20 Aug 2015 17:57:09 -0500
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>	<CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
	<DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <1159286698.499.1440111434641@5671a995fdba4007998cbd15e5014528.nuevasync.com>

I agree with David here. I do believe there should be a requirement that any new allocations must keep the allocation x amount of time before it can transferred. Possibly 12 months+ which would thereby kill most ideas to sell for profit.

-Kevin



> On Aug 20, 2015, at 4:05 PM, David Huberman <David.Huberman at microsoft.com> wrote:
> 
> Hi Bill,
>  
> > Still against it because it still applies to out-region transfers where ARIN no
> > longer has access to it and CAN NOT revoke it for fraud when the attestation
> > turns out to be untrue.
>  
> So I get what you're saying.  And you're right.  You and I petition ARIN, attest
> that we forecast to use a /X, we're lying, and we transfer it out of the region and
> ARIN is done with it - ARIN has no control over the block transferred out.
>  
> The disagreement I have with this view is that I don't want us making policy that
> punishes the 99.9% of people who are telling the truth and just want to run their
> network, so that we can somehow "catch" the 0.01% of the scammers.  I prefer
> making policy which works well for bona fide network operators.  People will always
> lie, and I do not believe it?s ARIN?s job to catch that.
>  
> Thanks!
> David
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150820/e711048f/attachment.htm>

From owen at delong.com  Thu Aug 20 19:09:36 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 20 Aug 2015 16:09:36 -0700
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
	<DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <30A91C6A-B2BD-4F00-AC7D-723BC70E1585@delong.com>

This is one of those areas where people of good conscience can disagree.

I absolutely feel it is ARINs job as a steward of resources held in trust for the community
to exercise due diligence in the issuance of those resources and to revoke them when
fraud is detected.

It may not be ARIN?s job to catch 100% of the liars out there, but it is certainly important
that we do not hamstring ARIN in their ability to protect the community from the liars
and the fraudsters to the extent possible.

I am opposed to the proposal.

Owen

> On Aug 20, 2015, at 14:05 , David Huberman <David.Huberman at microsoft.com> wrote:
> 
> Hi Bill, <>
>  
> > Still against it because it still applies to out-region transfers where ARIN no
> > longer has access to it and CAN NOT revoke it for fraud when the attestation
> > turns out to be untrue.
>  
> So I get what you're saying.  And you're right.  You and I petition ARIN, attest
> that we forecast to use a /X, we're lying, and we transfer it out of the region and
> ARIN is done with it - ARIN has no control over the block transferred out.
>  
> The disagreement I have with this view is that I don't want us making policy that
> punishes the 99.9% of people who are telling the truth and just want to run their
> network, so that we can somehow "catch" the 0.01% of the scammers.  I prefer
> making policy which works well for bona fide network operators.  People will always
> lie, and I do not believe it?s ARIN?s job to catch that.
>  
> Thanks!
> David
> _______________________________________________
> 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.

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

From SRyerse at eclipse-networks.com  Thu Aug 20 19:17:38 2015
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Thu, 20 Aug 2015 23:17:38 +0000
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <55D65B78.7090709@matthew.at>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
	<DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
	<55D65B78.7090709@matthew.at>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120183DD9015@ENI-MAIL.eclipse-networks.com>

I agree with Matthew.  +1

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460 - Cell
770.399.9099- Office

[Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc.
        Conquering Complex Networks?

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman
Sent: Thursday, August 20, 2015 6:58 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Thoughts on 2015-7

On 8/20/2015 2:05 PM, David Huberman wrote:

Hi Bill,



> Still against it because it still applies to out-region transfers where ARIN no

> longer has access to it and CAN NOT revoke it for fraud when the attestation

> turns out to be untrue.



So I get what you're saying.  And you're right.  You and I petition ARIN, attest
that we forecast to use a /X, we're lying, and we transfer it out of the region and

ARIN is done with it - ARIN has no control over the block transferred out.

That is true today. ARIN does not have any control over how IP blocks are used (or transferred) today.

Which is why I'm supportive of this policy... it makes the right thing (recording a transfer properly in the ARIN database) happen.






The disagreement I have with this view is that I don't want us making policy that

punishes the 99.9% of people who are telling the truth and just want to run their

network, so that we can somehow "catch" the 0.01% of the scammers.  I prefer

making policy which works well for bona fide network operators.  People will always

lie, and I do not believe it?s ARIN?s job to catch that.

Also agree... writing policy to try to block the wrongdoers always makes it harder for the legitimate users... which is the group ARIN should be supporting.

Matthew Kaufman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150820/6dc00cfa/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150820/6dc00cfa/attachment.jpg>

From matthew at matthew.at  Thu Aug 20 19:35:43 2015
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 20 Aug 2015 16:35:43 -0700
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <30A91C6A-B2BD-4F00-AC7D-723BC70E1585@delong.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
	<DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>
	<30A91C6A-B2BD-4F00-AC7D-723BC70E1585@delong.com>
Message-ID: <55D6644F.5000200@matthew.at>

On 8/20/2015 4:09 PM, Owen DeLong wrote:
> This is one of those areas where people of good conscience can disagree.
>
> I absolutely feel it is ARINs job as a steward of resources held in 
> trust for the community
> to exercise due diligence in the issuance of those resources and to 
> revoke them when
> fraud is detected.

That'd be a whole lot more than ARIN has ever done. You want them 
spending their time trying to revoke and reclaim IPv4 space from 
spammers (for instance) instead of working on getting IPv6 everywhere?

And of course the part they have been great at - diligence in the 
issuance of IPv4 resources - is within a hair's breadth of done forever.

>
> It may not be ARIN?s job to catch 100% of the liars out there, but it 
> is certainly important
> that we do not hamstring ARIN in their ability to protect the 
> community from the liars
> and the fraudsters to the extent possible.
>
> I am opposed to the proposal.
>

Can you explain exactly how ARIN can keep "liars and fraudsters" from 
paying someone money, using their address block anywhere in the world 
for any purpose whatsoever, etc.?

All they can do is update, or not update, the registration database per 
policy. This policy proposal makes their job easier and makes the 
database more likely to reflect the ongoing state of the IPv4 transfer 
market.

Matthew Kaufman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150820/c82783f4/attachment.htm>

From michael at linuxmagic.com  Thu Aug 20 19:55:34 2015
From: michael at linuxmagic.com (Michael Peddemors)
Date: Thu, 20 Aug 2015 16:55:34 -0700
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <55D6644F.5000200@matthew.at>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>	<CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>	<DM2PR03MB39842DC8667824F64BAE4369B660@DM2PR03MB398.namprd03.prod.outlook.com>	<30A91C6A-B2BD-4F00-AC7D-723BC70E1585@delong.com>
	<55D6644F.5000200@matthew.at>
Message-ID: <55D668F6.106@linuxmagic.com>

It looks like it is obvious, we need a new proposal that will 
accommodate both sides of this devide, enabling accurate record keeping, 
without language that encourages a positioning 'policy' that stake 
holders are uncomfortable with.

On 15-08-20 04:35 PM, Matthew Kaufman wrote:
> On 8/20/2015 4:09 PM, Owen DeLong wrote:
>> This is one of those areas where people of good conscience can disagree.
>>
>> I absolutely feel it is ARINs job as a steward of resources held in
>> trust for the community
>> to exercise due diligence in the issuance of those resources and to
>> revoke them when
>> fraud is detected.
>
> That'd be a whole lot more than ARIN has ever done. You want them
> spending their time trying to revoke and reclaim IPv4 space from
> spammers (for instance) instead of working on getting IPv6 everywhere?
>
> And of course the part they have been great at - diligence in the
> issuance of IPv4 resources - is within a hair's breadth of done forever.
>
>>
>> It may not be ARIN?s job to catch 100% of the liars out there, but it
>> is certainly important
>> that we do not hamstring ARIN in their ability to protect the
>> community from the liars
>> and the fraudsters to the extent possible.
>>
>> I am opposed to the proposal.
>>
>
> Can you explain exactly how ARIN can keep "liars and fraudsters" from
> paying someone money, using their address block anywhere in the world
> for any purpose whatsoever, etc.?
>
> All they can do is update, or not update, the registration database per
> policy. This policy proposal makes their job easier and makes the
> database more likely to reflect the ongoing state of the IPv4 transfer
> market.
>
> Matthew Kaufman
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From bjones at vt.edu  Thu Aug 20 16:04:27 2015
From: bjones at vt.edu (Brian Jones)
Date: Thu, 20 Aug 2015 16:04:27 -0400
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
Message-ID: <CANyqO+Ea0_Oxx4dg9UFvzT0fp19nMY5hn+=8gEMW4QH7LuXPyw@mail.gmail.com>

Hello,



On Thu, Aug 20, 2015 at 3:46 PM, Rob Seastrom <rs-lists at seastrom.com> wrote:

>
> Dear Colleagues,
>
> It's been almost two months since ARIN 2015-7 was submitted.  Anyone have
> thoughts on "Simplified requirements for demonstrated need for IPv4
> transfers"?
>
> The AC would love your input.
>
> Draft policy text follows:
>
> Draft Policy ARIN-2015-7
> Simplified requirements for demonstrated need for IPv4 transfers
>
> Date: 23 June 2015
>
> Problem statement:
>
> ARIN transfer policy currently inherits all its demonstrated need
> requirements for IPv4 transfers from NRPM sections 4. Because that
> section was written primarily to deal with free pool allocations, it is
> much more complicated than is really necessary for transfers. In
> practice, ARIN staff applies much more lenient needs assessment to
> section 8 IPv4 transfer requests than to free pool requests, as 24-month
> needs are much more difficult to assess to the same level of detail.
>
> This proposal seeks to dramatically simplify the needs assessment
> process for 8.3 transfers, while still allowing organizations with
> corner-case requirements to apply under existing policy if necessary.
>
> Policy statement:
>
> 8.1.x Simplified requirements for demonstrated need for IPv4 transfers
>
> IPv4 transfer recipients must demonstrate (and an officer of the
> requesting organization must attest) that they will use at least 50% of
> their aggregate IPv4 addresses (including the requested resources) on an
> operational network within 24 months.
>

?I agree with this simplified requirement but would even be willing to
accept a 50% within 12 months and 75% in 24 months requirement. Two years
is a long time to tie up valuable resources that are not being used. IMHO?




>
> Organizations that do not meet the simplified criteria above may instead
> demonstrate the need for number resources using the criteria in section
> 4 of the NRPM.
>
> Comments:
>
> a. Timetable for implementation: Immediate
>
> b. Anything else
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

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

From matthew at matthew.at  Thu Aug 20 21:14:59 2015
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 20 Aug 2015 18:14:59 -0700
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <CANyqO+Ea0_Oxx4dg9UFvzT0fp19nMY5hn+=8gEMW4QH7LuXPyw@mail.gmail.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CANyqO+Ea0_Oxx4dg9UFvzT0fp19nMY5hn+=8gEMW4QH7LuXPyw@mail.gmail.com>
Message-ID: <55D67B93.9030501@matthew.at>

On 8/20/2015 1:04 PM, Brian Jones wrote:
>
> ?I agree with this simplified requirement but would even be willing to 
> accept a 50% within 12 months and 75% in 24 months requirement. Two 
> years is a long time to tie up valuable resources that are not being 
> used. IMHO?
>

I do not understand this reasoning. There is no more free pool. If Org A 
is not using "valuable resources" and they are transferred to Org B who 
was mistaken about how fast they will use them, then Org B is also not 
using "valuable resources". But if instead Org A can't transfer them, 
then Org B doesn't get them and Org A still has "valuable resources" 
which are "tied up". They're "tied up" not being used either way... and 
ARIN can't do anything about it.

If you really want to make sure that these resources don't sit unused, 
make it so that after Org A transfers to Org B then if Org B doesn't use 
all of them, Org B can sell what they're not using.

Matthew Kaufman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150820/d6abdd50/attachment.htm>

From bjones at vt.edu  Thu Aug 20 22:17:01 2015
From: bjones at vt.edu (Brian Jones)
Date: Thu, 20 Aug 2015 22:17:01 -0400
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <55D67B93.9030501@matthew.at>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CANyqO+Ea0_Oxx4dg9UFvzT0fp19nMY5hn+=8gEMW4QH7LuXPyw@mail.gmail.com>
	<55D67B93.9030501@matthew.at>
Message-ID: <CANyqO+F7jFuvCGa3uraXWuFW_6b1t=J22VBEj_T4dcTvnMDNFw@mail.gmail.com>

Mathew,
I think we are in agreement on some level. I don't want valuable resources
to sit idle either. At the same time arbitrarily handing out large blocks
of resources without any real show of need allows for possible misuse of
the resources by those who would hang on to them to get a better price or
for whatever reason they want. Either way the resources sit idle. I am for
a reasonable amount of justification for the amount of resources that can
be consumed in a reasonable time period. Defining reasonable in the last
two sentences and coming to agreement may be the crux of the matter.

If the organization was mistaken about how many or how fast they would use
the resources, then the process should be able to easily accommodate
transfer, selling, or returning them as long as they follow procedures to
ensure that documentation records of the resources can be appropriately
updated for the good of the Internet.

In the end there is really not a good way to prevent unused addresses
sitting idle. It is up to the recipients of justified resources to be good
stewards and use them appropriately and hopefully transfer, sell, or return
them if they no longer need them.

--
Brian
On Aug 20, 2015 9:15 PM, "Matthew Kaufman" <matthew at matthew.at> wrote:

> On 8/20/2015 1:04 PM, Brian Jones wrote:
>
>
> ?I agree with this simplified requirement but would even be willing to
> accept a 50% within 12 months and 75% in 24 months requirement. Two years
> is a long time to tie up valuable resources that are not being used. IMHO?
>
>
> I do not understand this reasoning. There is no more free pool. If Org A
> is not using "valuable resources" and they are transferred to Org B who was
> mistaken about how fast they will use them, then Org B is also not using
> "valuable resources". But if instead Org A can't transfer them, then Org B
> doesn't get them and Org A still has "valuable resources" which are "tied
> up". They're "tied up" not being used either way... and ARIN can't do
> anything about it.
>
> If you really want to make sure that these resources don't sit unused,
> make it so that after Org A transfers to Org B then if Org B doesn't use
> all of them, Org B can sell what they're not using.
>
> Matthew Kaufman
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20150820/008fdf43/attachment.htm>

From narten at us.ibm.com  Fri Aug 21 00:53:03 2015
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 21 Aug 2015 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201508210453.t7L4r3cH009568@rotala.raleigh.ibm.com>

Total of 28 messages in the last 7 days.
 
script run at: Fri Aug 21 00:53:02 EDT 2015
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 10.71% |    3 | 14.38% |    61008 | david.huberman at microsoft.com
  7.14% |    2 | 16.18% |    68673 | jcurran at arin.net
 10.71% |    3 |  6.87% |    29163 | matthew at matthew.at
  7.14% |    2 |  8.81% |    37403 | owen at delong.com
  7.14% |    2 |  8.72% |    36988 | arin at ics-il.net
  7.14% |    2 |  6.12% |    25981 | bjones at vt.edu
  7.14% |    2 |  4.68% |    19855 | hannigan at gmail.com
  7.14% |    2 |  3.84% |    16309 | michael at linuxmagic.com
  7.14% |    2 |  2.94% |    12482 | bill at herrin.us
  3.57% |    1 |  6.03% |    25580 | pmcnary at cameron.net
  3.57% |    1 |  5.03% |    21324 | sryerse at eclipse-networks.com
  3.57% |    1 |  3.92% |    16632 | andrew.dul at quark.net
  3.57% |    1 |  3.47% |    14722 | khatfield at socllc.net
  3.57% |    1 |  2.89% |    12266 | farmer at umn.edu
  3.57% |    1 |  2.78% |    11804 | rjletts at uw.edu
  3.57% |    1 |  1.82% |     7718 | narten at us.ibm.com
  3.57% |    1 |  1.52% |     6446 | rs-lists at seastrom.com
--------+------+--------+----------+------------------------
100.00% |   28 |100.00% |   424354 | Total



From rudi.daniel at gmail.com  Fri Aug 21 10:50:17 2015
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Fri, 21 Aug 2015 10:50:17 -0400
Subject: [arin-ppml] ARIN-PPML 2015-7
Message-ID: <CA+uaoiV39VPLrkznoyE8o5b=3w7rc8K-wNsybp-TA_e+_en7XQ@mail.gmail.com>

Generally against proposal as read.
IMO any relaxation is in favor of those who when given an inch will
generally take a mile or two and out of region use simply magnifies
possibilities .
RD
On Aug 20, 2015 7:10 PM, <arin-ppml-request at arin.net> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>    1. Re: Thoughts on 2015-7 (Martin Hannigan)
>    2. Re: Thoughts on 2015-7 (Matthew Kaufman)
>    3. Re: Thoughts on 2015-7 (khatfield at socllc.net)
>    4. Re: Thoughts on 2015-7 (Owen DeLong)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 20 Aug 2015 18:50:58 -0400
> From: Martin  Hannigan <hannigan at gmail.com>
> To: "ppml at arin.net" <ppml at arin.net>
> Subject: Re: [arin-ppml] Thoughts on 2015-7
> Message-ID: <8BE49F13-E5E9-4939-94F7-A27CAFBD89F9 at gmail.com>
> Content-Type: text/plain;       charset=us-ascii
>
>
>
> I support this. The attestation, at least for US public companies, is not
> taken lightly. Its toothless, but not meaningless even if only  symbolic.
>
> Best,
>
> -M<
>
> > On Aug 20, 2015, at 18:32, Richard J. Letts <rjletts at uw.edu> wrote:
> >
> > I'm unconvinced; the new policy leaves it too open for enabling
> speculation.
> >
> > Richard Letts
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> >> Behalf Of Rob Seastrom
> >> Sent: 20 August 2015 12:46 PM
> >> To: ppml at arin.net
> >> Subject: [arin-ppml] Thoughts on 2015-7
> >>
> >>
> >> Dear Colleagues,
> >>
> >> It's been almost two months since ARIN 2015-7 was submitted.  Anyone
> have
> >> thoughts on "Simplified requirements for demonstrated need for IPv4
> >> transfers"?
> >>
> >> The AC would love your input.
> >>
> >> Draft policy text follows:
> >>
> >> Draft Policy ARIN-2015-7
> >> Simplified requirements for demonstrated need for IPv4 transfers
> >>
> >> Date: 23 June 2015
> >>
> >> Problem statement:
> >>
> >> ARIN transfer policy currently inherits all its demonstrated need
> >> requirements for IPv4 transfers from NRPM sections 4. Because that
> section
> >> was written primarily to deal with free pool allocations, it is much
> more
> >> complicated than is really necessary for transfers. In practice, ARIN
> >> staff applies much more lenient needs assessment to section 8 IPv4
> >> transfer requests than to free pool requests, as 24-month needs are much
> >> more difficult to assess to the same level of detail.
> >>
> >> This proposal seeks to dramatically simplify the needs assessment
> process
> >> for 8.3 transfers, while still allowing organizations with corner-case
> >> requirements to apply under existing policy if necessary.
> >>
> >> Policy statement:
> >>
> >> 8.1.x Simplified requirements for demonstrated need for IPv4 transfers
> >>
> >> IPv4 transfer recipients must demonstrate (and an officer of the
> >> requesting organization must attest) that they will use at least 50% of
> >> their aggregate IPv4 addresses (including the requested resources) on an
> >> operational network within 24 months.
> >>
> >> Organizations that do not meet the simplified criteria above may instead
> >> demonstrate the need for number resources using the criteria in section
> >> 4 of the NRPM.
> >>
> >> Comments:
> >>
> >> a. Timetable for implementation: Immediate
> >>
> >> b. Anything else
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to the ARIN
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage 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.
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 20 Aug 2015 15:58:00 -0700
> From: Matthew Kaufman <matthew at matthew.at>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Thoughts on 2015-7
> Message-ID: <55D65B78.7090709 at matthew.at>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 8/20/2015 2:05 PM, David Huberman wrote:
> >
> > Hi Bill,
> >
> > > Still against it because it still applies to out-region transfers
> > where ARIN no
> >
> > > longer has access to it and CAN NOT revoke it for fraud when the
> > attestation
> >
> > > turns out to be untrue.
> >
> > So I get what you're saying.  And you're right.  You and I petition
> > ARIN, attest
> > that we forecast to use a /X, we're lying, and we transfer it out of
> > the region and
> >
> > ARIN is done with it - ARIN has no control over the block transferred
> out.
> >
>
> That is true today. ARIN does not have any control over how IP blocks
> are used (or transferred) today.
>
> Which is why I'm supportive of this policy... it makes the right thing
> (recording a transfer properly in the ARIN database) happen.
>
>
> > The disagreement I have with this view is that I don't want us making
> > policy that
> >
> > punishes the 99.9% of people who are telling the truth and just want
> > to run their
> >
> > network, so that we can somehow "catch" the 0.01% of the scammers.  I
> > prefer
> >
> > making policy which works well for bona fide network operators.
> > People will always
> >
> > lie, and I do not believe it?s ARIN?s job to catch that.
> >
>
> Also agree... writing policy to try to block the wrongdoers always makes
> it harder for the legitimate users... which is the group ARIN should be
> supporting.
>
> Matthew Kaufman
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20150820/8ce4741f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Thu, 20 Aug 2015 17:57:09 -0500
> From: khatfield at socllc.net
> To: David Huberman <David.Huberman at microsoft.com>
> Cc: "arin-ppml at arin.net" <ppml at arin.net>
> Subject: Re: [arin-ppml] Thoughts on 2015-7
> Message-ID:
>         <
> 1159286698.499.1440111434641 at 5671a995fdba4007998cbd15e5014528.nuevasync.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> I agree with David here. I do believe there should be a requirement that
> any new allocations must keep the allocation x amount of time before it can
> transferred. Possibly 12 months+ which would thereby kill most ideas to
> sell for profit.
>
> -Kevin
>
>
>
> > On Aug 20, 2015, at 4:05 PM, David Huberman <
> David.Huberman at microsoft.com> wrote:
> >
> > Hi Bill,
> >
> > > Still against it because it still applies to out-region transfers
> where ARIN no
> > > longer has access to it and CAN NOT revoke it for fraud when the
> attestation
> > > turns out to be untrue.
> >
> > So I get what you're saying.  And you're right.  You and I petition
> ARIN, attest
> > that we forecast to use a /X, we're lying, and we transfer it out of the
> region and
> > ARIN is done with it - ARIN has no control over the block transferred
> out.
> >
> > The disagreement I have with this view is that I don't want us making
> policy that
> > punishes the 99.9% of people who are telling the truth and just want to
> run their
> > network, so that we can somehow "catch" the 0.01% of the scammers.  I
> prefer
> > making policy which works well for bona fide network operators.  People
> will always
> > lie, and I do not believe it?s ARIN?s job to catch that.
> >
> > Thanks!
> > David
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20150820/e711048f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Thu, 20 Aug 2015 16:09:36 -0700
> From: Owen DeLong <owen at delong.com>
> To: David Huberman <David.Huberman at microsoft.com>
> Cc: "arin-ppml at arin.net" <ppml at arin.net>
> Subject: Re: [arin-ppml] Thoughts on 2015-7
> Message-ID: <30A91C6A-B2BD-4F00-AC7D-723BC70E1585 at delong.com>
> Content-Type: text/plain; charset="utf-8"
>
> This is one of those areas where people of good conscience can disagree.
>
> I absolutely feel it is ARINs job as a steward of resources held in trust
> for the community
> to exercise due diligence in the issuance of those resources and to revoke
> them when
> fraud is detected.
>
> It may not be ARIN?s job to catch 100% of the liars out there, but it is
> certainly important
> that we do not hamstring ARIN in their ability to protect the community
> from the liars
> and the fraudsters to the extent possible.
>
> I am opposed to the proposal.
>
> Owen
>
> > On Aug 20, 2015, at 14:05 , David Huberman <David.Huberman at microsoft.com>
> wrote:
> >
> > Hi Bill, <>
> >
> > > Still against it because it still applies to out-region transfers
> where ARIN no
> > > longer has access to it and CAN NOT revoke it for fraud when the
> attestation
> > > turns out to be untrue.
> >
> > So I get what you're saying.  And you're right.  You and I petition
> ARIN, attest
> > that we forecast to use a /X, we're lying, and we transfer it out of the
> region and
> > ARIN is done with it - ARIN has no control over the block transferred
> out.
> >
> > The disagreement I have with this view is that I don't want us making
> policy that
> > punishes the 99.9% of people who are telling the truth and just want to
> run their
> > network, so that we can somehow "catch" the 0.01% of the scammers.  I
> prefer
> > making policy which works well for bona fide network operators.  People
> will always
> > lie, and I do not believe it?s ARIN?s job to catch that.
> >
> > Thanks!
> > David
> > _______________________________________________
> > 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.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20150820/f89d39d1/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 122, Issue 19
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150821/2a761025/attachment.htm>

From scottleibrand at gmail.com  Fri Aug 21 10:55:57 2015
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 21 Aug 2015 07:55:57 -0700
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <CANyqO+F7jFuvCGa3uraXWuFW_6b1t=J22VBEj_T4dcTvnMDNFw@mail.gmail.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CANyqO+Ea0_Oxx4dg9UFvzT0fp19nMY5hn+=8gEMW4QH7LuXPyw@mail.gmail.com>
	<55D67B93.9030501@matthew.at>
	<CANyqO+F7jFuvCGa3uraXWuFW_6b1t=J22VBEj_T4dcTvnMDNFw@mail.gmail.com>
Message-ID: <73BC964F-CCB4-452A-9580-59C8FB53D159@gmail.com>


> On Aug 20, 2015, at 7:17 PM, Brian Jones <bjones at vt.edu> wrote:
> 
> Mathew, 
> I think we are in agreement on some level. I don't want valuable resources to sit idle either. At the same time arbitrarily handing out large blocks of resources without any real show of need allows for possible misuse of the resources by those who would hang on to them to get a better price or for whatever reason they want.
> 

The IPv4 free pool is now empty, and there are no more large blocks to hand out. Is this still a concern when all blocks must be acquired via transfer? If so, can you explain why that's more of a concern under the proposed policy than under current policy?

> Either way the resources sit idle. I am for a reasonable amount of justification for the amount of resources that can be consumed in a reasonable time period. Defining reasonable in the last two sentences and coming to agreement may be the crux of the matter.
> 
> If the organization was mistaken about how many or how fast they would use the resources, then the process should be able to easily accommodate transfer, selling, or returning them as long as they follow procedures to ensure that documentation records of the resources can be appropriately updated for the good of the Internet.
> 
> In the end there is really not a good way to prevent unused addresses sitting idle. It is up to the recipients of justified resources to be good stewards and use them appropriately and hopefully transfer, sell, or return them if they no longer need them.
> 

Totally agreed. 

-Scott


>> On Aug 20, 2015 9:15 PM, "Matthew Kaufman" <matthew at matthew.at> wrote:
>>> On 8/20/2015 1:04 PM, Brian Jones wrote:
>>> 
>>> ?I agree with this simplified requirement but would even be willing to accept a 50% within 12 months and 75% in 24 months requirement. Two years is a long time to tie up valuable resources that are not being used. IMHO?
>> 
>> I do not understand this reasoning. There is no more free pool. If Org A is not using "valuable resources" and they are transferred to Org B who was mistaken about how fast they will use them, then Org B is also not using "valuable resources". But if instead Org A can't transfer them, then Org B doesn't get them and Org A still has "valuable resources" which are "tied up". They're "tied up" not being used either way... and ARIN can't do anything about it.
>> 
>> If you really want to make sure that these resources don't sit unused, make it so that after Org A transfers to Org B then if Org B doesn't use all of them, Org B can sell what they're not using.
>> 
>> Matthew Kaufman
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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/20150821/7a155739/attachment.htm>

From scottleibrand at gmail.com  Fri Aug 21 11:14:24 2015
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 21 Aug 2015 08:14:24 -0700
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CAP-guGXqBNnC=JyyPm2+hG-774oU_fO0eCSrs9JUmbyURYimgA@mail.gmail.com>
Message-ID: <79BD3EFD-4EDC-4DAC-8688-A6168ECE52B1@gmail.com>


> On Aug 20, 2015, at 1:30 PM, William Herrin <bill at herrin.us> wrote:
> 
>> On Thu, Aug 20, 2015 at 3:46 PM, Rob Seastrom <rs-lists at seastrom.com> wrote:
>> 8.1.x Simplified requirements for demonstrated need for IPv4 transfers
>> 
>> IPv4 transfer recipients must demonstrate (and an officer of the
>> requesting organization must attest) that they will use at least 50% of
>> their aggregate IPv4 addresses (including the requested resources) on an
>> operational network within 24 months.
> 
> Howdy,
> 
> Still against it because it still applies to out-region transfers
> where ARIN no longer has access to it and CAN NOT revoke it for fraud
> when the attestation turns out to be untrue.

Actually, it does not apply to the recipients of out-of-region transfers. NRPM 8.4 states that "The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR." 

This proposed language would only apply to 8.3 and 8.4 transfer recipients in the ARIN region. 

-Scott

From bjones at vt.edu  Fri Aug 21 11:21:23 2015
From: bjones at vt.edu (Brian Jones)
Date: Fri, 21 Aug 2015 11:21:23 -0400
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <73BC964F-CCB4-452A-9580-59C8FB53D159@gmail.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CANyqO+Ea0_Oxx4dg9UFvzT0fp19nMY5hn+=8gEMW4QH7LuXPyw@mail.gmail.com>
	<55D67B93.9030501@matthew.at>
	<CANyqO+F7jFuvCGa3uraXWuFW_6b1t=J22VBEj_T4dcTvnMDNFw@mail.gmail.com>
	<73BC964F-CCB4-452A-9580-59C8FB53D159@gmail.com>
Message-ID: <CANyqO+Eddb0Sn_Pp=HA16hxJDWuWUNkTFi-YS+V5+PBV5w03jw@mail.gmail.com>

On Fri, Aug 21, 2015 at 10:55 AM, Scott Leibrand <scottleibrand at gmail.com>
wrote:

>
> On Aug 20, 2015, at 7:17 PM, Brian Jones <bjones at vt.edu> wrote:
>
> Mathew,
> I think we are in agreement on some level. I don't want valuable resources
> to sit idle either. At the same time arbitrarily handing out large blocks
> of resources without any real show of need allows for possible misuse of
> the resources by those who would hang on to them to get a better price or
> for whatever reason they want.
>
>
> The IPv4 free pool is now empty, and there are no more large blocks to
> hand out. Is this still a concern when all blocks must be acquired via
> transfer? If so, can you explain why that's more of a concern under the
> proposed policy than under current policy?
>

?You are correct that there are not more large blocks to hand out, but
depending on the size of an individual organization a /24 could be a large
block, especially if there are idle and unused? /24's around in say, some
university's unused pool, or maybe a service provider that considers a /24
a very small block and not enough to fool with for transfer or selling.

The only reason any of this is more of a concern now is that the resources
are so scarce. I'm not so sure it is more of a concern in the proposed
policy as the current policy, unless you are one of the small businesses
that a /24 would fulfill your needs for now and the foreseeable future, but
this policy may not be able to help this any. Getting anyone to turn loose
of free blocks of addresses at this point will probably only happen in
partnering agreements or purchase agreements.

?Going forward it is important to have a process that not only accommodates
but also is easy enough that it will encourage transfers to be documented
appropriately. ?

Of course I think everyone should move to IPv6! :)

--
?Brian?



>
> Either way the resources sit idle. I am for a reasonable amount of
> justification for the amount of resources that can be consumed in a
> reasonable time period. Defining reasonable in the last two sentences and
> coming to agreement may be the crux of the matter.
>
> If the organization was mistaken about how many or how fast they would use
> the resources, then the process should be able to easily accommodate
> transfer, selling, or returning them as long as they follow procedures to
> ensure that documentation records of the resources can be appropriately
> updated for the good of the Internet.
>
> In the end there is really not a good way to prevent unused addresses
> sitting idle. It is up to the recipients of justified resources to be good
> stewards and use them appropriately and hopefully transfer, sell, or return
> them if they no longer need them.
>
>
> Totally agreed.
>
> -Scott
>
>
> On Aug 20, 2015 9:15 PM, "Matthew Kaufman" <matthew at matthew.at> wrote:
>
>> On 8/20/2015 1:04 PM, Brian Jones wrote:
>>
>>
>> ?I agree with this simplified requirement but would even be willing to
>> accept a 50% within 12 months and 75% in 24 months requirement. Two years
>> is a long time to tie up valuable resources that are not being used. IMHO?
>>
>>
>> I do not understand this reasoning. There is no more free pool. If Org A
>> is not using "valuable resources" and they are transferred to Org B who was
>> mistaken about how fast they will use them, then Org B is also not using
>> "valuable resources". But if instead Org A can't transfer them, then Org B
>> doesn't get them and Org A still has "valuable resources" which are "tied
>> up". They're "tied up" not being used either way... and ARIN can't do
>> anything about it.
>>
>> If you really want to make sure that these resources don't sit unused,
>> make it so that after Org A transfers to Org B then if Org B doesn't use
>> all of them, Org B can sell what they're not using.
>>
>> Matthew Kaufman
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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/20150821/a4329692/attachment.htm>

From mike at iptrading.com  Fri Aug 21 12:45:19 2015
From: mike at iptrading.com (Mike Burns)
Date: Fri, 21 Aug 2015 12:45:19 -0400
Subject: [arin-ppml] Thoughts on 2015-7
Message-ID: <xwu2pti3ccbtb0e2vu0cpahe.1440175519589@email.android.com>

I support the proposal.

Regards,
Mike Burns


Sent from my Sprint phone

<div>-------- Original message --------</div><div>From: Scott Leibrand <scottleibrand at gmail.com> </div><div>Date:08/21/2015  11:14 AM  (GMT-05:00) </div><div>To: William Herrin <bill at herrin.us> </div><div>Cc: "arin-ppml at arin.net" <ppml at arin.net> </div><div>Subject: Re: [arin-ppml] Thoughts on 2015-7 </div><div>
</div>
> On Aug 20, 2015, at 1:30 PM, William Herrin <bill at herrin.us> wrote:
> 
>> On Thu, Aug 20, 2015 at 3:46 PM, Rob Seastrom <rs-lists at seastrom.com> wrote:
>> 8.1.x Simplified requirements for demonstrated need for IPv4 transfers
>> 
>> IPv4 transfer recipients must demonstrate (and an officer of the
>> requesting organization must attest) that they will use at least 50% of
>> their aggregate IPv4 addresses (including the requested resources) on an
>> operational network within 24 months.
> 
> Howdy,
> 
> Still against it because it still applies to out-region transfers
> where ARIN no longer has access to it and CAN NOT revoke it for fraud
> when the attestation turns out to be untrue.

Actually, it does not apply to the recipients of out-of-region transfers. NRPM 8.4 states that "The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR." 

This proposed language would only apply to 8.3 and 8.4 transfer recipients in the ARIN region. 

-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/20150821/9cbc2324/attachment.htm>

From JOHN at egh.com  Fri Aug 21 15:21:31 2015
From: JOHN at egh.com (John Santos)
Date: Fri, 21 Aug 2015 15:21:31 -0400
Subject: [arin-ppml] ARIN-PPML 2015-7
In-Reply-To: <CA+uaoiV39VPLrkznoyE8o5b=3w7rc8K-wNsybp-TA_e+_en7XQ@mail.gmail.com>
Message-ID: <1150821152043.15636D-100000@joonya.egh.com>

Opposed, based on reasons expressed by Rudi and Owen.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

From rbf+arin-ppml at panix.com  Sun Aug 23 18:52:35 2015
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Sun, 23 Aug 2015 17:52:35 -0500
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <55D67B93.9030501@matthew.at>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>
	<CANyqO+Ea0_Oxx4dg9UFvzT0fp19nMY5hn+=8gEMW4QH7LuXPyw@mail.gmail.com>
	<55D67B93.9030501@matthew.at>
Message-ID: <20150823225235.GA28701@panix.com>

On Thu, Aug 20, 2015 at 06:14:59PM -0700, Matthew Kaufman wrote:
> On 8/20/2015 1:04 PM, Brian Jones wrote:
> >
> >?I agree with this simplified requirement but would even be willing to
> >accept a 50% within 12 months and 75% in 24 months requirement. Two years
> >is a long time to tie up valuable resources that are not being used. IMHO?
> 
> I do not understand this reasoning. There is no more free pool. If Org A is
> not using "valuable resources" and they are transferred to Org B who was
> mistaken about how fast they will use them, then Org B is also not using
> "valuable resources". But if instead Org A can't transfer them, then Org B
> doesn't get them and Org A still has "valuable resources" which are "tied
> up". They're "tied up" not being used either way... and ARIN can't do
> anything about it.

This analysis ignores the existance of Org C that had a need that can
be justified under ARIN policies as they exist today.

If Org A wants to transfer and can't transfer to Org B, Org A probably
won't keep them sitting on the shelf; chances are they'll find Org C or
D or E or ...

     -- Brett


From ggiesen+arin-ppml at giesen.me  Mon Aug 24 11:26:13 2015
From: ggiesen+arin-ppml at giesen.me (Gary T. Giesen)
Date: Mon, 24 Aug 2015 11:26:13 -0400
Subject: [arin-ppml] Thoughts on 2015-7
In-Reply-To: <20150823225235.GA28701@panix.com>
References: <967FBCE6-FD8A-422C-B097-20073E91973F@seastrom.com>	<CANyqO+Ea0_Oxx4dg9UFvzT0fp19nMY5hn+=8gEMW4QH7LuXPyw@mail.gmail.com>	<55D67B93.9030501@matthew.at>
	<20150823225235.GA28701@panix.com>
Message-ID: <073701d0de81$369d4b90$a3d7e2b0$@giesen.me>

I am opposed to the proposal, for the reasons Owen and Rob describe.



From info at arin.net  Tue Aug 25 15:11:57 2015
From: info at arin.net (ARIN)
Date: Tue, 25 Aug 2015 15:11:57 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - August 2015
Message-ID: <55DCBDFD.3080405@arin.net>

In accordance with the ARIN Policy Development Process (PDP), the ARIN
Advisory Council (AC) met on 20 August 2015.

The AC accepted the following as a Draft Policy (it will be
posted for discussion):

   ARIN-prop-222 Reassignment records for IPv4 End-Users

The AC is continuing to work on:

   Recommended Draft Policy ARIN-2015-1: Modification to Criteria for 
IPv6 Initial End-User Assignments
   Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to 
Specified Recipients)
   Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in 
end-user IPv4 policy
   Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better 
reflect how ARIN handles reorganizations
   Draft Policy ARIN-2015-5: Out of region use
   Draft Policy ARIN-2015-6: Transfers and Multi-national Networks
   Draft Policy ARIN-2015-7: Simplified requirements for demonstrated 
need for IPv4 transfers

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 Aug 25 15:12:13 2015
From: info at arin.net (ARIN)
Date: Tue, 25 Aug 2015 15:12:13 -0400
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4
	End-Users
Message-ID: <55DCBE0D.8010802@arin.net>

Draft Policy ARIN-2015-8
Reassignment records for IPv4 End-Users

On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222 
Reassignment records for IPv4 End-Users" as a Draft Policy.

Draft Policy ARIN-2015-8 is below and can be found at:
https://www.arin.net/policy/proposals/2015_8.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2015-8 on the Public Policy Mailing List.

The AC will evaluate the discussion in order to assess the conformance
of this draft policy with ARIN's Principles of Internet Number Resource
Policy as stated in the PDP. Specifically, these principles are:

    * Enabling Fair and Impartial Number Resource Administration
    * Technically Sound
    * Supported by the Community

The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2015-8
Reassignment records for IPv4 End-Users

Date: 25 August 2015

Problem statement:

End-User Organizations do not have the ability to create reassignment 
records in the number resource database.

Reassignment records can be used for a number of different functions 
which could benefit the overall desire to increase database accuracy by 
allowing organizations to add additional details in the database.

The following reasons have been noted as positive reasons to allow the 
creation of additional records.
- Geolocation (allows an organization to specify a different location 
within the database which is used by organizations creating geo-location 
by IP address databases)
- Subsidiary reassignment (allows an organization to note that a portion 
of their netblock is in use by a different subsidiary entity)
- Assignment to contracted parties (some organizations have contracts 
with other organizations which are operating networks under agreements 
with the registrant, this allows the top-level organizations to 
accurately specify the organization operating the network in the number 
resource database)
- More specific contact information (some organizations operate large 
networks which don't necessarily have the same technical or abuse 
contact information)

Policy statement:

Create new section 4.3.x

End-user organizations which have an active registration services 
agreement shall be permitted to create reassignment records in the 
number resource database. Organizations shall use the guidelines 
outlined in section 4.2.3 when creating reassignment records.

Comments:
a. Timetable for implementation: immediately
b. Anything else:

It is noted by the author of this policy proposal that one of the 
distinctions in the service between ISPs and End-Users has been the 
ability for an organization to create reassignment records.

This policy proposal stretches across responsibilities areas as it 
impacts number policy, ARIN operational practice, and fees.

Below we have noted the three areas and the different responsibilities:

A) Providing reassignment support for end-user assignments, for those 
who wish to use it

This is an ARIN Service issue - could be an suggestion/consultation 
process, so long as any implied additional workload/cost can be 
accommodated in budget and the community supports

B) New requirement on end-users to provide reassignment information in 
certain circumstances so that ARIN will treat their usage assertion credibly

This is a policy issue. These requirements should be vetted through the 
policy development process.

C) Fee Implications of ISPs moving to end-user category

This is Board issue, but first requires a community discussion or 
consultation to be held to solicit community input on desired outcome.


From ggiesen+arin-ppml at giesen.me  Wed Aug 26 13:18:43 2015
From: ggiesen+arin-ppml at giesen.me (Gary T. Giesen)
Date: Wed, 26 Aug 2015 13:18:43 -0400
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
	IPv4	End-Users
In-Reply-To: <55DCBE0D.8010802@arin.net>
References: <55DCBE0D.8010802@arin.net>
Message-ID: <009201d0e023$42c24710$c846d530$@giesen.me>

I am opposed to the policy as written.

There are few to no controls on who the end user can SWIP to, which I think
will either result in ISPs applying as end-users to game the system, raise
the cost for end users, or both. 

I assume this is trying to align the NRPM to ARIN's new fee structure which
I believe is due in September?

Cheers,

GTG

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of ARIN
> Sent: August 25, 2015 3:12 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
IPv4
> End-Users
> 
> Draft Policy ARIN-2015-8
> Reassignment records for IPv4 End-Users
> 
> On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222
> Reassignment records for IPv4 End-Users" as a Draft Policy.
> 
> Draft Policy ARIN-2015-8 is below and can be found at:
> https://www.arin.net/policy/proposals/2015_8.html
> 
> You are encouraged to discuss the merits and your concerns of Draft Policy
> 2015-8 on the Public Policy Mailing List.
> 
> The AC will evaluate the discussion in order to assess the conformance of
this
> draft policy with ARIN's Principles of Internet Number Resource Policy as
> stated in the PDP. Specifically, these principles are:
> 
>     * Enabling Fair and Impartial Number Resource Administration
>     * Technically Sound
>     * Supported by the Community
> 
> The ARIN Policy Development Process (PDP) can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy ARIN-2015-8
> Reassignment records for IPv4 End-Users
> 
> Date: 25 August 2015
> 
> Problem statement:
> 
> End-User Organizations do not have the ability to create reassignment
> records in the number resource database.
> 
> Reassignment records can be used for a number of different functions which
> could benefit the overall desire to increase database accuracy by allowing
> organizations to add additional details in the database.
> 
> The following reasons have been noted as positive reasons to allow the
> creation of additional records.
> - Geolocation (allows an organization to specify a different location
within the
> database which is used by organizations creating geo-location by IP
address
> databases)
> - Subsidiary reassignment (allows an organization to note that a portion
of
> their netblock is in use by a different subsidiary entity)
> - Assignment to contracted parties (some organizations have contracts with
> other organizations which are operating networks under agreements with
> the registrant, this allows the top-level organizations to accurately
specify the
> organization operating the network in the number resource database)
> - More specific contact information (some organizations operate large
> networks which don't necessarily have the same technical or abuse contact
> information)
> 
> Policy statement:
> 
> Create new section 4.3.x
> 
> End-user organizations which have an active registration services
agreement
> shall be permitted to create reassignment records in the number resource
> database. Organizations shall use the guidelines outlined in section 4.2.3
> when creating reassignment records.
> 
> Comments:
> a. Timetable for implementation: immediately b. Anything else:
> 
> It is noted by the author of this policy proposal that one of the
distinctions in
> the service between ISPs and End-Users has been the ability for an
> organization to create reassignment records.
> 
> This policy proposal stretches across responsibilities areas as it impacts
> number policy, ARIN operational practice, and fees.
> 
> Below we have noted the three areas and the different responsibilities:
> 
> A) Providing reassignment support for end-user assignments, for those who
> wish to use it
> 
> This is an ARIN Service issue - could be an suggestion/consultation
process,
> so long as any implied additional workload/cost can be accommodated in
> budget and the community supports
> 
> B) New requirement on end-users to provide reassignment information in
> certain circumstances so that ARIN will treat their usage assertion
credibly
> 
> This is a policy issue. These requirements should be vetted through the
policy
> development process.
> 
> C) Fee Implications of ISPs moving to end-user category
> 
> This is Board issue, but first requires a community discussion or
consultation
> to be held to solicit community input on desired outcome.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From alfeh at me.com  Wed Aug 26 14:06:48 2015
From: alfeh at me.com (Alfie Cleveland)
Date: Wed, 26 Aug 2015 19:06:48 +0100
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
	IPv4	End-Users
Message-ID: <B0F44C02-E15B-4D2E-8CBE-3CE20FAEFB35@me.com>

Hey,

I just wanted to state that I am fully in favour of this proposal. Let?s say, for example, I am a large corporation with many divisions. If I, at the head office, apply for IPv4 space as an End-User and receive an assignment, I am then to choose which part of my organisation receives this IPv4 space. Within such a large organisation, there will obviously be emails sent to abuse@<domain>.com, but within such a large organisation it is impossible to guarantee that those misusing space will receive the abuse emails, meaning that their response to the abuse will be hindered. If End-Users are able to create reassignment records, this will be much easier.

There is also the fact that organisations can keep track of how many addresses a department in an organisation has by looking at their ARIN profile as the departments will have the space reassigned to them. It would allow for much easier abuse tracking, and more detailed use figures as each organisation can show exactly where the space is being assigned.

Regards,
Alfie

From ggiesen+arin-ppml at giesen.me  Wed Aug 26 14:30:37 2015
From: ggiesen+arin-ppml at giesen.me (Gary T. Giesen)
Date: Wed, 26 Aug 2015 14:30:37 -0400
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
	for	IPv4	End-Users
In-Reply-To: <B0F44C02-E15B-4D2E-8CBE-3CE20FAEFB35@me.com>
References: <B0F44C02-E15B-4D2E-8CBE-3CE20FAEFB35@me.com>
Message-ID: <009701d0e02d$4dd9bd90$e98d38b0$@giesen.me>

I agree with the proposal in principle, just not as written.

If there were rules around who resassignments could be made to (must be a wholly owned subsidiary, etc) AND it didn't increase the fees for end users, I would support it.

GTG

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Alfie Cleveland
> Sent: August 26, 2015 2:07 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4
> End-Users
> 
> Hey,
> 
> I just wanted to state that I am fully in favour of this proposal. Let?s say, for
> example, I am a large corporation with many divisions. If I, at the head office,
> apply for IPv4 space as an End-User and receive an assignment, I am then to
> choose which part of my organisation receives this IPv4 space. Within such a
> large organisation, there will obviously be emails sent to
> abuse@<domain>.com, but within such a large organisation it is impossible to
> guarantee that those misusing space will receive the abuse emails, meaning
> that their response to the abuse will be hindered. If End-Users are able to
> create reassignment records, this will be much easier.
> 
> There is also the fact that organisations can keep track of how many
> addresses a department in an organisation has by looking at their ARIN
> profile as the departments will have the space reassigned to them. It would
> allow for much easier abuse tracking, and more detailed use figures as each
> organisation can show exactly where the space is being assigned.
> 
> Regards,
> Alfie
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 andrew.dul at quark.net  Wed Aug 26 14:33:43 2015
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 26 Aug 2015 11:33:43 -0700
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
 IPv4 End-Users
In-Reply-To: <009201d0e023$42c24710$c846d530$@giesen.me>
References: <55DCBE0D.8010802@arin.net>
	<009201d0e023$42c24710$c846d530$@giesen.me>
Message-ID: <55DE0687.4010601@quark.net>

Shouldn't operators get to decide and be responsible for what records
they put in the database?  I understand that the potential for mis-use
of additional reassignments, but there is already that potential for
ISPs.  Do you feel that we need to address mis-use with ISP
reassignments too?

One could create all sorts of "schemes" to limit the ability of ISP
users to "game" the system as end users.  Fee per reassignment record,
or 10 reassignments per end-user w/ additional records costing more...

Or maybe we just need to think about if the differences between ISPs and
end-users matter as much in a IPv4 depleted world. 

While this policy likely has downstream fee implications, it is not
designed to map to any particular fee structure.  I haven't seen any
details on any proposed fee changes so I could not take that into
account when drafting this policy.

Andrew

On 8/26/2015 10:18 AM, Gary T. Giesen wrote:
> I am opposed to the policy as written.
>
> There are few to no controls on who the end user can SWIP to, which I think
> will either result in ISPs applying as end-users to game the system, raise
> the cost for end users, or both. 
>
> I assume this is trying to align the NRPM to ARIN's new fee structure which
> I believe is due in September?
>
> Cheers,
>
> GTG
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of ARIN
>> Sent: August 25, 2015 3:12 PM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
> IPv4
>> End-Users
>>
>> Draft Policy ARIN-2015-8
>> Reassignment records for IPv4 End-Users
>>
>> On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222
>> Reassignment records for IPv4 End-Users" as a Draft Policy.
>>
>> Draft Policy ARIN-2015-8 is below and can be found at:
>> https://www.arin.net/policy/proposals/2015_8.html
>>
>> You are encouraged to discuss the merits and your concerns of Draft Policy
>> 2015-8 on the Public Policy Mailing List.
>>
>> The AC will evaluate the discussion in order to assess the conformance of
> this
>> draft policy with ARIN's Principles of Internet Number Resource Policy as
>> stated in the PDP. Specifically, these principles are:
>>
>>     * Enabling Fair and Impartial Number Resource Administration
>>     * Technically Sound
>>     * Supported by the Community
>>
>> The ARIN Policy Development Process (PDP) can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Draft Policy ARIN-2015-8
>> Reassignment records for IPv4 End-Users
>>
>> Date: 25 August 2015
>>
>> Problem statement:
>>
>> End-User Organizations do not have the ability to create reassignment
>> records in the number resource database.
>>
>> Reassignment records can be used for a number of different functions which
>> could benefit the overall desire to increase database accuracy by allowing
>> organizations to add additional details in the database.
>>
>> The following reasons have been noted as positive reasons to allow the
>> creation of additional records.
>> - Geolocation (allows an organization to specify a different location
> within the
>> database which is used by organizations creating geo-location by IP
> address
>> databases)
>> - Subsidiary reassignment (allows an organization to note that a portion
> of
>> their netblock is in use by a different subsidiary entity)
>> - Assignment to contracted parties (some organizations have contracts with
>> other organizations which are operating networks under agreements with
>> the registrant, this allows the top-level organizations to accurately
> specify the
>> organization operating the network in the number resource database)
>> - More specific contact information (some organizations operate large
>> networks which don't necessarily have the same technical or abuse contact
>> information)
>>
>> Policy statement:
>>
>> Create new section 4.3.x
>>
>> End-user organizations which have an active registration services
> agreement
>> shall be permitted to create reassignment records in the number resource
>> database. Organizations shall use the guidelines outlined in section 4.2.3
>> when creating reassignment records.
>>
>> Comments:
>> a. Timetable for implementation: immediately b. Anything else:
>>
>> It is noted by the author of this policy proposal that one of the
> distinctions in
>> the service between ISPs and End-Users has been the ability for an
>> organization to create reassignment records.
>>
>> This policy proposal stretches across responsibilities areas as it impacts
>> number policy, ARIN operational practice, and fees.
>>
>> Below we have noted the three areas and the different responsibilities:
>>
>> A) Providing reassignment support for end-user assignments, for those who
>> wish to use it
>>
>> This is an ARIN Service issue - could be an suggestion/consultation
> process,
>> so long as any implied additional workload/cost can be accommodated in
>> budget and the community supports
>>
>> B) New requirement on end-users to provide reassignment information in
>> certain circumstances so that ARIN will treat their usage assertion
> credibly
>> This is a policy issue. These requirements should be vetted through the
> policy
>> development process.
>>
>> C) Fee Implications of ISPs moving to end-user category
>>
>> This is Board issue, but first requires a community discussion or
> consultation
>> to be held to solicit community input on desired outcome.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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  Wed Aug 26 14:41:45 2015
From: bill at herrin.us (William Herrin)
Date: Wed, 26 Aug 2015 14:41:45 -0400
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
 IPv4 End-Users
In-Reply-To: <B0F44C02-E15B-4D2E-8CBE-3CE20FAEFB35@me.com>
References: <B0F44C02-E15B-4D2E-8CBE-3CE20FAEFB35@me.com>
Message-ID: <CAP-guGVZEFLWBVLKgUxa3Tp7jm3_zXRcC7qvEcP6LB+V17JmDA@mail.gmail.com>

On Wed, Aug 26, 2015 at 2:06 PM, Alfie Cleveland <alfeh at me.com> wrote:
> I just wanted to state that I am fully in favour of this proposal. Let?s say, for example, I am a large corporation with many divisions. If I, at the head office, apply for IPv4 space as an End-User and receive an assignment, I am then to choose which part of my organisation receives this IPv4 space. Within such a large organisation, there will obviously be emails sent to abuse@<domain>.com, but within such a large organisation it is impossible to guarantee that those misusing space will receive the abuse emails, meaning that their response to the abuse will be hindered. If End-Users are able to create reassignment records, this will be much easier.

Hi Alfie,

If such a feature requires an additional payment to ARIN, how much
extra are you willing to pay before it isn't worth it?

In the past, ARIN has claimed SWIP and its related activities as one
of the cost drivers that justify different pricing for ISPs and end
users. Were 2015-8 to become policy, one presumes we wouldn't get it
for free.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>


From ggiesen at giesen.me  Wed Aug 26 15:08:12 2015
From: ggiesen at giesen.me (Gary T. Giesen)
Date: Wed, 26 Aug 2015 15:08:12 -0400
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
	IPv4 End-Users
In-Reply-To: <55DE0687.4010601@quark.net>
References: <55DCBE0D.8010802@arin.net>	<009201d0e023$42c24710$c846d530$@giesen.me>
	<55DE0687.4010601@quark.net>
Message-ID: <009901d0e032$8e745680$ab5d0380$@giesen.me>

Andrew,

If that's your approach, why not create policy to create one class of user,
and remove the distinction altogether? ISPs pay more because they receive
more in services, and because they make money "leasing" IPs. If you make it
so that ISPs can get the same set of services as end users (and start
applying as end-users), then end-user fees will have to increase
appropriately, in order to avoid decreasing ARIN's overall revenues. A lot
of end-users will not want that, to satisfy the wants of a few very large
orgs, for a service which they may even not know exists (and have no desire
to use it)

All I'm talking about is putting in some language to guard against obvious
fraud, and keep costs down for end-users (since they presumably won't have
anywhere near the ratio of SWIPs/block). It's not going to stop an ISP
determined to go the end-user route, but will hopefully steer the
well-meaning ISPs down the correct path and could make it easier to revoke
blocks for blatent fraud.

A lot of what's in the NRPM already is hard to enforce, but that doesn't
stop us from trying to create policies for fair allocations/assignments,
with reasonable controls. I think some plain language about what is and is
not an acceptable SWIP for an end-user is appropriate. What I don't want to
see if the ISP/end-user classes merging by being back-doored through a
policy with no limits.

Cheers,

GTG

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Andrew Dul
> Sent: August 26, 2015 2:34 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
for
> IPv4 End-Users
> 
> Shouldn't operators get to decide and be responsible for what records they
> put in the database?  I understand that the potential for mis-use of
additional
> reassignments, but there is already that potential for ISPs.  Do you feel
that
> we need to address mis-use with ISP reassignments too?
> 
> One could create all sorts of "schemes" to limit the ability of ISP users
to
> "game" the system as end users.  Fee per reassignment record, or 10
> reassignments per end-user w/ additional records costing more...
> 
> Or maybe we just need to think about if the differences between ISPs and
> end-users matter as much in a IPv4 depleted world.
> 
> While this policy likely has downstream fee implications, it is not
designed to
> map to any particular fee structure.  I haven't seen any details on any
> proposed fee changes so I could not take that into account when drafting
this
> policy.
> 
> Andrew
> 
> On 8/26/2015 10:18 AM, Gary T. Giesen wrote:
> > I am opposed to the policy as written.
> >
> > There are few to no controls on who the end user can SWIP to, which I
> > think will either result in ISPs applying as end-users to game the
> > system, raise the cost for end users, or both.
> >
> > I assume this is trying to align the NRPM to ARIN's new fee structure
> > which I believe is due in September?
> >
> > Cheers,
> >
> > GTG
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> >> On Behalf Of ARIN
> >> Sent: August 25, 2015 3:12 PM
> >> To: arin-ppml at arin.net
> >> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
> >> for
> > IPv4
> >> End-Users
> >>
> >> Draft Policy ARIN-2015-8
> >> Reassignment records for IPv4 End-Users
> >>
> >> On 20 August 2015 the ARIN Advisory Council (AC) accepted
> >> "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a Draft
> Policy.
> >>
> >> Draft Policy ARIN-2015-8 is below and can be found at:
> >> https://www.arin.net/policy/proposals/2015_8.html
> >>
> >> You are encouraged to discuss the merits and your concerns of Draft
> >> Policy
> >> 2015-8 on the Public Policy Mailing List.
> >>
> >> The AC will evaluate the discussion in order to assess the
> >> conformance of
> > this
> >> draft policy with ARIN's Principles of Internet Number Resource
> >> Policy as stated in the PDP. Specifically, these principles are:
> >>
> >>     * Enabling Fair and Impartial Number Resource Administration
> >>     * Technically Sound
> >>     * Supported by the Community
> >>
> >> The ARIN Policy Development Process (PDP) can be found at:
> >> https://www.arin.net/policy/pdp.html
> >>
> >> Draft Policies and Proposals under discussion can be found at:
> >> https://www.arin.net/policy/proposals/index.html
> >>
> >> Regards,
> >>
> >> Communications and Member Services
> >> American Registry for Internet Numbers (ARIN)
> >>
> >>
> >> ## * ##
> >>
> >>
> >> Draft Policy ARIN-2015-8
> >> Reassignment records for IPv4 End-Users
> >>
> >> Date: 25 August 2015
> >>
> >> Problem statement:
> >>
> >> End-User Organizations do not have the ability to create reassignment
> >> records in the number resource database.
> >>
> >> Reassignment records can be used for a number of different functions
> >> which could benefit the overall desire to increase database accuracy
> >> by allowing organizations to add additional details in the database.
> >>
> >> The following reasons have been noted as positive reasons to allow
> >> the creation of additional records.
> >> - Geolocation (allows an organization to specify a different location
> > within the
> >> database which is used by organizations creating geo-location by IP
> > address
> >> databases)
> >> - Subsidiary reassignment (allows an organization to note that a
> >> portion
> > of
> >> their netblock is in use by a different subsidiary entity)
> >> - Assignment to contracted parties (some organizations have contracts
> >> with other organizations which are operating networks under
> >> agreements with the registrant, this allows the top-level
> >> organizations to accurately
> > specify the
> >> organization operating the network in the number resource database)
> >> - More specific contact information (some organizations operate large
> >> networks which don't necessarily have the same technical or abuse
> >> contact
> >> information)
> >>
> >> Policy statement:
> >>
> >> Create new section 4.3.x
> >>
> >> End-user organizations which have an active registration services
> > agreement
> >> shall be permitted to create reassignment records in the number
> >> resource database. Organizations shall use the guidelines outlined in
> >> section 4.2.3 when creating reassignment records.
> >>
> >> Comments:
> >> a. Timetable for implementation: immediately b. Anything else:
> >>
> >> It is noted by the author of this policy proposal that one of the
> > distinctions in
> >> the service between ISPs and End-Users has been the ability for an
> >> organization to create reassignment records.
> >>
> >> This policy proposal stretches across responsibilities areas as it
> >> impacts number policy, ARIN operational practice, and fees.
> >>
> >> Below we have noted the three areas and the different responsibilities:
> >>
> >> A) Providing reassignment support for end-user assignments, for those
> >> who wish to use it
> >>
> >> This is an ARIN Service issue - could be an suggestion/consultation
> > process,
> >> so long as any implied additional workload/cost can be accommodated
> >> in budget and the community supports
> >>
> >> B) New requirement on end-users to provide reassignment information
> >> in certain circumstances so that ARIN will treat their usage
> >> assertion
> > credibly
> >> This is a policy issue. These requirements should be vetted through
> >> the
> > policy
> >> development process.
> >>
> >> C) Fee Implications of ISPs moving to end-user category
> >>
> >> This is Board issue, but first requires a community discussion or
> > consultation
> >> to be held to solicit community input on desired outcome.
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to the ARIN
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage 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  Wed Aug 26 20:02:23 2015
From: owen at delong.com (Owen DeLong)
Date: Wed, 26 Aug 2015 17:02:23 -0700
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
	IPv4 End-Users
In-Reply-To: <55DE0687.4010601@quark.net>
References: <55DCBE0D.8010802@arin.net>
	<009201d0e023$42c24710$c846d530$@giesen.me>
	<55DE0687.4010601@quark.net>
Message-ID: <FB481427-B20A-480C-B0CF-FAB2F08E6499@delong.com>

Operators already do get to decide? They can (for the most part) choose to apply
as an ISP or an end-user.

Perhaps a better approach we could take would be to change ISP to LIR throughout
the NRPM and then define LIR to include an ISP and/or any central registry within a
given organization that manages space and makes sub-assignments to entities
within the organization.

I believe this would put the potential abuse on equal footing with the existing potential
for abuse in the ISP world while removing the additional potential abuse of smaller
ISPs attempting to masquerade as end-users. (Something that already occurs across
many ISPs that don?t make static assignments to their end-users).

Owen

> On Aug 26, 2015, at 11:33 , Andrew Dul <andrew.dul at quark.net> wrote:
> 
> Shouldn't operators get to decide and be responsible for what records
> they put in the database?  I understand that the potential for mis-use
> of additional reassignments, but there is already that potential for
> ISPs.  Do you feel that we need to address mis-use with ISP
> reassignments too?
> 
> One could create all sorts of "schemes" to limit the ability of ISP
> users to "game" the system as end users.  Fee per reassignment record,
> or 10 reassignments per end-user w/ additional records costing more...
> 
> Or maybe we just need to think about if the differences between ISPs and
> end-users matter as much in a IPv4 depleted world. 
> 
> While this policy likely has downstream fee implications, it is not
> designed to map to any particular fee structure.  I haven't seen any
> details on any proposed fee changes so I could not take that into
> account when drafting this policy.
> 
> Andrew
> 
> On 8/26/2015 10:18 AM, Gary T. Giesen wrote:
>> I am opposed to the policy as written.
>> 
>> There are few to no controls on who the end user can SWIP to, which I think
>> will either result in ISPs applying as end-users to game the system, raise
>> the cost for end users, or both. 
>> 
>> I assume this is trying to align the NRPM to ARIN's new fee structure which
>> I believe is due in September?
>> 
>> Cheers,
>> 
>> GTG
>> 
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>>> Behalf Of ARIN
>>> Sent: August 25, 2015 3:12 PM
>>> To: arin-ppml at arin.net
>>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
>> IPv4
>>> End-Users
>>> 
>>> Draft Policy ARIN-2015-8
>>> Reassignment records for IPv4 End-Users
>>> 
>>> On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222
>>> Reassignment records for IPv4 End-Users" as a Draft Policy.
>>> 
>>> Draft Policy ARIN-2015-8 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2015_8.html
>>> 
>>> You are encouraged to discuss the merits and your concerns of Draft Policy
>>> 2015-8 on the Public Policy Mailing List.
>>> 
>>> The AC will evaluate the discussion in order to assess the conformance of
>> this
>>> draft policy with ARIN's Principles of Internet Number Resource Policy as
>>> stated in the PDP. Specifically, these principles are:
>>> 
>>>    * Enabling Fair and Impartial Number Resource Administration
>>>    * Technically Sound
>>>    * Supported by the Community
>>> 
>>> The ARIN Policy Development Process (PDP) can be found at:
>>> https://www.arin.net/policy/pdp.html
>>> 
>>> Draft Policies and Proposals under discussion can be found at:
>>> https://www.arin.net/policy/proposals/index.html
>>> 
>>> Regards,
>>> 
>>> Communications and Member Services
>>> American Registry for Internet Numbers (ARIN)
>>> 
>>> 
>>> ## * ##
>>> 
>>> 
>>> Draft Policy ARIN-2015-8
>>> Reassignment records for IPv4 End-Users
>>> 
>>> Date: 25 August 2015
>>> 
>>> Problem statement:
>>> 
>>> End-User Organizations do not have the ability to create reassignment
>>> records in the number resource database.
>>> 
>>> Reassignment records can be used for a number of different functions which
>>> could benefit the overall desire to increase database accuracy by allowing
>>> organizations to add additional details in the database.
>>> 
>>> The following reasons have been noted as positive reasons to allow the
>>> creation of additional records.
>>> - Geolocation (allows an organization to specify a different location
>> within the
>>> database which is used by organizations creating geo-location by IP
>> address
>>> databases)
>>> - Subsidiary reassignment (allows an organization to note that a portion
>> of
>>> their netblock is in use by a different subsidiary entity)
>>> - Assignment to contracted parties (some organizations have contracts with
>>> other organizations which are operating networks under agreements with
>>> the registrant, this allows the top-level organizations to accurately
>> specify the
>>> organization operating the network in the number resource database)
>>> - More specific contact information (some organizations operate large
>>> networks which don't necessarily have the same technical or abuse contact
>>> information)
>>> 
>>> Policy statement:
>>> 
>>> Create new section 4.3.x
>>> 
>>> End-user organizations which have an active registration services
>> agreement
>>> shall be permitted to create reassignment records in the number resource
>>> database. Organizations shall use the guidelines outlined in section 4.2.3
>>> when creating reassignment records.
>>> 
>>> Comments:
>>> a. Timetable for implementation: immediately b. Anything else:
>>> 
>>> It is noted by the author of this policy proposal that one of the
>> distinctions in
>>> the service between ISPs and End-Users has been the ability for an
>>> organization to create reassignment records.
>>> 
>>> This policy proposal stretches across responsibilities areas as it impacts
>>> number policy, ARIN operational practice, and fees.
>>> 
>>> Below we have noted the three areas and the different responsibilities:
>>> 
>>> A) Providing reassignment support for end-user assignments, for those who
>>> wish to use it
>>> 
>>> This is an ARIN Service issue - could be an suggestion/consultation
>> process,
>>> so long as any implied additional workload/cost can be accommodated in
>>> budget and the community supports
>>> 
>>> B) New requirement on end-users to provide reassignment information in
>>> certain circumstances so that ARIN will treat their usage assertion
>> credibly
>>> This is a policy issue. These requirements should be vetted through the
>> policy
>>> development process.
>>> 
>>> C) Fee Implications of ISPs moving to end-user category
>>> 
>>> This is Board issue, but first requires a community discussion or
>> consultation
>>> to be held to solicit community input on desired outcome.
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the ARIN
>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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 rudi.daniel at gmail.com  Thu Aug 27 07:45:50 2015
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Thu, 27 Aug 2015 07:45:50 -0400
Subject: [arin-ppml] 2015-8
Message-ID: <CA+uaoiWuD3HJK4JTT4xd6svq_vrtXkRcuakL7B3CZCV84hdDiQ@mail.gmail.com>

"This policy proposal stretches across responsibilities areas as it impacts
> number policy, ARIN operational practice, and fees."

What would the result of orgs. being allowed to create re assignment
records, yet failing to do so? Or, what would be their motivation to
maintain an acceptible level of accuracy?
RD
On Aug 26, 2015 1:19 PM, <arin-ppml-request at arin.net> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>    1. Re: Thoughts on 2015-7 (Mike Burns)
>    2. Re: ARIN-PPML 2015-7 (John Santos)
>    3. Re: Thoughts on 2015-7 (Brett Frankenberger)
>    4. Re: Thoughts on 2015-7 (Gary T. Giesen)
>    5. Advisory Council Meeting Results - August 2015 (ARIN)
>    6. Draft Policy ARIN-2015-8: Reassignment records for IPv4
>       End-Users (ARIN)
>    7. Re: Draft Policy ARIN-2015-8: Reassignment records for    IPv4
>       End-Users (Gary T. Giesen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Aug 2015 12:45:19 -0400
> From: Mike Burns <mike at iptrading.com>
> To: Scott Leibrand <scottleibrand at gmail.com>, William Herrin
>         <bill at herrin.us>
> Cc: "arin-ppml at arin.net" <ppml at arin.net>
> Subject: Re: [arin-ppml] Thoughts on 2015-7
> Message-ID: <xwu2pti3ccbtb0e2vu0cpahe.1440175519589 at email.android.com>
> Content-Type: text/plain; charset="utf-8"
>
> I support the proposal.
>
> Regards,
> Mike Burns
>
>
> Sent from my Sprint phone
>
> <div>-------- Original message --------</div><div>From: Scott Leibrand <
> scottleibrand at gmail.com> </div><div>Date:08/21/2015  11:14 AM
> (GMT-05:00) </div><div>To: William Herrin <bill at herrin.us> </div><div>Cc:
> "arin-ppml at arin.net" <ppml at arin.net> </div><div>Subject: Re: [arin-ppml]
> Thoughts on 2015-7 </div><div>
> </div>
> > On Aug 20, 2015, at 1:30 PM, William Herrin <bill at herrin.us> wrote:
> >
> >> On Thu, Aug 20, 2015 at 3:46 PM, Rob Seastrom <rs-lists at seastrom.com>
> wrote:
> >> 8.1.x Simplified requirements for demonstrated need for IPv4 transfers
> >>
> >> IPv4 transfer recipients must demonstrate (and an officer of the
> >> requesting organization must attest) that they will use at least 50% of
> >> their aggregate IPv4 addresses (including the requested resources) on an
> >> operational network within 24 months.
> >
> > Howdy,
> >
> > Still against it because it still applies to out-region transfers
> > where ARIN no longer has access to it and CAN NOT revoke it for fraud
> > when the attestation turns out to be untrue.
>
> Actually, it does not apply to the recipients of out-of-region transfers.
> NRPM 8.4 states that "The conditions on a recipient outside of the ARIN
> region will be defined by the policies of the receiving RIR."
>
> This proposed language would only apply to 8.3 and 8.4 transfer recipients
> in the ARIN region.
>
> -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: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20150821/9cbc2324/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 21 Aug 2015 15:21:31 -0400
> From: John Santos <JOHN at egh.com>
> To: Rudolph Daniel <rudi.daniel at gmail.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-PPML 2015-7
> Message-ID: <1150821152043.15636D-100000 at joonya.egh.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Opposed, based on reasons expressed by Rudi and Owen.
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>
> ------------------------------
>
> Message: 3
> Date: Sun, 23 Aug 2015 17:52:35 -0500
> From: Brett Frankenberger <rbf+arin-ppml at panix.com>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Thoughts on 2015-7
> Message-ID: <20150823225235.GA28701 at panix.com>
> Content-Type: text/plain; charset=utf-8
>
> On Thu, Aug 20, 2015 at 06:14:59PM -0700, Matthew Kaufman wrote:
> > On 8/20/2015 1:04 PM, Brian Jones wrote:
> > >
> > >?I agree with this simplified requirement but would even be willing to
> > >accept a 50% within 12 months and 75% in 24 months requirement. Two
> years
> > >is a long time to tie up valuable resources that are not being used.
> IMHO?
> >
> > I do not understand this reasoning. There is no more free pool. If Org A
> is
> > not using "valuable resources" and they are transferred to Org B who was
> > mistaken about how fast they will use them, then Org B is also not using
> > "valuable resources". But if instead Org A can't transfer them, then Org
> B
> > doesn't get them and Org A still has "valuable resources" which are "tied
> > up". They're "tied up" not being used either way... and ARIN can't do
> > anything about it.
>
> This analysis ignores the existance of Org C that had a need that can
> be justified under ARIN policies as they exist today.
>
> If Org A wants to transfer and can't transfer to Org B, Org A probably
> won't keep them sitting on the shelf; chances are they'll find Org C or
> D or E or ...
>
>      -- Brett
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 24 Aug 2015 11:26:13 -0400
> From: "Gary T. Giesen" <ggiesen+arin-ppml at giesen.me>
> To: <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Thoughts on 2015-7
> Message-ID: <073701d0de81$369d4b90$a3d7e2b0$@giesen.me>
> Content-Type: text/plain;       charset="utf-8"
>
> I am opposed to the proposal, for the reasons Owen and Rob describe.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 25 Aug 2015 15:11:57 -0400
> From: ARIN <info at arin.net>
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Advisory Council Meeting Results - August 2015
> Message-ID: <55DCBDFD.3080405 at arin.net>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> In accordance with the ARIN Policy Development Process (PDP), the ARIN
> Advisory Council (AC) met on 20 August 2015.
>
> The AC accepted the following as a Draft Policy (it will be
> posted for discussion):
>
>    ARIN-prop-222 Reassignment records for IPv4 End-Users
>
> The AC is continuing to work on:
>
>    Recommended Draft Policy ARIN-2015-1: Modification to Criteria for
> IPv6 Initial End-User Assignments
>    Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to
> Specified Recipients)
>    Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in
> end-user IPv4 policy
>    Recommended Draft Policy ARIN-2015-4: Modify 8.2 section to better
> reflect how ARIN handles reorganizations
>    Draft Policy ARIN-2015-5: Out of region use
>    Draft Policy ARIN-2015-6: Transfers and Multi-national Networks
>    Draft Policy ARIN-2015-7: Simplified requirements for demonstrated
> need for IPv4 transfers
>
> 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)
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 25 Aug 2015 15:12:13 -0400
> From: ARIN <info at arin.net>
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
>         for IPv4        End-Users
> Message-ID: <55DCBE0D.8010802 at arin.net>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Draft Policy ARIN-2015-8
> Reassignment records for IPv4 End-Users
>
> On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222
> Reassignment records for IPv4 End-Users" as a Draft Policy.
>
> Draft Policy ARIN-2015-8 is below and can be found at:
> https://www.arin.net/policy/proposals/2015_8.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2015-8 on the Public Policy Mailing List.
>
> The AC will evaluate the discussion in order to assess the conformance
> of this draft policy with ARIN's Principles of Internet Number Resource
> Policy as stated in the PDP. Specifically, these principles are:
>
>     * Enabling Fair and Impartial Number Resource Administration
>     * Technically Sound
>     * Supported by the Community
>
> The ARIN Policy Development Process (PDP) can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2015-8
> Reassignment records for IPv4 End-Users
>
> Date: 25 August 2015
>
> Problem statement:
>
> End-User Organizations do not have the ability to create reassignment
> records in the number resource database.
>
> Reassignment records can be used for a number of different functions
> which could benefit the overall desire to increase database accuracy by
> allowing organizations to add additional details in the database.
>
> The following reasons have been noted as positive reasons to allow the
> creation of additional records.
> - Geolocation (allows an organization to specify a different location
> within the database which is used by organizations creating geo-location
> by IP address databases)
> - Subsidiary reassignment (allows an organization to note that a portion
> of their netblock is in use by a different subsidiary entity)
> - Assignment to contracted parties (some organizations have contracts
> with other organizations which are operating networks under agreements
> with the registrant, this allows the top-level organizations to
> accurately specify the organization operating the network in the number
> resource database)
> - More specific contact information (some organizations operate large
> networks which don't necessarily have the same technical or abuse
> contact information)
>
> Policy statement:
>
> Create new section 4.3.x
>
> End-user organizations which have an active registration services
> agreement shall be permitted to create reassignment records in the
> number resource database. Organizations shall use the guidelines
> outlined in section 4.2.3 when creating reassignment records.
>
> Comments:
> a. Timetable for implementation: immediately
> b. Anything else:
>
> It is noted by the author of this policy proposal that one of the
> distinctions in the service between ISPs and End-Users has been the
> ability for an organization to create reassignment records.
>
> This policy proposal stretches across responsibilities areas as it
> impacts number policy, ARIN operational practice, and fees.
>
> Below we have noted the three areas and the different responsibilities:
>
> A) Providing reassignment support for end-user assignments, for those
> who wish to use it
>
> This is an ARIN Service issue - could be an suggestion/consultation
> process, so long as any implied additional workload/cost can be
> accommodated in budget and the community supports
>
> B) New requirement on end-users to provide reassignment information in
> certain circumstances so that ARIN will treat their usage assertion
> credibly
>
> This is a policy issue. These requirements should be vetted through the
> policy development process.
>
> C) Fee Implications of ISPs moving to end-user category
>
> This is Board issue, but first requires a community discussion or
> consultation to be held to solicit community input on desired outcome.
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 26 Aug 2015 13:18:43 -0400
> From: "Gary T. Giesen" <ggiesen+arin-ppml at giesen.me>
> To: <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment
>         records for     IPv4    End-Users
> Message-ID: <009201d0e023$42c24710$c846d530$@giesen.me>
> Content-Type: text/plain;       charset="us-ascii"
>
> I am opposed to the policy as written.
>
> There are few to no controls on who the end user can SWIP to, which I think
> will either result in ISPs applying as end-users to game the system, raise
> the cost for end users, or both.
>
> I assume this is trying to align the NRPM to ARIN's new fee structure which
> I believe is due in September?
>
> Cheers,
>
> GTG
>
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of ARIN
> > Sent: August 25, 2015 3:12 PM
> > To: arin-ppml at arin.net
> > Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
> IPv4
> > End-Users
> >
> > Draft Policy ARIN-2015-8
> > Reassignment records for IPv4 End-Users
> >
> > On 20 August 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-222
> > Reassignment records for IPv4 End-Users" as a Draft Policy.
> >
> > Draft Policy ARIN-2015-8 is below and can be found at:
> > https://www.arin.net/policy/proposals/2015_8.html
> >
> > You are encouraged to discuss the merits and your concerns of Draft
> Policy
> > 2015-8 on the Public Policy Mailing List.
> >
> > The AC will evaluate the discussion in order to assess the conformance of
> this
> > draft policy with ARIN's Principles of Internet Number Resource Policy as
> > stated in the PDP. Specifically, these principles are:
> >
> >     * Enabling Fair and Impartial Number Resource Administration
> >     * Technically Sound
> >     * Supported by the Community
> >
> > The ARIN Policy Development Process (PDP) can be found at:
> > https://www.arin.net/policy/pdp.html
> >
> > Draft Policies and Proposals under discussion can be found at:
> > https://www.arin.net/policy/proposals/index.html
> >
> > Regards,
> >
> > Communications and Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Draft Policy ARIN-2015-8
> > Reassignment records for IPv4 End-Users
> >
> > Date: 25 August 2015
> >
> > Problem statement:
> >
> > End-User Organizations do not have the ability to create reassignment
> > records in the number resource database.
> >
> > Reassignment records can be used for a number of different functions
> which
> > could benefit the overall desire to increase database accuracy by
> allowing
> > organizations to add additional details in the database.
> >
> > The following reasons have been noted as positive reasons to allow the
> > creation of additional records.
> > - Geolocation (allows an organization to specify a different location
> within the
> > database which is used by organizations creating geo-location by IP
> address
> > databases)
> > - Subsidiary reassignment (allows an organization to note that a portion
> of
> > their netblock is in use by a different subsidiary entity)
> > - Assignment to contracted parties (some organizations have contracts
> with
> > other organizations which are operating networks under agreements with
> > the registrant, this allows the top-level organizations to accurately
> specify the
> > organization operating the network in the number resource database)
> > - More specific contact information (some organizations operate large
> > networks which don't necessarily have the same technical or abuse contact
> > information)
> >
> > Policy statement:
> >
> > Create new section 4.3.x
> >
> > End-user organizations which have an active registration services
> agreement
> > shall be permitted to create reassignment records in the number resource
> > database. Organizations shall use the guidelines outlined in section
> 4.2.3
> > when creating reassignment records.
> >
> > Comments:
> > a. Timetable for implementation: immediately b. Anything else:
> >
> > It is noted by the author of this policy proposal that one of the
> distinctions in
> > the service between ISPs and End-Users has been the ability for an
> > organization to create reassignment records.
> >
> > This policy proposal stretches across responsibilities areas as it
> impacts
> > number policy, ARIN operational practice, and fees.
> >
> > Below we have noted the three areas and the different responsibilities:
> >
> > A) Providing reassignment support for end-user assignments, for those who
> > wish to use it
> >
> > This is an ARIN Service issue - could be an suggestion/consultation
> process,
> > so long as any implied additional workload/cost can be accommodated in
> > budget and the community supports
> >
> > B) New requirement on end-users to provide reassignment information in
> > certain circumstances so that ARIN will treat their usage assertion
> credibly
> >
> > This is a policy issue. These requirements should be vetted through the
> policy
> > development process.
> >
> > C) Fee Implications of ISPs moving to end-user category
> >
> > This is Board issue, but first requires a community discussion or
> consultation
> > to be held to solicit community input on desired outcome.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 122, Issue 23
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150827/3d0aa9f5/attachment.htm>

From andrew.dul at quark.net  Thu Aug 27 12:20:08 2015
From: andrew.dul at quark.net (Andrew Dul)
Date: Thu, 27 Aug 2015 09:20:08 -0700
Subject: [arin-ppml] 2015-8
In-Reply-To: <CA+uaoiWuD3HJK4JTT4xd6svq_vrtXkRcuakL7B3CZCV84hdDiQ@mail.gmail.com>
References: <CA+uaoiWuD3HJK4JTT4xd6svq_vrtXkRcuakL7B3CZCV84hdDiQ@mail.gmail.com>
Message-ID: <55DF38B8.5010601@quark.net>

On 8/27/2015 4:45 AM, Rudolph Daniel wrote:
>
> "This policy proposal stretches across responsibilities areas as it 
> impacts
> > number policy, ARIN operational practice, and fees."
>
> What would the result of orgs. being allowed to create re assignment 
> records, yet failing to do so? Or, what would be their motivation to 
> maintain an acceptible level of accuracy?
>

The way the policy is written so far, additional reassignment records, 
are optional.  If the community wanted to see end-users add reassignment 
records as a requirement, that is a discussion that the community should 
have and draft those expectations into policy.

Andrew


From andrew.dul at quark.net  Thu Aug 27 12:38:05 2015
From: andrew.dul at quark.net (Andrew Dul)
Date: Thu, 27 Aug 2015 09:38:05 -0700
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
 IPv4 End-Users
In-Reply-To: <009901d0e032$8e745680$ab5d0380$@giesen.me>
References: <55DCBE0D.8010802@arin.net>
	<009201d0e023$42c24710$c846d530$@giesen.me>
	<55DE0687.4010601@quark.net>
	<009901d0e032$8e745680$ab5d0380$@giesen.me>
Message-ID: <55DF3CED.6050607@quark.net>


On 8/26/2015 12:08 PM, Gary T. Giesen wrote:
> Andrew,
>
> If that's your approach, why not create policy to create one class of user,
> and remove the distinction altogether?
I have contemplated such an approach and even drafted, about 2 years 
ago, a post-IPV4-exhaustion policy rewrite, which collapsed the 
distinction between ISPs and end-users.  In discussing this idea within 
the AC and other community members, they believed at that time that was 
too much for the community to handle.  The community in the past has 
noted that omnibus style policy rewrites are generally not accepted by 
the larger community.

This policy proposal is a way to start the discussion between the ISP / 
end-user differences.  If the wider community support the idea of fully 
collapsing the two categories, we can continue that direction.  If not, 
that is OK, too.


> ISPs pay more because they receive
> more in services, and because they make money "leasing" IPs. If you make it
> so that ISPs can get the same set of services as end users (and start
> applying as end-users), then end-user fees will have to increase
> appropriately, in order to avoid decreasing ARIN's overall revenues. A lot
> of end-users will not want that, to satisfy the wants of a few very large
> orgs, for a service which they may even not know exists (and have no desire
> to use it)
>
> All I'm talking about is putting in some language to guard against obvious
> fraud, and keep costs down for end-users (since they presumably won't have
> anywhere near the ratio of SWIPs/block). It's not going to stop an ISP
> determined to go the end-user route, but will hopefully steer the
> well-meaning ISPs down the correct path and could make it easier to revoke
> blocks for blatent fraud.

Do you have any language that you'd like to see added to the draft such 
that you could support it?

> A lot of what's in the NRPM already is hard to enforce, but that doesn't
> stop us from trying to create policies for fair allocations/assignments,
> with reasonable controls. I think some plain language about what is and is
> not an acceptable SWIP for an end-user is appropriate. What I don't want to
> see if the ISP/end-user classes merging by being back-doored through a
> policy with no limits.

Some of the examples of what I thought were acceptable reassignments I 
put in the problem statement.  Would you support those types of 
reassignment records being allowed for end-users?

Andrew

>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Andrew Dul
>> Sent: August 26, 2015 2:34 PM
>> To: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
> for
>> IPv4 End-Users
>>
>> Shouldn't operators get to decide and be responsible for what records they
>> put in the database?  I understand that the potential for mis-use of
> additional
>> reassignments, but there is already that potential for ISPs.  Do you feel
> that
>> we need to address mis-use with ISP reassignments too?
>>
>> One could create all sorts of "schemes" to limit the ability of ISP users
> to
>> "game" the system as end users.  Fee per reassignment record, or 10
>> reassignments per end-user w/ additional records costing more...
>>
>> Or maybe we just need to think about if the differences between ISPs and
>> end-users matter as much in a IPv4 depleted world.
>>
>> While this policy likely has downstream fee implications, it is not
> designed to
>> map to any particular fee structure.  I haven't seen any details on any
>> proposed fee changes so I could not take that into account when drafting
> this
>> policy.
>>
>> Andrew
>>
>> On 8/26/2015 10:18 AM, Gary T. Giesen wrote:
>>> I am opposed to the policy as written.
>>>
>>> There are few to no controls on who the end user can SWIP to, which I
>>> think will either result in ISPs applying as end-users to game the
>>> system, raise the cost for end users, or both.
>>>
>>> I assume this is trying to align the NRPM to ARIN's new fee structure
>>> which I believe is due in September?
>>>
>>> Cheers,
>>>
>>> GTG
>>>
>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>>>> On Behalf Of ARIN
>>>> Sent: August 25, 2015 3:12 PM
>>>> To: arin-ppml at arin.net
>>>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
>>>> for
>>> IPv4
>>>> End-Users
>>>>
>>>> Draft Policy ARIN-2015-8
>>>> Reassignment records for IPv4 End-Users
>>>>
>>>> On 20 August 2015 the ARIN Advisory Council (AC) accepted
>>>> "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a Draft
>> Policy.
>>>> Draft Policy ARIN-2015-8 is below and can be found at:
>>>> https://www.arin.net/policy/proposals/2015_8.html
>>>>
>>>> You are encouraged to discuss the merits and your concerns of Draft
>>>> Policy
>>>> 2015-8 on the Public Policy Mailing List.
>>>>
>>>> The AC will evaluate the discussion in order to assess the
>>>> conformance of
>>> this
>>>> draft policy with ARIN's Principles of Internet Number Resource
>>>> Policy as stated in the PDP. Specifically, these principles are:
>>>>
>>>>      * Enabling Fair and Impartial Number Resource Administration
>>>>      * Technically Sound
>>>>      * Supported by the Community
>>>>
>>>> The ARIN Policy Development Process (PDP) can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>>
>>>> Draft Policies and Proposals under discussion can be found at:
>>>> https://www.arin.net/policy/proposals/index.html
>>>>
>>>> Regards,
>>>>
>>>> Communications and Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>>
>>>> ## * ##
>>>>
>>>>
>>>> Draft Policy ARIN-2015-8
>>>> Reassignment records for IPv4 End-Users
>>>>
>>>> Date: 25 August 2015
>>>>
>>>> Problem statement:
>>>>
>>>> End-User Organizations do not have the ability to create reassignment
>>>> records in the number resource database.
>>>>
>>>> Reassignment records can be used for a number of different functions
>>>> which could benefit the overall desire to increase database accuracy
>>>> by allowing organizations to add additional details in the database.
>>>>
>>>> The following reasons have been noted as positive reasons to allow
>>>> the creation of additional records.
>>>> - Geolocation (allows an organization to specify a different location
>>> within the
>>>> database which is used by organizations creating geo-location by IP
>>> address
>>>> databases)
>>>> - Subsidiary reassignment (allows an organization to note that a
>>>> portion
>>> of
>>>> their netblock is in use by a different subsidiary entity)
>>>> - Assignment to contracted parties (some organizations have contracts
>>>> with other organizations which are operating networks under
>>>> agreements with the registrant, this allows the top-level
>>>> organizations to accurately
>>> specify the
>>>> organization operating the network in the number resource database)
>>>> - More specific contact information (some organizations operate large
>>>> networks which don't necessarily have the same technical or abuse
>>>> contact
>>>> information)
>>>>
>>>> Policy statement:
>>>>
>>>> Create new section 4.3.x
>>>>
>>>> End-user organizations which have an active registration services
>>> agreement
>>>> shall be permitted to create reassignment records in the number
>>>> resource database. Organizations shall use the guidelines outlined in
>>>> section 4.2.3 when creating reassignment records.
>>>>
>>>> Comments:
>>>> a. Timetable for implementation: immediately b. Anything else:
>>>>
>>>> It is noted by the author of this policy proposal that one of the
>>> distinctions in
>>>> the service between ISPs and End-Users has been the ability for an
>>>> organization to create reassignment records.
>>>>
>>>> This policy proposal stretches across responsibilities areas as it
>>>> impacts number policy, ARIN operational practice, and fees.
>>>>
>>>> Below we have noted the three areas and the different responsibilities:
>>>>
>>>> A) Providing reassignment support for end-user assignments, for those
>>>> who wish to use it
>>>>
>>>> This is an ARIN Service issue - could be an suggestion/consultation
>>> process,
>>>> so long as any implied additional workload/cost can be accommodated
>>>> in budget and the community supports
>>>>
>>>> B) New requirement on end-users to provide reassignment information
>>>> in certain circumstances so that ARIN will treat their usage
>>>> assertion
>>> credibly
>>>> This is a policy issue. These requirements should be vetted through
>>>> the
>>> policy
>>>> development process.
>>>>
>>>> C) Fee Implications of ISPs moving to end-user category
>>>>
>>>> This is Board issue, but first requires a community discussion or
>>> consultation
>>>> to be held to solicit community input on desired outcome.
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to the ARIN
>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the ARIN
>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Thu Aug 27 17:09:45 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 27 Aug 2015 14:09:45 -0700
Subject: [arin-ppml] 2015-8
In-Reply-To: <55DF38B8.5010601@quark.net>
References: <CA+uaoiWuD3HJK4JTT4xd6svq_vrtXkRcuakL7B3CZCV84hdDiQ@mail.gmail.com>
	<55DF38B8.5010601@quark.net>
Message-ID: <B12ACD10-6C39-4C6C-A374-9F44EE0B7F14@delong.com>


> On Aug 27, 2015, at 09:20 , Andrew Dul <andrew.dul at quark.net> wrote:
> 
> On 8/27/2015 4:45 AM, Rudolph Daniel wrote:
>> 
>> "This policy proposal stretches across responsibilities areas as it impacts
>> > number policy, ARIN operational practice, and fees."
>> 
>> What would the result of orgs. being allowed to create re assignment records, yet failing to do so? Or, what would be their motivation to maintain an acceptible level of accuracy?
>> 
> 
> The way the policy is written so far, additional reassignment records, are optional.  If the community wanted to see end-users add reassignment records as a requirement, that is a discussion that the community should have and draft those expectations into policy.

I remain unconvinced that even allowing end user reassignment records is a good idea.

However, you are right as to discussing requiring them.

However, even if we make them optional, Rudy raises a good and valid point about what is in place to ensure that they remain at all accurate.

Owen



From narten at us.ibm.com  Fri Aug 28 00:53:02 2015
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 28 Aug 2015 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201508280453.t7S4r3ZE006390@rotala.raleigh.ibm.com>

Total of 22 messages in the last 7 days.
 
script run at: Fri Aug 28 00:53:02 EDT 2015
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  9.09% |    2 | 30.36% |    82859 | rudi.daniel at gmail.com
 13.64% |    3 | 13.06% |    35656 | andrew.dul at quark.net
 13.64% |    3 |  8.58% |    23428 | ggiesen+arin-ppml at giesen.me
  9.09% |    2 |  8.02% |    21890 | scottleibrand at gmail.com
  9.09% |    2 |  6.81% |    18577 | owen at delong.com
  9.09% |    2 |  5.20% |    14181 | info at arin.net
  4.55% |    1 |  7.05% |    19234 | bjones at vt.edu
  4.55% |    1 |  5.24% |    14300 | ggiesen at giesen.me
  4.55% |    1 |  3.93% |    10721 | mike at iptrading.com
  4.55% |    1 |  2.75% |     7507 | narten at us.ibm.com
  4.55% |    1 |  2.45% |     6695 | bill at herrin.us
  4.55% |    1 |  2.30% |     6290 | alfeh at me.com
  4.55% |    1 |  2.26% |     6165 | rbf+arin-ppml at panix.com
  4.55% |    1 |  1.99% |     5440 | john at egh.com
--------+------+--------+----------+------------------------
100.00% |   22 |100.00% |   272943 | Total



From ggiesen+arin-ppml at giesen.me  Fri Aug 28 12:59:24 2015
From: ggiesen+arin-ppml at giesen.me (Gary T. Giesen)
Date: Fri, 28 Aug 2015 12:59:24 -0400
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
	IPv4 End-Users
In-Reply-To: <55DF3CED.6050607@quark.net>
References: <55DCBE0D.8010802@arin.net>	<009201d0e023$42c24710$c846d530$@giesen.me>	<55DE0687.4010601@quark.net>	<009901d0e032$8e745680$ab5d0380$@giesen.me>
	<55DF3CED.6050607@quark.net>
Message-ID: <031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me>

I'd suggest something like this to define which entities reassignments can
be performed to:

1) A business department, division or sector which is not legally distinct
from address space holder
2) A subsidiary of the address space holder, where the parent has a
controlling interest
3) A sister company of the address space holder, where the parent company of
the address space holder holds a controlling interest in both daughter
companies

Of course, since I am neither a lawyer nor an expert in corporate structures
this should be reviewed by legal, but my basic intention is that there be a
single, common ownership between the address holder and the reassignees. I
included #3 because there may be a subsidiary which handles IT/network
services for its sister companies.

Cheers,

GTG

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Andrew Dul
> Sent: August 27, 2015 12:38 PM
> To: Gary T. Giesen; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
for
> IPv4 End-Users
> 
> 
> On 8/26/2015 12:08 PM, Gary T. Giesen wrote:
> > Andrew,
> >
> > If that's your approach, why not create policy to create one class of
> > user, and remove the distinction altogether?
> I have contemplated such an approach and even drafted, about 2 years ago,
> a post-IPV4-exhaustion policy rewrite, which collapsed the distinction
> between ISPs and end-users.  In discussing this idea within the AC and
other
> community members, they believed at that time that was too much for the
> community to handle.  The community in the past has noted that omnibus
> style policy rewrites are generally not accepted by the larger community.
> 
> This policy proposal is a way to start the discussion between the ISP /
end-
> user differences.  If the wider community support the idea of fully
collapsing
> the two categories, we can continue that direction.  If not, that is OK,
too.
> 
> 
> > ISPs pay more because they receive
> > more in services, and because they make money "leasing" IPs. If you
> > make it so that ISPs can get the same set of services as end users
> > (and start applying as end-users), then end-user fees will have to
> > increase appropriately, in order to avoid decreasing ARIN's overall
> > revenues. A lot of end-users will not want that, to satisfy the wants
> > of a few very large orgs, for a service which they may even not know
> > exists (and have no desire to use it)
> >
> > All I'm talking about is putting in some language to guard against
> > obvious fraud, and keep costs down for end-users (since they
> > presumably won't have anywhere near the ratio of SWIPs/block). It's
> > not going to stop an ISP determined to go the end-user route, but will
> > hopefully steer the well-meaning ISPs down the correct path and could
> > make it easier to revoke blocks for blatent fraud.
> 
> Do you have any language that you'd like to see added to the draft such
that
> you could support it?
> 
> > A lot of what's in the NRPM already is hard to enforce, but that
> > doesn't stop us from trying to create policies for fair
> > allocations/assignments, with reasonable controls. I think some plain
> > language about what is and is not an acceptable SWIP for an end-user
> > is appropriate. What I don't want to see if the ISP/end-user classes
> > merging by being back-doored through a policy with no limits.
> 
> Some of the examples of what I thought were acceptable reassignments I
> put in the problem statement.  Would you support those types of
> reassignment records being allowed for end-users?
> 
> Andrew
> 
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> >> On Behalf Of Andrew Dul
> >> Sent: August 26, 2015 2:34 PM
> >> To: arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment
> >> records
> > for
> >> IPv4 End-Users
> >>
> >> Shouldn't operators get to decide and be responsible for what records
> >> they put in the database?  I understand that the potential for
> >> mis-use of
> > additional
> >> reassignments, but there is already that potential for ISPs.  Do you
> >> feel
> > that
> >> we need to address mis-use with ISP reassignments too?
> >>
> >> One could create all sorts of "schemes" to limit the ability of ISP
> >> users
> > to
> >> "game" the system as end users.  Fee per reassignment record, or 10
> >> reassignments per end-user w/ additional records costing more...
> >>
> >> Or maybe we just need to think about if the differences between ISPs
> >> and end-users matter as much in a IPv4 depleted world.
> >>
> >> While this policy likely has downstream fee implications, it is not
> > designed to
> >> map to any particular fee structure.  I haven't seen any details on
> >> any proposed fee changes so I could not take that into account when
> >> drafting
> > this
> >> policy.
> >>
> >> Andrew
> >>
> >> On 8/26/2015 10:18 AM, Gary T. Giesen wrote:
> >>> I am opposed to the policy as written.
> >>>
> >>> There are few to no controls on who the end user can SWIP to, which
> >>> I think will either result in ISPs applying as end-users to game the
> >>> system, raise the cost for end users, or both.
> >>>
> >>> I assume this is trying to align the NRPM to ARIN's new fee
> >>> structure which I believe is due in September?
> >>>
> >>> Cheers,
> >>>
> >>> GTG
> >>>
> >>>> -----Original Message-----
> >>>> From: arin-ppml-bounces at arin.net
> >>>> [mailto:arin-ppml-bounces at arin.net]
> >>>> On Behalf Of ARIN
> >>>> Sent: August 25, 2015 3:12 PM
> >>>> To: arin-ppml at arin.net
> >>>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
> >>>> for
> >>> IPv4
> >>>> End-Users
> >>>>
> >>>> Draft Policy ARIN-2015-8
> >>>> Reassignment records for IPv4 End-Users
> >>>>
> >>>> On 20 August 2015 the ARIN Advisory Council (AC) accepted
> >>>> "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a Draft
> >> Policy.
> >>>> Draft Policy ARIN-2015-8 is below and can be found at:
> >>>> https://www.arin.net/policy/proposals/2015_8.html
> >>>>
> >>>> You are encouraged to discuss the merits and your concerns of Draft
> >>>> Policy
> >>>> 2015-8 on the Public Policy Mailing List.
> >>>>
> >>>> The AC will evaluate the discussion in order to assess the
> >>>> conformance of
> >>> this
> >>>> draft policy with ARIN's Principles of Internet Number Resource
> >>>> Policy as stated in the PDP. Specifically, these principles are:
> >>>>
> >>>>      * Enabling Fair and Impartial Number Resource Administration
> >>>>      * Technically Sound
> >>>>      * Supported by the Community
> >>>>
> >>>> The ARIN Policy Development Process (PDP) can be found at:
> >>>> https://www.arin.net/policy/pdp.html
> >>>>
> >>>> Draft Policies and Proposals under discussion can be found at:
> >>>> https://www.arin.net/policy/proposals/index.html
> >>>>
> >>>> Regards,
> >>>>
> >>>> Communications and Member Services
> >>>> American Registry for Internet Numbers (ARIN)
> >>>>
> >>>>
> >>>> ## * ##
> >>>>
> >>>>
> >>>> Draft Policy ARIN-2015-8
> >>>> Reassignment records for IPv4 End-Users
> >>>>
> >>>> Date: 25 August 2015
> >>>>
> >>>> Problem statement:
> >>>>
> >>>> End-User Organizations do not have the ability to create
> >>>> reassignment records in the number resource database.
> >>>>
> >>>> Reassignment records can be used for a number of different
> >>>> functions which could benefit the overall desire to increase
> >>>> database accuracy by allowing organizations to add additional details
in
> the database.
> >>>>
> >>>> The following reasons have been noted as positive reasons to allow
> >>>> the creation of additional records.
> >>>> - Geolocation (allows an organization to specify a different
> >>>> location
> >>> within the
> >>>> database which is used by organizations creating geo-location by IP
> >>> address
> >>>> databases)
> >>>> - Subsidiary reassignment (allows an organization to note that a
> >>>> portion
> >>> of
> >>>> their netblock is in use by a different subsidiary entity)
> >>>> - Assignment to contracted parties (some organizations have
> >>>> contracts with other organizations which are operating networks
> >>>> under agreements with the registrant, this allows the top-level
> >>>> organizations to accurately
> >>> specify the
> >>>> organization operating the network in the number resource database)
> >>>> - More specific contact information (some organizations operate
> >>>> large networks which don't necessarily have the same technical or
> >>>> abuse contact
> >>>> information)
> >>>>
> >>>> Policy statement:
> >>>>
> >>>> Create new section 4.3.x
> >>>>
> >>>> End-user organizations which have an active registration services
> >>> agreement
> >>>> shall be permitted to create reassignment records in the number
> >>>> resource database. Organizations shall use the guidelines outlined
> >>>> in section 4.2.3 when creating reassignment records.
> >>>>
> >>>> Comments:
> >>>> a. Timetable for implementation: immediately b. Anything else:
> >>>>
> >>>> It is noted by the author of this policy proposal that one of the
> >>> distinctions in
> >>>> the service between ISPs and End-Users has been the ability for an
> >>>> organization to create reassignment records.
> >>>>
> >>>> This policy proposal stretches across responsibilities areas as it
> >>>> impacts number policy, ARIN operational practice, and fees.
> >>>>
> >>>> Below we have noted the three areas and the different
> responsibilities:
> >>>>
> >>>> A) Providing reassignment support for end-user assignments, for
> >>>> those who wish to use it
> >>>>
> >>>> This is an ARIN Service issue - could be an suggestion/consultation
> >>> process,
> >>>> so long as any implied additional workload/cost can be accommodated
> >>>> in budget and the community supports
> >>>>
> >>>> B) New requirement on end-users to provide reassignment
> information
> >>>> in certain circumstances so that ARIN will treat their usage
> >>>> assertion
> >>> credibly
> >>>> This is a policy issue. These requirements should be vetted through
> >>>> the
> >>> policy
> >>>> development process.
> >>>>
> >>>> C) Fee Implications of ISPs moving to end-user category
> >>>>
> >>>> This is Board issue, but first requires a community discussion or
> >>> consultation
> >>>> to be held to solicit community input on desired outcome.
> >>>> _______________________________________________
> >>>> PPML
> >>>> You are receiving this message because you are subscribed to the
> >>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>> Unsubscribe or manage your mailing list subscription at:
> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>> Please contact info at arin.net if you experience any issues.
> >>> _______________________________________________
> >>> PPML
> >>> You are receiving this message because you are subscribed to the
> >>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>> Unsubscribe or manage your mailing list subscription at:
> >>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>> Please contact info at arin.net if you experience any issues.
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to the ARIN
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From andrew.dul at quark.net  Fri Aug 28 13:48:33 2015
From: andrew.dul at quark.net (Andrew Dul)
Date: Fri, 28 Aug 2015 10:48:33 -0700
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
 IPv4 End-Users
In-Reply-To: <031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me>
References: <55DCBE0D.8010802@arin.net>
	<009201d0e023$42c24710$c846d530$@giesen.me>
	<55DE0687.4010601@quark.net>
	<009901d0e032$8e745680$ab5d0380$@giesen.me>
	<55DF3CED.6050607@quark.net>
	<031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me>
Message-ID: <55E09EF1.5070206@quark.net>

I believe there is value in allowing end-users to add reassignments for
organizations which they don't wholly control.  Gary, I think we will
have to just agree to disagree on that point.  I think your definition
fits with what you are hoping for, thanks for the text.

Andrew

On 8/28/2015 9:59 AM, Gary T. Giesen wrote:
> I'd suggest something like this to define which entities reassignments can
> be performed to:
>
> 1) A business department, division or sector which is not legally distinct
> from address space holder
> 2) A subsidiary of the address space holder, where the parent has a
> controlling interest
> 3) A sister company of the address space holder, where the parent company of
> the address space holder holds a controlling interest in both daughter
> companies
>
> Of course, since I am neither a lawyer nor an expert in corporate structures
> this should be reviewed by legal, but my basic intention is that there be a
> single, common ownership between the address holder and the reassignees. I
> included #3 because there may be a subsidiary which handles IT/network
> services for its sister companies.
>
> Cheers,
>
> GTG
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Andrew Dul
>> Sent: August 27, 2015 12:38 PM
>> To: Gary T. Giesen; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
> for
>> IPv4 End-Users
>>
>>
>> On 8/26/2015 12:08 PM, Gary T. Giesen wrote:
>>> Andrew,
>>>
>>> If that's your approach, why not create policy to create one class of
>>> user, and remove the distinction altogether?
>> I have contemplated such an approach and even drafted, about 2 years ago,
>> a post-IPV4-exhaustion policy rewrite, which collapsed the distinction
>> between ISPs and end-users.  In discussing this idea within the AC and
> other
>> community members, they believed at that time that was too much for the
>> community to handle.  The community in the past has noted that omnibus
>> style policy rewrites are generally not accepted by the larger community.
>>
>> This policy proposal is a way to start the discussion between the ISP /
> end-
>> user differences.  If the wider community support the idea of fully
> collapsing
>> the two categories, we can continue that direction.  If not, that is OK,
> too.
>>
>>> ISPs pay more because they receive
>>> more in services, and because they make money "leasing" IPs. If you
>>> make it so that ISPs can get the same set of services as end users
>>> (and start applying as end-users), then end-user fees will have to
>>> increase appropriately, in order to avoid decreasing ARIN's overall
>>> revenues. A lot of end-users will not want that, to satisfy the wants
>>> of a few very large orgs, for a service which they may even not know
>>> exists (and have no desire to use it)
>>>
>>> All I'm talking about is putting in some language to guard against
>>> obvious fraud, and keep costs down for end-users (since they
>>> presumably won't have anywhere near the ratio of SWIPs/block). It's
>>> not going to stop an ISP determined to go the end-user route, but will
>>> hopefully steer the well-meaning ISPs down the correct path and could
>>> make it easier to revoke blocks for blatent fraud.
>> Do you have any language that you'd like to see added to the draft such
> that
>> you could support it?
>>
>>> A lot of what's in the NRPM already is hard to enforce, but that
>>> doesn't stop us from trying to create policies for fair
>>> allocations/assignments, with reasonable controls. I think some plain
>>> language about what is and is not an acceptable SWIP for an end-user
>>> is appropriate. What I don't want to see if the ISP/end-user classes
>>> merging by being back-doored through a policy with no limits.
>> Some of the examples of what I thought were acceptable reassignments I
>> put in the problem statement.  Would you support those types of
>> reassignment records being allowed for end-users?
>>
>> Andrew
>>
>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>>>> On Behalf Of Andrew Dul
>>>> Sent: August 26, 2015 2:34 PM
>>>> To: arin-ppml at arin.net
>>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment
>>>> records
>>> for
>>>> IPv4 End-Users
>>>>
>>>> Shouldn't operators get to decide and be responsible for what records
>>>> they put in the database?  I understand that the potential for
>>>> mis-use of
>>> additional
>>>> reassignments, but there is already that potential for ISPs.  Do you
>>>> feel
>>> that
>>>> we need to address mis-use with ISP reassignments too?
>>>>
>>>> One could create all sorts of "schemes" to limit the ability of ISP
>>>> users
>>> to
>>>> "game" the system as end users.  Fee per reassignment record, or 10
>>>> reassignments per end-user w/ additional records costing more...
>>>>
>>>> Or maybe we just need to think about if the differences between ISPs
>>>> and end-users matter as much in a IPv4 depleted world.
>>>>
>>>> While this policy likely has downstream fee implications, it is not
>>> designed to
>>>> map to any particular fee structure.  I haven't seen any details on
>>>> any proposed fee changes so I could not take that into account when
>>>> drafting
>>> this
>>>> policy.
>>>>
>>>> Andrew
>>>>
>>>> On 8/26/2015 10:18 AM, Gary T. Giesen wrote:
>>>>> I am opposed to the policy as written.
>>>>>
>>>>> There are few to no controls on who the end user can SWIP to, which
>>>>> I think will either result in ISPs applying as end-users to game the
>>>>> system, raise the cost for end users, or both.
>>>>>
>>>>> I assume this is trying to align the NRPM to ARIN's new fee
>>>>> structure which I believe is due in September?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> GTG
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: arin-ppml-bounces at arin.net
>>>>>> [mailto:arin-ppml-bounces at arin.net]
>>>>>> On Behalf Of ARIN
>>>>>> Sent: August 25, 2015 3:12 PM
>>>>>> To: arin-ppml at arin.net
>>>>>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
>>>>>> for
>>>>> IPv4
>>>>>> End-Users
>>>>>>
>>>>>> Draft Policy ARIN-2015-8
>>>>>> Reassignment records for IPv4 End-Users
>>>>>>
>>>>>> On 20 August 2015 the ARIN Advisory Council (AC) accepted
>>>>>> "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a Draft
>>>> Policy.
>>>>>> Draft Policy ARIN-2015-8 is below and can be found at:
>>>>>> https://www.arin.net/policy/proposals/2015_8.html
>>>>>>
>>>>>> You are encouraged to discuss the merits and your concerns of Draft
>>>>>> Policy
>>>>>> 2015-8 on the Public Policy Mailing List.
>>>>>>
>>>>>> The AC will evaluate the discussion in order to assess the
>>>>>> conformance of
>>>>> this
>>>>>> draft policy with ARIN's Principles of Internet Number Resource
>>>>>> Policy as stated in the PDP. Specifically, these principles are:
>>>>>>
>>>>>>      * Enabling Fair and Impartial Number Resource Administration
>>>>>>      * Technically Sound
>>>>>>      * Supported by the Community
>>>>>>
>>>>>> The ARIN Policy Development Process (PDP) can be found at:
>>>>>> https://www.arin.net/policy/pdp.html
>>>>>>
>>>>>> Draft Policies and Proposals under discussion can be found at:
>>>>>> https://www.arin.net/policy/proposals/index.html
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Communications and Member Services
>>>>>> American Registry for Internet Numbers (ARIN)
>>>>>>
>>>>>>
>>>>>> ## * ##
>>>>>>
>>>>>>
>>>>>> Draft Policy ARIN-2015-8
>>>>>> Reassignment records for IPv4 End-Users
>>>>>>
>>>>>> Date: 25 August 2015
>>>>>>
>>>>>> Problem statement:
>>>>>>
>>>>>> End-User Organizations do not have the ability to create
>>>>>> reassignment records in the number resource database.
>>>>>>
>>>>>> Reassignment records can be used for a number of different
>>>>>> functions which could benefit the overall desire to increase
>>>>>> database accuracy by allowing organizations to add additional details
> in
>> the database.
>>>>>> The following reasons have been noted as positive reasons to allow
>>>>>> the creation of additional records.
>>>>>> - Geolocation (allows an organization to specify a different
>>>>>> location
>>>>> within the
>>>>>> database which is used by organizations creating geo-location by IP
>>>>> address
>>>>>> databases)
>>>>>> - Subsidiary reassignment (allows an organization to note that a
>>>>>> portion
>>>>> of
>>>>>> their netblock is in use by a different subsidiary entity)
>>>>>> - Assignment to contracted parties (some organizations have
>>>>>> contracts with other organizations which are operating networks
>>>>>> under agreements with the registrant, this allows the top-level
>>>>>> organizations to accurately
>>>>> specify the
>>>>>> organization operating the network in the number resource database)
>>>>>> - More specific contact information (some organizations operate
>>>>>> large networks which don't necessarily have the same technical or
>>>>>> abuse contact
>>>>>> information)
>>>>>>
>>>>>> Policy statement:
>>>>>>
>>>>>> Create new section 4.3.x
>>>>>>
>>>>>> End-user organizations which have an active registration services
>>>>> agreement
>>>>>> shall be permitted to create reassignment records in the number
>>>>>> resource database. Organizations shall use the guidelines outlined
>>>>>> in section 4.2.3 when creating reassignment records.
>>>>>>
>>>>>> Comments:
>>>>>> a. Timetable for implementation: immediately b. Anything else:
>>>>>>
>>>>>> It is noted by the author of this policy proposal that one of the
>>>>> distinctions in
>>>>>> the service between ISPs and End-Users has been the ability for an
>>>>>> organization to create reassignment records.
>>>>>>
>>>>>> This policy proposal stretches across responsibilities areas as it
>>>>>> impacts number policy, ARIN operational practice, and fees.
>>>>>>
>>>>>> Below we have noted the three areas and the different
>> responsibilities:
>>>>>> A) Providing reassignment support for end-user assignments, for
>>>>>> those who wish to use it
>>>>>>
>>>>>> This is an ARIN Service issue - could be an suggestion/consultation
>>>>> process,
>>>>>> so long as any implied additional workload/cost can be accommodated
>>>>>> in budget and the community supports
>>>>>>
>>>>>> B) New requirement on end-users to provide reassignment
>> information
>>>>>> in certain circumstances so that ARIN will treat their usage
>>>>>> assertion
>>>>> credibly
>>>>>> This is a policy issue. These requirements should be vetted through
>>>>>> the
>>>>> policy
>>>>>> development process.
>>>>>>
>>>>>> C) Fee Implications of ISPs moving to end-user category
>>>>>>
>>>>>> This is Board issue, but first requires a community discussion or
>>>>> consultation
>>>>>> to be held to solicit community input on desired outcome.
>>>>>> _______________________________________________
>>>>>> PPML
>>>>>> You are receiving this message because you are subscribed to the
>>>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>>> Please contact info at arin.net if you experience any issues.
>>>>> _______________________________________________
>>>>> PPML
>>>>> You are receiving this message because you are subscribed to the
>>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>> Please contact info at arin.net if you experience any issues.
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to the ARIN
>>>> Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.



From ggiesen at giesen.me  Fri Aug 28 13:56:30 2015
From: ggiesen at giesen.me (Gary T. Giesen)
Date: Fri, 28 Aug 2015 13:56:30 -0400
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for
	IPv4 End-Users
In-Reply-To: <55E09EF1.5070206@quark.net>
References: <55DCBE0D.8010802@arin.net>	<009201d0e023$42c24710$c846d530$@giesen.me>	<55DE0687.4010601@quark.net>	<009901d0e032$8e745680$ab5d0380$@giesen.me>	<55DF3CED.6050607@quark.net>	<031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me>
	<55E09EF1.5070206@quark.net>
Message-ID: <031e01d0e1ba$dedc4a90$9c94dfb0$@giesen.me>

Andrew,

Not to beat a dead horse, but I think if an org wants to (or is required to)
make assignments to entities that don't fit that definition, then they
should apply for an ISP block (or have their existing block converted) and
pay the appropriate fees, and allow the rest of us to keep end-user fees
low.

Cheers,

GTG

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Andrew Dul
> Sent: August 28, 2015 1:49 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
for
> IPv4 End-Users
> 
> I believe there is value in allowing end-users to add reassignments for
> organizations which they don't wholly control.  Gary, I think we will have
to
> just agree to disagree on that point.  I think your definition fits with
what you
> are hoping for, thanks for the text.
> 
> Andrew
> 
> On 8/28/2015 9:59 AM, Gary T. Giesen wrote:
> > I'd suggest something like this to define which entities reassignments
> > can be performed to:
> >
> > 1) A business department, division or sector which is not legally
> > distinct from address space holder
> > 2) A subsidiary of the address space holder, where the parent has a
> > controlling interest
> > 3) A sister company of the address space holder, where the parent
> > company of the address space holder holds a controlling interest in
> > both daughter companies
> >
> > Of course, since I am neither a lawyer nor an expert in corporate
> > structures this should be reviewed by legal, but my basic intention is
> > that there be a single, common ownership between the address holder
> > and the reassignees. I included #3 because there may be a subsidiary
> > which handles IT/network services for its sister companies.
> >
> > Cheers,
> >
> > GTG
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> >> On Behalf Of Andrew Dul
> >> Sent: August 27, 2015 12:38 PM
> >> To: Gary T. Giesen; arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment
> >> records
> > for
> >> IPv4 End-Users
> >>
> >>
> >> On 8/26/2015 12:08 PM, Gary T. Giesen wrote:
> >>> Andrew,
> >>>
> >>> If that's your approach, why not create policy to create one class
> >>> of user, and remove the distinction altogether?
> >> I have contemplated such an approach and even drafted, about 2 years
> >> ago, a post-IPV4-exhaustion policy rewrite, which collapsed the
> >> distinction between ISPs and end-users.  In discussing this idea
> >> within the AC and
> > other
> >> community members, they believed at that time that was too much for
> >> the community to handle.  The community in the past has noted that
> >> omnibus style policy rewrites are generally not accepted by the larger
> community.
> >>
> >> This policy proposal is a way to start the discussion between the ISP
> >> /
> > end-
> >> user differences.  If the wider community support the idea of fully
> > collapsing
> >> the two categories, we can continue that direction.  If not, that is
> >> OK,
> > too.
> >>
> >>> ISPs pay more because they receive
> >>> more in services, and because they make money "leasing" IPs. If you
> >>> make it so that ISPs can get the same set of services as end users
> >>> (and start applying as end-users), then end-user fees will have to
> >>> increase appropriately, in order to avoid decreasing ARIN's overall
> >>> revenues. A lot of end-users will not want that, to satisfy the
> >>> wants of a few very large orgs, for a service which they may even
> >>> not know exists (and have no desire to use it)
> >>>
> >>> All I'm talking about is putting in some language to guard against
> >>> obvious fraud, and keep costs down for end-users (since they
> >>> presumably won't have anywhere near the ratio of SWIPs/block). It's
> >>> not going to stop an ISP determined to go the end-user route, but
> >>> will hopefully steer the well-meaning ISPs down the correct path and
> >>> could make it easier to revoke blocks for blatent fraud.
> >> Do you have any language that you'd like to see added to the draft
> >> such
> > that
> >> you could support it?
> >>
> >>> A lot of what's in the NRPM already is hard to enforce, but that
> >>> doesn't stop us from trying to create policies for fair
> >>> allocations/assignments, with reasonable controls. I think some
> >>> plain language about what is and is not an acceptable SWIP for an
> >>> end-user is appropriate. What I don't want to see if the
> >>> ISP/end-user classes merging by being back-doored through a policy
> with no limits.
> >> Some of the examples of what I thought were acceptable reassignments
> >> I put in the problem statement.  Would you support those types of
> >> reassignment records being allowed for end-users?
> >>
> >> Andrew
> >>
> >>>> -----Original Message-----
> >>>> From: arin-ppml-bounces at arin.net
> >>>> [mailto:arin-ppml-bounces at arin.net]
> >>>> On Behalf Of Andrew Dul
> >>>> Sent: August 26, 2015 2:34 PM
> >>>> To: arin-ppml at arin.net
> >>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment
> >>>> records
> >>> for
> >>>> IPv4 End-Users
> >>>>
> >>>> Shouldn't operators get to decide and be responsible for what
> >>>> records they put in the database?  I understand that the potential
> >>>> for mis-use of
> >>> additional
> >>>> reassignments, but there is already that potential for ISPs.  Do
> >>>> you feel
> >>> that
> >>>> we need to address mis-use with ISP reassignments too?
> >>>>
> >>>> One could create all sorts of "schemes" to limit the ability of ISP
> >>>> users
> >>> to
> >>>> "game" the system as end users.  Fee per reassignment record, or 10
> >>>> reassignments per end-user w/ additional records costing more...
> >>>>
> >>>> Or maybe we just need to think about if the differences between
> >>>> ISPs and end-users matter as much in a IPv4 depleted world.
> >>>>
> >>>> While this policy likely has downstream fee implications, it is not
> >>> designed to
> >>>> map to any particular fee structure.  I haven't seen any details on
> >>>> any proposed fee changes so I could not take that into account when
> >>>> drafting
> >>> this
> >>>> policy.
> >>>>
> >>>> Andrew
> >>>>
> >>>> On 8/26/2015 10:18 AM, Gary T. Giesen wrote:
> >>>>> I am opposed to the policy as written.
> >>>>>
> >>>>> There are few to no controls on who the end user can SWIP to,
> >>>>> which I think will either result in ISPs applying as end-users to
> >>>>> game the system, raise the cost for end users, or both.
> >>>>>
> >>>>> I assume this is trying to align the NRPM to ARIN's new fee
> >>>>> structure which I believe is due in September?
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> GTG
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: arin-ppml-bounces at arin.net
> >>>>>> [mailto:arin-ppml-bounces at arin.net]
> >>>>>> On Behalf Of ARIN
> >>>>>> Sent: August 25, 2015 3:12 PM
> >>>>>> To: arin-ppml at arin.net
> >>>>>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment
> >>>>>> records for
> >>>>> IPv4
> >>>>>> End-Users
> >>>>>>
> >>>>>> Draft Policy ARIN-2015-8
> >>>>>> Reassignment records for IPv4 End-Users
> >>>>>>
> >>>>>> On 20 August 2015 the ARIN Advisory Council (AC) accepted
> >>>>>> "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a
> >>>>>> Draft
> >>>> Policy.
> >>>>>> Draft Policy ARIN-2015-8 is below and can be found at:
> >>>>>> https://www.arin.net/policy/proposals/2015_8.html
> >>>>>>
> >>>>>> You are encouraged to discuss the merits and your concerns of
> >>>>>> Draft Policy
> >>>>>> 2015-8 on the Public Policy Mailing List.
> >>>>>>
> >>>>>> The AC will evaluate the discussion in order to assess the
> >>>>>> conformance of
> >>>>> this
> >>>>>> draft policy with ARIN's Principles of Internet Number Resource
> >>>>>> Policy as stated in the PDP. Specifically, these principles are:
> >>>>>>
> >>>>>>      * Enabling Fair and Impartial Number Resource Administration
> >>>>>>      * Technically Sound
> >>>>>>      * Supported by the Community
> >>>>>>
> >>>>>> The ARIN Policy Development Process (PDP) can be found at:
> >>>>>> https://www.arin.net/policy/pdp.html
> >>>>>>
> >>>>>> Draft Policies and Proposals under discussion can be found at:
> >>>>>> https://www.arin.net/policy/proposals/index.html
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Communications and Member Services American Registry for
> Internet
> >>>>>> Numbers (ARIN)
> >>>>>>
> >>>>>>
> >>>>>> ## * ##
> >>>>>>
> >>>>>>
> >>>>>> Draft Policy ARIN-2015-8
> >>>>>> Reassignment records for IPv4 End-Users
> >>>>>>
> >>>>>> Date: 25 August 2015
> >>>>>>
> >>>>>> Problem statement:
> >>>>>>
> >>>>>> End-User Organizations do not have the ability to create
> >>>>>> reassignment records in the number resource database.
> >>>>>>
> >>>>>> Reassignment records can be used for a number of different
> >>>>>> functions which could benefit the overall desire to increase
> >>>>>> database accuracy by allowing organizations to add additional
> >>>>>> details
> > in
> >> the database.
> >>>>>> The following reasons have been noted as positive reasons to
> >>>>>> allow the creation of additional records.
> >>>>>> - Geolocation (allows an organization to specify a different
> >>>>>> location
> >>>>> within the
> >>>>>> database which is used by organizations creating geo-location by
> >>>>>> IP
> >>>>> address
> >>>>>> databases)
> >>>>>> - Subsidiary reassignment (allows an organization to note that a
> >>>>>> portion
> >>>>> of
> >>>>>> their netblock is in use by a different subsidiary entity)
> >>>>>> - Assignment to contracted parties (some organizations have
> >>>>>> contracts with other organizations which are operating networks
> >>>>>> under agreements with the registrant, this allows the top-level
> >>>>>> organizations to accurately
> >>>>> specify the
> >>>>>> organization operating the network in the number resource
> >>>>>> database)
> >>>>>> - More specific contact information (some organizations operate
> >>>>>> large networks which don't necessarily have the same technical or
> >>>>>> abuse contact
> >>>>>> information)
> >>>>>>
> >>>>>> Policy statement:
> >>>>>>
> >>>>>> Create new section 4.3.x
> >>>>>>
> >>>>>> End-user organizations which have an active registration services
> >>>>> agreement
> >>>>>> shall be permitted to create reassignment records in the number
> >>>>>> resource database. Organizations shall use the guidelines
> >>>>>> outlined in section 4.2.3 when creating reassignment records.
> >>>>>>
> >>>>>> Comments:
> >>>>>> a. Timetable for implementation: immediately b. Anything else:
> >>>>>>
> >>>>>> It is noted by the author of this policy proposal that one of the
> >>>>> distinctions in
> >>>>>> the service between ISPs and End-Users has been the ability for
> >>>>>> an organization to create reassignment records.
> >>>>>>
> >>>>>> This policy proposal stretches across responsibilities areas as
> >>>>>> it impacts number policy, ARIN operational practice, and fees.
> >>>>>>
> >>>>>> Below we have noted the three areas and the different
> >> responsibilities:
> >>>>>> A) Providing reassignment support for end-user assignments, for
> >>>>>> those who wish to use it
> >>>>>>
> >>>>>> This is an ARIN Service issue - could be an
> >>>>>> suggestion/consultation
> >>>>> process,
> >>>>>> so long as any implied additional workload/cost can be
> >>>>>> accommodated in budget and the community supports
> >>>>>>
> >>>>>> B) New requirement on end-users to provide reassignment
> >> information
> >>>>>> in certain circumstances so that ARIN will treat their usage
> >>>>>> assertion
> >>>>> credibly
> >>>>>> This is a policy issue. These requirements should be vetted
> >>>>>> through the
> >>>>> policy
> >>>>>> development process.
> >>>>>>
> >>>>>> C) Fee Implications of ISPs moving to end-user category
> >>>>>>
> >>>>>> This is Board issue, but first requires a community discussion or
> >>>>> consultation
> >>>>>> to be held to solicit community input on desired outcome.
> >>>>>> _______________________________________________
> >>>>>> PPML
> >>>>>> You are receiving this message because you are subscribed to the
> >>>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>>>> Unsubscribe or manage your mailing list subscription at:
> >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>>>> Please contact info at arin.net if you experience any issues.
> >>>>> _______________________________________________
> >>>>> PPML
> >>>>> You are receiving this message because you are subscribed to the
> >>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>>> Unsubscribe or manage your mailing list subscription at:
> >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>>> Please contact info at arin.net if you experience any issues.
> >>>> _______________________________________________
> >>>> PPML
> >>>> You are receiving this message because you are subscribed to the
> >>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>> Unsubscribe or manage your mailing list subscription at:
> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>> Please contact info at arin.net if you experience any issues.
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to the ARIN
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bill at tknow.com  Fri Aug 28 15:56:16 2015
From: bill at tknow.com (Bill Buhler)
Date: Fri, 28 Aug 2015 19:56:16 +0000
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
	for	IPv4 End-Users
In-Reply-To: <031e01d0e1ba$dedc4a90$9c94dfb0$@giesen.me>
References: <55DCBE0D.8010802@arin.net>
	<009201d0e023$42c24710$c846d530$@giesen.me>	<55DE0687.4010601@quark.net>
	<009901d0e032$8e745680$ab5d0380$@giesen.me>	<55DF3CED.6050607@quark.net>
	<031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me>	<55E09EF1.5070206@quark.net>
	<031e01d0e1ba$dedc4a90$9c94dfb0$@giesen.me>
Message-ID: <b2cefbbc40d84159b191c7575789a659@TK-Ex13.ad.tknow.com>

I agree with Gary, if it isn't owned they are a ISP, and should behave accordingly.

Bill Buhler
TeKnowledgy, Inc. | Curing IT headaches since 2009

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Gary T. Giesen
Sent: Friday, August 28, 2015 11:56 AM
To: andrew.dul at quark.net; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records for IPv4 End-Users

Andrew,

Not to beat a dead horse, but I think if an org wants to (or is required to) make assignments to entities that don't fit that definition, then they should apply for an ISP block (or have their existing block converted) and pay the appropriate fees, and allow the rest of us to keep end-user fees low.

Cheers,

GTG

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> On Behalf Of Andrew Dul
> Sent: August 28, 2015 1:49 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment 
> records
for
> IPv4 End-Users
> 
> I believe there is value in allowing end-users to add reassignments 
> for organizations which they don't wholly control.  Gary, I think we 
> will have
to
> just agree to disagree on that point.  I think your definition fits 
> with
what you
> are hoping for, thanks for the text.
> 
> Andrew
> 
> On 8/28/2015 9:59 AM, Gary T. Giesen wrote:
> > I'd suggest something like this to define which entities 
> > reassignments can be performed to:
> >
> > 1) A business department, division or sector which is not legally 
> > distinct from address space holder
> > 2) A subsidiary of the address space holder, where the parent has a 
> > controlling interest
> > 3) A sister company of the address space holder, where the parent 
> > company of the address space holder holds a controlling interest in 
> > both daughter companies
> >
> > Of course, since I am neither a lawyer nor an expert in corporate 
> > structures this should be reviewed by legal, but my basic intention 
> > is that there be a single, common ownership between the address 
> > holder and the reassignees. I included #3 because there may be a 
> > subsidiary which handles IT/network services for its sister companies.
> >
> > Cheers,
> >
> > GTG
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net 
> >> [mailto:arin-ppml-bounces at arin.net]
> >> On Behalf Of Andrew Dul
> >> Sent: August 27, 2015 12:38 PM
> >> To: Gary T. Giesen; arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment 
> >> records
> > for
> >> IPv4 End-Users
> >>
> >>
> >> On 8/26/2015 12:08 PM, Gary T. Giesen wrote:
> >>> Andrew,
> >>>
> >>> If that's your approach, why not create policy to create one class 
> >>> of user, and remove the distinction altogether?
> >> I have contemplated such an approach and even drafted, about 2 
> >> years ago, a post-IPV4-exhaustion policy rewrite, which collapsed 
> >> the distinction between ISPs and end-users.  In discussing this 
> >> idea within the AC and
> > other
> >> community members, they believed at that time that was too much for 
> >> the community to handle.  The community in the past has noted that 
> >> omnibus style policy rewrites are generally not accepted by the 
> >> larger
> community.
> >>
> >> This policy proposal is a way to start the discussion between the 
> >> ISP /
> > end-
> >> user differences.  If the wider community support the idea of fully
> > collapsing
> >> the two categories, we can continue that direction.  If not, that 
> >> is OK,
> > too.
> >>
> >>> ISPs pay more because they receive more in services, and because 
> >>> they make money "leasing" IPs. If you make it so that ISPs can get 
> >>> the same set of services as end users (and start applying as 
> >>> end-users), then end-user fees will have to increase 
> >>> appropriately, in order to avoid decreasing ARIN's overall 
> >>> revenues. A lot of end-users will not want that, to satisfy the 
> >>> wants of a few very large orgs, for a service which they may even 
> >>> not know exists (and have no desire to use it)
> >>>
> >>> All I'm talking about is putting in some language to guard against 
> >>> obvious fraud, and keep costs down for end-users (since they 
> >>> presumably won't have anywhere near the ratio of SWIPs/block). 
> >>> It's not going to stop an ISP determined to go the end-user route, 
> >>> but will hopefully steer the well-meaning ISPs down the correct 
> >>> path and could make it easier to revoke blocks for blatent fraud.
> >> Do you have any language that you'd like to see added to the draft 
> >> such
> > that
> >> you could support it?
> >>
> >>> A lot of what's in the NRPM already is hard to enforce, but that 
> >>> doesn't stop us from trying to create policies for fair 
> >>> allocations/assignments, with reasonable controls. I think some 
> >>> plain language about what is and is not an acceptable SWIP for an 
> >>> end-user is appropriate. What I don't want to see if the 
> >>> ISP/end-user classes merging by being back-doored through a policy
> with no limits.
> >> Some of the examples of what I thought were acceptable 
> >> reassignments I put in the problem statement.  Would you support 
> >> those types of reassignment records being allowed for end-users?
> >>
> >> Andrew
> >>
> >>>> -----Original Message-----
> >>>> From: arin-ppml-bounces at arin.net
> >>>> [mailto:arin-ppml-bounces at arin.net]
> >>>> On Behalf Of Andrew Dul
> >>>> Sent: August 26, 2015 2:34 PM
> >>>> To: arin-ppml at arin.net
> >>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment 
> >>>> records
> >>> for
> >>>> IPv4 End-Users
> >>>>
> >>>> Shouldn't operators get to decide and be responsible for what 
> >>>> records they put in the database?  I understand that the 
> >>>> potential for mis-use of
> >>> additional
> >>>> reassignments, but there is already that potential for ISPs.  Do 
> >>>> you feel
> >>> that
> >>>> we need to address mis-use with ISP reassignments too?
> >>>>
> >>>> One could create all sorts of "schemes" to limit the ability of 
> >>>> ISP users
> >>> to
> >>>> "game" the system as end users.  Fee per reassignment record, or 
> >>>> 10 reassignments per end-user w/ additional records costing more...
> >>>>
> >>>> Or maybe we just need to think about if the differences between 
> >>>> ISPs and end-users matter as much in a IPv4 depleted world.
> >>>>
> >>>> While this policy likely has downstream fee implications, it is 
> >>>> not
> >>> designed to
> >>>> map to any particular fee structure.  I haven't seen any details 
> >>>> on any proposed fee changes so I could not take that into account 
> >>>> when drafting
> >>> this
> >>>> policy.
> >>>>
> >>>> Andrew
> >>>>
> >>>> On 8/26/2015 10:18 AM, Gary T. Giesen wrote:
> >>>>> I am opposed to the policy as written.
> >>>>>
> >>>>> There are few to no controls on who the end user can SWIP to, 
> >>>>> which I think will either result in ISPs applying as end-users 
> >>>>> to game the system, raise the cost for end users, or both.
> >>>>>
> >>>>> I assume this is trying to align the NRPM to ARIN's new fee 
> >>>>> structure which I believe is due in September?
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> GTG
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: arin-ppml-bounces at arin.net 
> >>>>>> [mailto:arin-ppml-bounces at arin.net]
> >>>>>> On Behalf Of ARIN
> >>>>>> Sent: August 25, 2015 3:12 PM
> >>>>>> To: arin-ppml at arin.net
> >>>>>> Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment 
> >>>>>> records for
> >>>>> IPv4
> >>>>>> End-Users
> >>>>>>
> >>>>>> Draft Policy ARIN-2015-8
> >>>>>> Reassignment records for IPv4 End-Users
> >>>>>>
> >>>>>> On 20 August 2015 the ARIN Advisory Council (AC) accepted
> >>>>>> "ARIN-prop-222 Reassignment records for IPv4 End-Users" as a 
> >>>>>> Draft
> >>>> Policy.
> >>>>>> Draft Policy ARIN-2015-8 is below and can be found at:
> >>>>>> https://www.arin.net/policy/proposals/2015_8.html
> >>>>>>
> >>>>>> You are encouraged to discuss the merits and your concerns of 
> >>>>>> Draft Policy
> >>>>>> 2015-8 on the Public Policy Mailing List.
> >>>>>>
> >>>>>> The AC will evaluate the discussion in order to assess the 
> >>>>>> conformance of
> >>>>> this
> >>>>>> draft policy with ARIN's Principles of Internet Number Resource 
> >>>>>> Policy as stated in the PDP. Specifically, these principles are:
> >>>>>>
> >>>>>>      * Enabling Fair and Impartial Number Resource Administration
> >>>>>>      * Technically Sound
> >>>>>>      * Supported by the Community
> >>>>>>
> >>>>>> The ARIN Policy Development Process (PDP) can be found at:
> >>>>>> https://www.arin.net/policy/pdp.html
> >>>>>>
> >>>>>> Draft Policies and Proposals under discussion can be found at:
> >>>>>> https://www.arin.net/policy/proposals/index.html
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Communications and Member Services American Registry for
> Internet
> >>>>>> Numbers (ARIN)
> >>>>>>
> >>>>>>
> >>>>>> ## * ##
> >>>>>>
> >>>>>>
> >>>>>> Draft Policy ARIN-2015-8
> >>>>>> Reassignment records for IPv4 End-Users
> >>>>>>
> >>>>>> Date: 25 August 2015
> >>>>>>
> >>>>>> Problem statement:
> >>>>>>
> >>>>>> End-User Organizations do not have the ability to create 
> >>>>>> reassignment records in the number resource database.
> >>>>>>
> >>>>>> Reassignment records can be used for a number of different 
> >>>>>> functions which could benefit the overall desire to increase 
> >>>>>> database accuracy by allowing organizations to add additional 
> >>>>>> details
> > in
> >> the database.
> >>>>>> The following reasons have been noted as positive reasons to 
> >>>>>> allow the creation of additional records.
> >>>>>> - Geolocation (allows an organization to specify a different 
> >>>>>> location
> >>>>> within the
> >>>>>> database which is used by organizations creating geo-location 
> >>>>>> by IP
> >>>>> address
> >>>>>> databases)
> >>>>>> - Subsidiary reassignment (allows an organization to note that 
> >>>>>> a portion
> >>>>> of
> >>>>>> their netblock is in use by a different subsidiary entity)
> >>>>>> - Assignment to contracted parties (some organizations have 
> >>>>>> contracts with other organizations which are operating networks 
> >>>>>> under agreements with the registrant, this allows the top-level 
> >>>>>> organizations to accurately
> >>>>> specify the
> >>>>>> organization operating the network in the number resource
> >>>>>> database)
> >>>>>> - More specific contact information (some organizations operate 
> >>>>>> large networks which don't necessarily have the same technical 
> >>>>>> or abuse contact
> >>>>>> information)
> >>>>>>
> >>>>>> Policy statement:
> >>>>>>
> >>>>>> Create new section 4.3.x
> >>>>>>
> >>>>>> End-user organizations which have an active registration 
> >>>>>> services
> >>>>> agreement
> >>>>>> shall be permitted to create reassignment records in the number 
> >>>>>> resource database. Organizations shall use the guidelines 
> >>>>>> outlined in section 4.2.3 when creating reassignment records.
> >>>>>>
> >>>>>> Comments:
> >>>>>> a. Timetable for implementation: immediately b. Anything else:
> >>>>>>
> >>>>>> It is noted by the author of this policy proposal that one of 
> >>>>>> the
> >>>>> distinctions in
> >>>>>> the service between ISPs and End-Users has been the ability for 
> >>>>>> an organization to create reassignment records.
> >>>>>>
> >>>>>> This policy proposal stretches across responsibilities areas as 
> >>>>>> it impacts number policy, ARIN operational practice, and fees.
> >>>>>>
> >>>>>> Below we have noted the three areas and the different
> >> responsibilities:
> >>>>>> A) Providing reassignment support for end-user assignments, for 
> >>>>>> those who wish to use it
> >>>>>>
> >>>>>> This is an ARIN Service issue - could be an 
> >>>>>> suggestion/consultation
> >>>>> process,
> >>>>>> so long as any implied additional workload/cost can be 
> >>>>>> accommodated in budget and the community supports
> >>>>>>
> >>>>>> B) New requirement on end-users to provide reassignment
> >> information
> >>>>>> in certain circumstances so that ARIN will treat their usage 
> >>>>>> assertion
> >>>>> credibly
> >>>>>> This is a policy issue. These requirements should be vetted 
> >>>>>> through the
> >>>>> policy
> >>>>>> development process.
> >>>>>>
> >>>>>> C) Fee Implications of ISPs moving to end-user category
> >>>>>>
> >>>>>> This is Board issue, but first requires a community discussion 
> >>>>>> or
> >>>>> consultation
> >>>>>> to be held to solicit community input on desired outcome.
> >>>>>> _______________________________________________
> >>>>>> PPML
> >>>>>> You are receiving this message because you are subscribed to 
> >>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>>>> Unsubscribe or manage your mailing list subscription at:
> >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>>>> Please contact info at arin.net if you experience any issues.
> >>>>> _______________________________________________
> >>>>> PPML
> >>>>> You are receiving this message because you are subscribed to the 
> >>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>>> Unsubscribe or manage your mailing list subscription at:
> >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>>> Please contact info at arin.net if you experience any issues.
> >>>> _______________________________________________
> >>>> PPML
> >>>> You are receiving this message because you are subscribed to the 
> >>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>>> Unsubscribe or manage your mailing list subscription at:
> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> >>>> Please contact info at arin.net if you experience any issues.
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to the 
> >> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage 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  Fri Aug 28 16:05:30 2015
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Aug 2015 20:05:30 +0000
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
	for	IPv4 End-Users
In-Reply-To: <031e01d0e1ba$dedc4a90$9c94dfb0$@giesen.me>
References: <55DCBE0D.8010802@arin.net>
	<009201d0e023$42c24710$c846d530$@giesen.me>
	<55DE0687.4010601@quark.net>
	<009901d0e032$8e745680$ab5d0380$@giesen.me>
	<55DF3CED.6050607@quark.net>
	<031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me>
	<55E09EF1.5070206@quark.net>
	<031e01d0e1ba$dedc4a90$9c94dfb0$@giesen.me>
Message-ID: <4AD333A0-C403-4A6F-84EF-11ED5A949597@corp.arin.net>

On Aug 28, 2015, at 1:56 PM, Gary T. Giesen <ggiesen at giesen.me> wrote:
> Not to beat a dead horse, but I think if an org wants to (or is required to)
> make assignments to entities that don't fit that definition, then they
> should apply for an ISP block (or have their existing block converted) and
> pay the appropriate fees, and allow the rest of us to keep end-user fees
> low.

We have had a handful of organizations switch from end-user to ISP for the
purposes of being able to put in reassignment records (e.g. to improve the
usefulness of geolocation), but it is almost certain that others having avoided
such a change due to the cost implications.

In the end, the community has to consider the indirect financial benefit vs the 
implied reduction in usefulness of the registry that results when parties seek
to avoid paying same.

Thanks,
/John

John Curran
President and CEO
ARIN



From ggiesen at giesen.me  Fri Aug 28 16:15:52 2015
From: ggiesen at giesen.me (Gary T. Giesen)
Date: Fri, 28 Aug 2015 16:15:52 -0400
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment
	records	for	IPv4 End-Users
In-Reply-To: <4AD333A0-C403-4A6F-84EF-11ED5A949597@corp.arin.net>
References: <55DCBE0D.8010802@arin.net>	<009201d0e023$42c24710$c846d530$@giesen.me>	<55DE0687.4010601@quark.net>	<009901d0e032$8e745680$ab5d0380$@giesen.me>	<55DF3CED.6050607@quark.net>	<031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me>	<55E09EF1.5070206@quark.net>	<031e01d0e1ba$dedc4a90$9c94dfb0$@giesen.me>
	<4AD333A0-C403-4A6F-84EF-11ED5A949597@corp.arin.net>
Message-ID: <034d01d0e1ce$56f258e0$04d70aa0$@giesen.me>

John,

And if every ISP starts becoming an end-user because they can now submit
reassignment records and ARIN goes broke because they've lost X% (X = not
insignificant) of their revenue, how useful will the registry be then?

I'm supportive of reassignment records for end users, for things like better
geolocation, dividing between their departments, facilitating usage
counting, etc. But if they are reselling them they are an ISP and should
bear the cost of that rather than pushing it down to other end users who are
not directly deriving revenue from limited IP resources.

 My $0.02 (and then some)

Cheers,

GTG

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of John Curran
> Sent: August 28, 2015 4:06 PM
> To: Gary T. Giesen; Andrew Dul
> Cc: arin-ppml at arin.net List
> Subject: Re: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment records
for
> IPv4 End-Users
> 
> On Aug 28, 2015, at 1:56 PM, Gary T. Giesen <ggiesen at giesen.me> wrote:
> > Not to beat a dead horse, but I think if an org wants to (or is
> > required to) make assignments to entities that don't fit that
> > definition, then they should apply for an ISP block (or have their
> > existing block converted) and pay the appropriate fees, and allow the
> > rest of us to keep end-user fees low.
> 
> We have had a handful of organizations switch from end-user to ISP for the
> purposes of being able to put in reassignment records (e.g. to improve the
> usefulness of geolocation), but it is almost certain that others having
avoided
> such a change due to the cost implications.
> 
> In the end, the community has to consider the indirect financial benefit
vs
> the implied reduction in usefulness of the registry that results when
parties
> seek to avoid paying same.
> 
> Thanks,
> /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  Fri Aug 28 16:46:51 2015
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Aug 2015 20:46:51 +0000
Subject: [arin-ppml] Draft Policy ARIN-2015-8: Reassignment
	records	for	IPv4 End-Users
In-Reply-To: <034d01d0e1ce$56f258e0$04d70aa0$@giesen.me>
References: <55DCBE0D.8010802@arin.net>
	<009201d0e023$42c24710$c846d530$@giesen.me>
	<55DE0687.4010601@quark.net>
	<009901d0e032$8e745680$ab5d0380$@giesen.me>
	<55DF3CED.6050607@quark.net>
	<031c01d0e1b2$e4b0e190$ae12a4b0$@giesen.me>
	<55E09EF1.5070206@quark.net>
	<031e01d0e1ba$dedc4a90$9c94dfb0$@giesen.me>
	<4AD333A0-C403-4A6F-84EF-11ED5A949597@corp.arin.net>
	<034d01d0e1ce$56f258e0$04d70aa0$@giesen.me>
Message-ID: <430214D4-3251-4A1B-A442-A39D6ACF3A81@arin.net>

On Aug 28, 2015, at 4:15 PM, Gary T. Giesen <ggiesen at giesen.me> wrote:
> 
> John,
> 
> And if every ISP starts becoming an end-user because they can now submit
> reassignment records and ARIN goes broke because they've lost X% (X = not
> insignificant) of their revenue, how useful will the registry be then?

Gary -

While that is a theoretical possibility, it is an extremely unlikely outcome?
(i.e. ?ARIN goes broke? presumes not only that staff is not performing correct
financial planning, but that the ARIN Board is remiss in noticing and addressing
the situation ? this would be quite surprising given their record of ample attention 
to ARIN?s financial well being...)

With respect to cost-recovery, it is important to note that there is a not a direct 
relation such that ISP == large and End-User == small, so in environment where 
the services (and fees) are the same for end-users and ISPs, we would either
have a uniform fees for all, or would have to rely upon the size distinction to 
recover more from larger entities (whether ISP or end-user) so that smaller 
entities could have significantly smaller fees.   

(I have no idea if this is a desirable outcome, that?s for the community to 
consider, but it is certainly a manageable situation if we?re told to head in
that direction.)

> I'm supportive of reassignment records for end users, for things like better
> geolocation, dividing between their departments, facilitating usage
> counting, etc. But if they are reselling them they are an ISP and should
> bear the cost of that rather than pushing it down to other end users who are
> not directly deriving revenue from limited IP resources.

That?s a very clear expression of your position and reasoning - thanks!
/John




From alfeh at me.com  Fri Aug 28 16:53:18 2015
From: alfeh at me.com (Alfie Cleveland)
Date: Fri, 28 Aug 2015 21:53:18 +0100
Subject: [arin-ppml] ARIN-PPML Digest, Vol 122, Issue 28
In-Reply-To: <mailman.21766.1440794818.4627.arin-ppml@arin.net>
References: <mailman.21766.1440794818.4627.arin-ppml@arin.net>
Message-ID: <ADEC7684-463E-48F0-B67C-B878DF5B4B21@me.com>

Hey,

With IPv4 reaching exhaustion most likely within the next 10 days, ISPs applying for space as an End-User instead of an ISP really isn?t as much of a concern, due to the fact that there will be no IPs to give them. It?s simple - we can just disallow people to change from ISP to End-User space without a very good reason. Or, make it only possible for End-Users to assign x space - for example I?d recommend only allowing them to assign /25s and higher.

Regards,
Alfie