From jschiller at google.com  Wed Jun  1 08:42:31 2016
From: jschiller at google.com (Jason Schiller)
Date: Wed, 1 Jun 2016 08:42:31 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
 (Inter-RIR Transfers to Specified Recipients)
In-Reply-To: <5744C66C.8050204@arin.net>
References: <5744C66C.8050204@arin.net>
Message-ID: <CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>

I support as written.

However it occurs to me, why doesn't this text also apply to 8.3 intra-ARIN
specified transfers?

1. I see no reason why intra-compnay transfers where the recipient is
outside of the ARIN region, be treated any differently than when the
recipient is inside the ARIN region.

2. In fact I think if anything we would want to be equally or more liberal
when the recipient is inside the ARIN region to have a greater chance of
enforcing anti-flip restrictions (which we cannot easily do outside of the
region).

3. I would like to avoid further diverging 8.3 and 8.4.  One could imagine
merging 8.3 and 8.4 into a single section, and the community has asked the
AC to undertake that work.

___Jason

On Tue, May 24, 2016 at 5:23 PM, ARIN <info at arin.net> wrote:

>
> Recommended Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to
> Specified Recipients)
>
> On 19 May 2016 the ARIN Advisory Council (AC) advanced 2015-2 to
> Recommended Draft Policy status.
>
> The text of the Recommended Draft Policy is below, and may also be found
> at:
> https://www.arin.net/policy/proposals/2015_2.html
>
> You are encouraged to discuss all Recommended Draft Policies on PPML prior
> to their presentation at the next ARIN Public Policy Consultation (PPC).
> PPML and PPC discussions are invaluable to the AC when determining
> community consensus.
>
> The 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)
>
>
>
> Recommended Draft Policy ARIN 2015-2
> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>
> Date: 24 May 2016
>
> AC's assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> Draft Policy ARIN 2015-2 contributes to fair and impartial number
> resources administration by removing an impediment to the transfer of IPv4
> numbering resources to other RIRs when business needs change within the
> first 12 months of receipt of a 24 month supply of IP addresses by an
> entity via the transfer market. It is technically sound in that it balances
> removing limits on transfers of IPv4 numbering resources to other RIRs with
> safeguards related to ownership and control described in the draft policy
> to reduce the likelihood of fraudulent transactions. There was strong
> community support for this draft policy at the NANOG 66 PPC and ARIN 37,
> subject only to some suggested editorial changes which have now been
> implemented in the latest version.
>
> Problem Statement:
>
> Organizations that obtain a 24 month supply of IP addresses via the
> transfer market and then have an unexpected change in business plan are
> unable to move IP addresses to the proper RIR within the first 12 months of
> receipt.
>
> Policy statement:
>
> Replace 8.4, bullet 4, to read:
>
> "Source entities within the ARIN region must not have received a transfer,
> allocation, or assignment of IPv4 number resources from ARIN for the 12
> months prior to the approval of a transfer request, unless either the
> source or recipient entity owns or controls the other, or both are under
> common ownership or control. This restriction does not include M&A
> transfers."
>
> Comments: Organizations that obtain a 24 month supply of IP addresses via
> the transfer market and then have an unexpected change in business plan are
> unable to move IP addresses to the proper RIR within the first 12 months of
> receipt. The need to move the resources does not flow from ARIN policy, but
> rather from the requirement of certain registries outside the ARIN region
> to have the resources moved in order to be used there.
>
> The intention of this change is to allow organizations to perform
> inter-RIR transfers of space received via an 8.3 transfer regardless of the
> date transferred to ARIN. A common example is that an organization acquires
> a block located in the ARIN region, transfers it to ARIN, then 3 months
> later, the organization announces that it wants to launch new services out
> of region. Under current policy, the organization is prohibited from moving
> some or all of those addresses to that region's Whois if there is a need to
> move them to satisfy the rules of the other region requiring the movement
> of the resources to that region in order for them to be used there.
> Instead, the numbers are locked in ARIN's Whois. It's important to note
> that 8.3 transfers are approved for a 24 month supply, and it would not be
> unheard of for a business model to change within the first 12 months after
> approval. The proposal also introduces a requirement for an affiliation
> relationship between the source and recipient entity, based on established
> corporate law principles, so as to make it reasonably likely that
> eliminating the 12 month anti-flip period in that situation will meet the
> needs of organizations that operate networks in more than one region
> without encouraging abuse.
>
> a. Timetable for implementation: Immediate
>
> b. Anything else: N/A
>
> #####
>
> ARIN STAFF & LEGAL ASSESSMENT
> Draft Policy ARIN-2015-2
> MODIFY 8.4 (INTER-RIR TRANSFERS TO SPECIFIED RECIPIENTS)
> https://www.arin.net/policy/proposals/2015_2.html
>
> Date of Assessment: 17 May 2016
>
> ___
> 1. Summary (Staff Understanding)
>
> Currently, organizations are unable to act as a source on an 8.4 transfer
> of IPv4 address space if they have received IPv4 address space in the past
> 12 months from ARIN's IPv4 free pool, the waiting list for unmet requests,
> or an 8.3 transfer. This draft policy lifts the 12-month restriction in
> cases when the source or recipient entity owns or controls the other, or
> both are under common ownership or control.
>
> ___
> 2. Comments
>
> A. ARIN Staff Comments
>
> * If this policy is implemented, ARIN staff would no longer apply a
> 12-month time restriction to organizations who wish to 8.4 transfer IPv4
> addresses to themselves or in cases when the source or recipient entity
> owns or controls the other, or both are under common ownership or control.
>
> * This policy could be implemented as written.
>
> B. ARIN General Counsel ? Legal Assessment
>
> Concerns raised by the GC regarding previous versions of this policy have
> been satisfactorily addressed in the current draft. The current proposed
> draft does not create material legal issues for ARIN. In order to determine
> when entities are under common ownership or control, traditional legal
> standards will be applied by ARIN.
>
> ___
> 3. Resource Impact
>
> Implementation of this policy would have minimal resource impact. It is
> estimated that implementation would occur within 3 months after
> ratification by the ARIN Board of Trustees. The following would be needed
> in order to implement:
>
> * Updated guidelines and internal procedures
>
> * Staff training
>
> ___
> 4. Proposal / Draft Policy Text Assessed
>
> Draft Policy ARIN 2015-2
> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>
> Date: 11 May 2016
>
> Problem Statement:
>
> Organizations that obtain a 24 month supply of IP addresses via the
> transfer market and then have an unexpected change in business plan are
> unable to move IP addresses to the proper RIR within the first 12 months of
> receipt.
>
> Policy statement:
>
> Replace 8.4, bullet 4, to read: "Source entities within the ARIN region
> must not have received a transfer, allocation, or assignment of IPv4 number
> resources from ARIN for the 12 months prior to the approval of a transfer
> request, unless either the source or recipient entity owns or controls the
> other, or both are under common ownership or control. This restriction does
> not include M&A transfers."
>
> Comments: Organizations that obtain a 24 month supply of IP addresses via
> the transfer market and then have an unexpected change in business plan are
> unable to move IP addresses to the proper RIR within the first 12 months of
> receipt. The need to move the resources does not flow from ARIN policy, but
> rather from the requirement of certain registries outside the ARIN region
> to have the resources moved in order to be used there.
>
> The intention of this change is to allow organizations to perform
> inter-RIR transfers of space received via an 8.3 transfer regardless of the
> date transferred to ARIN. A common example is that an organization acquires
> a block located in the ARIN region, transfers it to ARIN, then 3 months
> later, the organization announces that it wants to launch new services out
> of region. Under current policy, the organization is prohibited from moving
> some or all of those addresses to that region's Whois if there is a need to
> move them to satisfy the rules of the other region requiring the movement
> of the resources to that region in order for them to be used there.
> Instead, the numbers are locked in ARIN's Whois. It's important to note
> that 8.3 transfers are approved for a 24 month supply, and it would not be
> unheard of for a business model to change within the first 12 months after
> approval. The proposal also introduces a requirement for an affiliation
> relationship between the source and recipient entity, based on established
> corporate law principles, so as to make it reasonably likely that
> eliminating the 12 month anti-flip period in that situation will meet the
> needs of organizations that operate networks in more than one region
> without encouraging abuse.
>
> a. Timetable for implementation: Immediate
> b. Anything else: N/A
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20160601/bcf20de4/attachment.htm>

From daveid at panix.com  Wed Jun  1 09:04:04 2016
From: daveid at panix.com (David Huberman)
Date: Wed, 1 Jun 2016 08:04:04 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
	(Inter-RIR Transfers to Specified Recipients)
In-Reply-To: <CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>
References: <5744C66C.8050204@arin.net>
	<CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>
Message-ID: <025E3E2D-6DCA-4B77-AF60-35C391A60256@panix.com>

What real scenario are you thinking of that involves in-region companies that isn't an 8.3?  I'm an American and my familiarity with American corporate law and resulting structures is having a hard time thinking of a scenario.  But maybe it's just early and I haven't had my hot chocolate yet :)



> On Jun 1, 2016, at 7:42 AM, Jason Schiller <jschiller at google.com> wrote:
> 
> I support as written.
> 
> However it occurs to me, why doesn't this text also apply to 8.3 intra-ARIN specified transfers?
> 
> 1. I see no reason why intra-compnay transfers where the recipient is outside of the ARIN region, be treated any differently than when the recipient is inside the ARIN region.
> 
> 2. In fact I think if anything we would want to be equally or more liberal when the recipient is inside the ARIN region to have a greater chance of enforcing anti-flip restrictions (which we cannot easily do outside of the region).
> 
> 3. I would like to avoid further diverging 8.3 and 8.4.  One could imagine merging 8.3 and 8.4 into a single section, and the community has asked the AC to undertake that work.
> 
> ___Jason
> 
>> On Tue, May 24, 2016 at 5:23 PM, ARIN <info at arin.net> wrote:
>> 
>> Recommended Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>> 
>> On 19 May 2016 the ARIN Advisory Council (AC) advanced 2015-2 to Recommended Draft Policy status.
>> 
>> The text of the Recommended Draft Policy is below, and may also be found at:
>> https://www.arin.net/policy/proposals/2015_2.html
>> 
>> You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus.
>> 
>> The 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)
>> 
>> 
>> 
>> Recommended Draft Policy ARIN 2015-2
>> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>> 
>> Date: 24 May 2016
>> 
>> AC's assessment of conformance with the Principles of Internet Number Resource Policy:
>> 
>> Draft Policy ARIN 2015-2 contributes to fair and impartial number resources administration by removing an impediment to the transfer of IPv4 numbering resources to other RIRs when business needs change within the first 12 months of receipt of a 24 month supply of IP addresses by an entity via the transfer market. It is technically sound in that it balances removing limits on transfers of IPv4 numbering resources to other RIRs with safeguards related to ownership and control described in the draft policy to reduce the likelihood of fraudulent transactions. There was strong community support for this draft policy at the NANOG 66 PPC and ARIN 37, subject only to some suggested editorial changes which have now been implemented in the latest version.
>> 
>> Problem Statement:
>> 
>> Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt.
>> 
>> Policy statement:
>> 
>> Replace 8.4, bullet 4, to read:
>> 
>> "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request, unless either the source or recipient entity owns or controls the other, or both are under common ownership or control. This restriction does not include M&A transfers."
>> 
>> Comments: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. The need to move the resources does not flow from ARIN policy, but rather from the requirement of certain registries outside the ARIN region to have the resources moved in order to be used there.
>> 
>> The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois if there is a need to move them to satisfy the rules of the other region requiring the movement of the resources to that region in order for them to be used there. Instead, the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse.
>> 
>> a. Timetable for implementation: Immediate
>> 
>> b. Anything else: N/A
>> 
>> #####
>> 
>> ARIN STAFF & LEGAL ASSESSMENT
>> Draft Policy ARIN-2015-2
>> MODIFY 8.4 (INTER-RIR TRANSFERS TO SPECIFIED RECIPIENTS)
>> https://www.arin.net/policy/proposals/2015_2.html
>> 
>> Date of Assessment: 17 May 2016
>> 
>> ___
>> 1. Summary (Staff Understanding)
>> 
>> Currently, organizations are unable to act as a source on an 8.4 transfer of IPv4 address space if they have received IPv4 address space in the past 12 months from ARIN's IPv4 free pool, the waiting list for unmet requests, or an 8.3 transfer. This draft policy lifts the 12-month restriction in cases when the source or recipient entity owns or controls the other, or both are under common ownership or control.
>> 
>> ___
>> 2. Comments
>> 
>> A. ARIN Staff Comments
>> 
>> * If this policy is implemented, ARIN staff would no longer apply a 12-month time restriction to organizations who wish to 8.4 transfer IPv4 addresses to themselves or in cases when the source or recipient entity owns or controls the other, or both are under common ownership or control.
>> 
>> * This policy could be implemented as written.
>> 
>> B. ARIN General Counsel ? Legal Assessment
>> 
>> Concerns raised by the GC regarding previous versions of this policy have been satisfactorily addressed in the current draft. The current proposed draft does not create material legal issues for ARIN. In order to determine when entities are under common ownership or control, traditional legal standards will be applied by ARIN.
>> 
>> ___
>> 3. Resource Impact
>> 
>> Implementation of this policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement:
>> 
>> * Updated guidelines and internal procedures
>> 
>> * Staff training
>> 
>> ___
>> 4. Proposal / Draft Policy Text Assessed
>> 
>> Draft Policy ARIN 2015-2
>> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>> 
>> Date: 11 May 2016
>> 
>> Problem Statement:
>> 
>> Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt.
>> 
>> Policy statement:
>> 
>> Replace 8.4, bullet 4, to read: "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request, unless either the source or recipient entity owns or controls the other, or both are under common ownership or control. This restriction does not include M&A transfers."
>> 
>> Comments: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. The need to move the resources does not flow from ARIN policy, but rather from the requirement of certain registries outside the ARIN region to have the resources moved in order to be used there.
>> 
>> The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois if there is a need to move them to satisfy the rules of the other region requiring the movement of the resources to that region in order for them to be used there. Instead, the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse.
>> 
>> a. Timetable for implementation: Immediate
>> b. Anything else: N/A
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20160601/802dbb66/attachment.htm>

From jschiller at google.com  Wed Jun  1 09:39:52 2016
From: jschiller at google.com (Jason Schiller)
Date: Wed, 1 Jun 2016 09:39:52 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
 (Inter-RIR Transfers to Specified Recipients)
In-Reply-To: <025E3E2D-6DCA-4B77-AF60-35C391A60256@panix.com>
References: <5744C66C.8050204@arin.net>
	<CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>
	<025E3E2D-6DCA-4B77-AF60-35C391A60256@panix.com>
Message-ID: <CAC4yj2US3aN9FW0raw5dga11U+_QrzP6imBbg1CX3Tjf6cR+pw@mail.gmail.com>

My understanding of the problem is that company A is selling a /16.
Company B buys the /16.

After 3 months, company B finds their projected usage of the IP space
is no longer needed because their product was canceled, but a
European division of company B has need of them.

Under current policy company B cannot transfer the address space
to their european division because:

1. the source is ineligible for another 9 months because they recently
received a transfer.

2. the recipient is ineligible because RIPE does not have a compatible
needs based policy (maybe this has changed).

This policy would permit the transfer.

Now instead imagine company B has multiple OrgIDs, one for dial-up,
one for dedicated customers, etc.  They recently decided to have a
cloud offering, and spun up a new OrgID (under the same legal entity)
and transfered the /16 for their new cloud offering.

The cloud product fizzles after 3 months, but there is justified need for
the /16 in part by the dial-up customers and in part by dedicated
customers.  To properly reflect the usage of the space part of the /16
needs to be moved to the dial-up OrgID, and the rest to the dedicated
OrgId.

Same scenario, but instead of one company with multiple OrgIds, it is
one company with multiple wholly owned subsidiaries, each of which
have their own OrgID.

I believe 8.2 does not apply unless there was some corporate
restructuring.

___Jason

On Wed, Jun 1, 2016 at 9:04 AM, David Huberman <daveid at panix.com> wrote:

> What real scenario are you thinking of that involves in-region companies
> that isn't an 8.3?  I'm an American and my familiarity with American
> corporate law and resulting structures is having a hard time thinking of a
> scenario.  But maybe it's just early and I haven't had my hot chocolate yet
> :)
>
>
>
> On Jun 1, 2016, at 7:42 AM, Jason Schiller <jschiller at google.com> wrote:
>
> I support as written.
>
> However it occurs to me, why doesn't this text also apply to 8.3
> intra-ARIN specified transfers?
>
> 1. I see no reason why intra-compnay transfers where the recipient is
> outside of the ARIN region, be treated any differently than when the
> recipient is inside the ARIN region.
>
> 2. In fact I think if anything we would want to be equally or more liberal
> when the recipient is inside the ARIN region to have a greater chance of
> enforcing anti-flip restrictions (which we cannot easily do outside of the
> region).
>
> 3. I would like to avoid further diverging 8.3 and 8.4.  One could imagine
> merging 8.3 and 8.4 into a single section, and the community has asked the
> AC to undertake that work.
>
> ___Jason
>
> On Tue, May 24, 2016 at 5:23 PM, ARIN <info at arin.net> wrote:
>
>>
>> Recommended Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to
>> Specified Recipients)
>>
>> On 19 May 2016 the ARIN Advisory Council (AC) advanced 2015-2 to
>> Recommended Draft Policy status.
>>
>> The text of the Recommended Draft Policy is below, and may also be found
>> at:
>> https://www.arin.net/policy/proposals/2015_2.html
>>
>> You are encouraged to discuss all Recommended Draft Policies on PPML
>> prior to their presentation at the next ARIN Public Policy Consultation
>> (PPC). PPML and PPC discussions are invaluable to the AC when determining
>> community consensus.
>>
>> The 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)
>>
>>
>>
>> Recommended Draft Policy ARIN 2015-2
>> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>>
>> Date: 24 May 2016
>>
>> AC's assessment of conformance with the Principles of Internet Number
>> Resource Policy:
>>
>> Draft Policy ARIN 2015-2 contributes to fair and impartial number
>> resources administration by removing an impediment to the transfer of IPv4
>> numbering resources to other RIRs when business needs change within the
>> first 12 months of receipt of a 24 month supply of IP addresses by an
>> entity via the transfer market. It is technically sound in that it balances
>> removing limits on transfers of IPv4 numbering resources to other RIRs with
>> safeguards related to ownership and control described in the draft policy
>> to reduce the likelihood of fraudulent transactions. There was strong
>> community support for this draft policy at the NANOG 66 PPC and ARIN 37,
>> subject only to some suggested editorial changes which have now been
>> implemented in the latest version.
>>
>> Problem Statement:
>>
>> Organizations that obtain a 24 month supply of IP addresses via the
>> transfer market and then have an unexpected change in business plan are
>> unable to move IP addresses to the proper RIR within the first 12 months of
>> receipt.
>>
>> Policy statement:
>>
>> Replace 8.4, bullet 4, to read:
>>
>> "Source entities within the ARIN region must not have received a
>> transfer, allocation, or assignment of IPv4 number resources from ARIN for
>> the 12 months prior to the approval of a transfer request, unless either
>> the source or recipient entity owns or controls the other, or both are
>> under common ownership or control. This restriction does not include M&A
>> transfers."
>>
>> Comments: Organizations that obtain a 24 month supply of IP addresses via
>> the transfer market and then have an unexpected change in business plan are
>> unable to move IP addresses to the proper RIR within the first 12 months of
>> receipt. The need to move the resources does not flow from ARIN policy, but
>> rather from the requirement of certain registries outside the ARIN region
>> to have the resources moved in order to be used there.
>>
>> The intention of this change is to allow organizations to perform
>> inter-RIR transfers of space received via an 8.3 transfer regardless of the
>> date transferred to ARIN. A common example is that an organization acquires
>> a block located in the ARIN region, transfers it to ARIN, then 3 months
>> later, the organization announces that it wants to launch new services out
>> of region. Under current policy, the organization is prohibited from moving
>> some or all of those addresses to that region's Whois if there is a need to
>> move them to satisfy the rules of the other region requiring the movement
>> of the resources to that region in order for them to be used there.
>> Instead, the numbers are locked in ARIN's Whois. It's important to note
>> that 8.3 transfers are approved for a 24 month supply, and it would not be
>> unheard of for a business model to change within the first 12 months after
>> approval. The proposal also introduces a requirement for an affiliation
>> relationship between the source and recipient entity, based on established
>> corporate law principles, so as to make it reasonably likely that
>> eliminating the 12 month anti-flip period in that situation will meet the
>> needs of organizations that operate networks in more than one region
>> without encouraging abuse.
>>
>> a. Timetable for implementation: Immediate
>>
>> b. Anything else: N/A
>>
>> #####
>>
>> ARIN STAFF & LEGAL ASSESSMENT
>> Draft Policy ARIN-2015-2
>> MODIFY 8.4 (INTER-RIR TRANSFERS TO SPECIFIED RECIPIENTS)
>> https://www.arin.net/policy/proposals/2015_2.html
>>
>> Date of Assessment: 17 May 2016
>>
>> ___
>> 1. Summary (Staff Understanding)
>>
>> Currently, organizations are unable to act as a source on an 8.4 transfer
>> of IPv4 address space if they have received IPv4 address space in the past
>> 12 months from ARIN's IPv4 free pool, the waiting list for unmet requests,
>> or an 8.3 transfer. This draft policy lifts the 12-month restriction in
>> cases when the source or recipient entity owns or controls the other, or
>> both are under common ownership or control.
>>
>> ___
>> 2. Comments
>>
>> A. ARIN Staff Comments
>>
>> * If this policy is implemented, ARIN staff would no longer apply a
>> 12-month time restriction to organizations who wish to 8.4 transfer IPv4
>> addresses to themselves or in cases when the source or recipient entity
>> owns or controls the other, or both are under common ownership or control.
>>
>> * This policy could be implemented as written.
>>
>> B. ARIN General Counsel ? Legal Assessment
>>
>> Concerns raised by the GC regarding previous versions of this policy have
>> been satisfactorily addressed in the current draft. The current proposed
>> draft does not create material legal issues for ARIN. In order to determine
>> when entities are under common ownership or control, traditional legal
>> standards will be applied by ARIN.
>>
>> ___
>> 3. Resource Impact
>>
>> Implementation of this policy would have minimal resource impact. It is
>> estimated that implementation would occur within 3 months after
>> ratification by the ARIN Board of Trustees. The following would be needed
>> in order to implement:
>>
>> * Updated guidelines and internal procedures
>>
>> * Staff training
>>
>> ___
>> 4. Proposal / Draft Policy Text Assessed
>>
>> Draft Policy ARIN 2015-2
>> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>>
>> Date: 11 May 2016
>>
>> Problem Statement:
>>
>> Organizations that obtain a 24 month supply of IP addresses via the
>> transfer market and then have an unexpected change in business plan are
>> unable to move IP addresses to the proper RIR within the first 12 months of
>> receipt.
>>
>> Policy statement:
>>
>> Replace 8.4, bullet 4, to read: "Source entities within the ARIN region
>> must not have received a transfer, allocation, or assignment of IPv4 number
>> resources from ARIN for the 12 months prior to the approval of a transfer
>> request, unless either the source or recipient entity owns or controls the
>> other, or both are under common ownership or control. This restriction does
>> not include M&A transfers."
>>
>> Comments: Organizations that obtain a 24 month supply of IP addresses via
>> the transfer market and then have an unexpected change in business plan are
>> unable to move IP addresses to the proper RIR within the first 12 months of
>> receipt. The need to move the resources does not flow from ARIN policy, but
>> rather from the requirement of certain registries outside the ARIN region
>> to have the resources moved in order to be used there.
>>
>> The intention of this change is to allow organizations to perform
>> inter-RIR transfers of space received via an 8.3 transfer regardless of the
>> date transferred to ARIN. A common example is that an organization acquires
>> a block located in the ARIN region, transfers it to ARIN, then 3 months
>> later, the organization announces that it wants to launch new services out
>> of region. Under current policy, the organization is prohibited from moving
>> some or all of those addresses to that region's Whois if there is a need to
>> move them to satisfy the rules of the other region requiring the movement
>> of the resources to that region in order for them to be used there.
>> Instead, the numbers are locked in ARIN's Whois. It's important to note
>> that 8.3 transfers are approved for a 24 month supply, and it would not be
>> unheard of for a business model to change within the first 12 months after
>> approval. The proposal also introduces a requirement for an affiliation
>> relationship between the source and recipient entity, based on established
>> corporate law principles, so as to make it reasonably likely that
>> eliminating the 12 month anti-flip period in that situation will meet the
>> needs of organizations that operate networks in more than one region
>> without encouraging abuse.
>>
>> a. Timetable for implementation: Immediate
>> b. Anything else: N/A
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20160601/2ab1c84e/attachment.htm>

From daveid at panix.com  Wed Jun  1 09:44:28 2016
From: daveid at panix.com (David Huberman)
Date: Wed, 1 Jun 2016 08:44:28 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
	(Inter-RIR Transfers to Specified Recipients)
In-Reply-To: <CAC4yj2US3aN9FW0raw5dga11U+_QrzP6imBbg1CX3Tjf6cR+pw@mail.gmail.com>
References: <5744C66C.8050204@arin.net>
	<CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>
	<025E3E2D-6DCA-4B77-AF60-35C391A60256@panix.com>
	<CAC4yj2US3aN9FW0raw5dga11U+_QrzP6imBbg1CX3Tjf6cR+pw@mail.gmail.com>
Message-ID: <E754C289-A321-4CD4-AEAF-B672BEE4609A@panix.com>

Ah, in this case 8.2 applies.  Number resources which need to move between OrgIDs with common ownership can move via 8.2. :-)

> On Jun 1, 2016, at 8:39 AM, Jason Schiller <jschiller at google.com> wrote:
> 
> My understanding of the problem is that company A is selling a /16.
> Company B buys the /16.
> 
> After 3 months, company B finds their projected usage of the IP space 
> is no longer needed because their product was canceled, but a 
> European division of company B has need of them.
> 
> Under current policy company B cannot transfer the address space
> to their european division because:
> 
> 1. the source is ineligible for another 9 months because they recently
> received a transfer.
> 
> 2. the recipient is ineligible because RIPE does not have a compatible 
> needs based policy (maybe this has changed).
> 
> This policy would permit the transfer.
> 
> Now instead imagine company B has multiple OrgIDs, one for dial-up,
> one for dedicated customers, etc.  They recently decided to have a 
> cloud offering, and spun up a new OrgID (under the same legal entity) 
> and transfered the /16 for their new cloud offering.  
> 
> The cloud product fizzles after 3 months, but there is justified need for
> the /16 in part by the dial-up customers and in part by dedicated 
> customers.  To properly reflect the usage of the space part of the /16
> needs to be moved to the dial-up OrgID, and the rest to the dedicated
> OrgId.
> 
> Same scenario, but instead of one company with multiple OrgIds, it is 
> one company with multiple wholly owned subsidiaries, each of which
> have their own OrgID.  
> 
> I believe 8.2 does not apply unless there was some corporate
> restructuring. 
> 
> ___Jason
> 
>> On Wed, Jun 1, 2016 at 9:04 AM, David Huberman <daveid at panix.com> wrote:
>> What real scenario are you thinking of that involves in-region companies that isn't an 8.3?  I'm an American and my familiarity with American corporate law and resulting structures is having a hard time thinking of a scenario.  But maybe it's just early and I haven't had my hot chocolate yet :)
>> 
>> 
>> 
>>> On Jun 1, 2016, at 7:42 AM, Jason Schiller <jschiller at google.com> wrote:
>>> 
>>> I support as written.
>>> 
>>> However it occurs to me, why doesn't this text also apply to 8.3 intra-ARIN specified transfers?
>>> 
>>> 1. I see no reason why intra-compnay transfers where the recipient is outside of the ARIN region, be treated any differently than when the recipient is inside the ARIN region.
>>> 
>>> 2. In fact I think if anything we would want to be equally or more liberal when the recipient is inside the ARIN region to have a greater chance of enforcing anti-flip restrictions (which we cannot easily do outside of the region).
>>> 
>>> 3. I would like to avoid further diverging 8.3 and 8.4.  One could imagine merging 8.3 and 8.4 into a single section, and the community has asked the AC to undertake that work.
>>> 
>>> ___Jason
>>> 
>>>> On Tue, May 24, 2016 at 5:23 PM, ARIN <info at arin.net> wrote:
>>>> 
>>>> Recommended Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>>>> 
>>>> On 19 May 2016 the ARIN Advisory Council (AC) advanced 2015-2 to Recommended Draft Policy status.
>>>> 
>>>> The text of the Recommended Draft Policy is below, and may also be found at:
>>>> https://www.arin.net/policy/proposals/2015_2.html
>>>> 
>>>> You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus.
>>>> 
>>>> The 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)
>>>> 
>>>> 
>>>> 
>>>> Recommended Draft Policy ARIN 2015-2
>>>> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>>>> 
>>>> Date: 24 May 2016
>>>> 
>>>> AC's assessment of conformance with the Principles of Internet Number Resource Policy:
>>>> 
>>>> Draft Policy ARIN 2015-2 contributes to fair and impartial number resources administration by removing an impediment to the transfer of IPv4 numbering resources to other RIRs when business needs change within the first 12 months of receipt of a 24 month supply of IP addresses by an entity via the transfer market. It is technically sound in that it balances removing limits on transfers of IPv4 numbering resources to other RIRs with safeguards related to ownership and control described in the draft policy to reduce the likelihood of fraudulent transactions. There was strong community support for this draft policy at the NANOG 66 PPC and ARIN 37, subject only to some suggested editorial changes which have now been implemented in the latest version.
>>>> 
>>>> Problem Statement:
>>>> 
>>>> Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt.
>>>> 
>>>> Policy statement:
>>>> 
>>>> Replace 8.4, bullet 4, to read:
>>>> 
>>>> "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request, unless either the source or recipient entity owns or controls the other, or both are under common ownership or control. This restriction does not include M&A transfers."
>>>> 
>>>> Comments: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. The need to move the resources does not flow from ARIN policy, but rather from the requirement of certain registries outside the ARIN region to have the resources moved in order to be used there.
>>>> 
>>>> The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois if there is a need to move them to satisfy the rules of the other region requiring the movement of the resources to that region in order for them to be used there. Instead, the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse.
>>>> 
>>>> a. Timetable for implementation: Immediate
>>>> 
>>>> b. Anything else: N/A
>>>> 
>>>> #####
>>>> 
>>>> ARIN STAFF & LEGAL ASSESSMENT
>>>> Draft Policy ARIN-2015-2
>>>> MODIFY 8.4 (INTER-RIR TRANSFERS TO SPECIFIED RECIPIENTS)
>>>> https://www.arin.net/policy/proposals/2015_2.html
>>>> 
>>>> Date of Assessment: 17 May 2016
>>>> 
>>>> ___
>>>> 1. Summary (Staff Understanding)
>>>> 
>>>> Currently, organizations are unable to act as a source on an 8.4 transfer of IPv4 address space if they have received IPv4 address space in the past 12 months from ARIN's IPv4 free pool, the waiting list for unmet requests, or an 8.3 transfer. This draft policy lifts the 12-month restriction in cases when the source or recipient entity owns or controls the other, or both are under common ownership or control.
>>>> 
>>>> ___
>>>> 2. Comments
>>>> 
>>>> A. ARIN Staff Comments
>>>> 
>>>> * If this policy is implemented, ARIN staff would no longer apply a 12-month time restriction to organizations who wish to 8.4 transfer IPv4 addresses to themselves or in cases when the source or recipient entity owns or controls the other, or both are under common ownership or control.
>>>> 
>>>> * This policy could be implemented as written.
>>>> 
>>>> B. ARIN General Counsel ? Legal Assessment
>>>> 
>>>> Concerns raised by the GC regarding previous versions of this policy have been satisfactorily addressed in the current draft. The current proposed draft does not create material legal issues for ARIN. In order to determine when entities are under common ownership or control, traditional legal standards will be applied by ARIN.
>>>> 
>>>> ___
>>>> 3. Resource Impact
>>>> 
>>>> Implementation of this policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement:
>>>> 
>>>> * Updated guidelines and internal procedures
>>>> 
>>>> * Staff training
>>>> 
>>>> ___
>>>> 4. Proposal / Draft Policy Text Assessed
>>>> 
>>>> Draft Policy ARIN 2015-2
>>>> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>>>> 
>>>> Date: 11 May 2016
>>>> 
>>>> Problem Statement:
>>>> 
>>>> Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt.
>>>> 
>>>> Policy statement:
>>>> 
>>>> Replace 8.4, bullet 4, to read: "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request, unless either the source or recipient entity owns or controls the other, or both are under common ownership or control. This restriction does not include M&A transfers."
>>>> 
>>>> Comments: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. The need to move the resources does not flow from ARIN policy, but rather from the requirement of certain registries outside the ARIN region to have the resources moved in order to be used there.
>>>> 
>>>> The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois if there is a need to move them to satisfy the rules of the other region requiring the movement of the resources to that region in order for them to be used there. Instead, the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse.
>>>> 
>>>> a. Timetable for implementation: Immediate
>>>> b. Anything else: N/A
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage 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
>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage 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/20160601/21db44ef/attachment.htm>

From jschiller at google.com  Wed Jun  1 11:02:21 2016
From: jschiller at google.com (Jason Schiller)
Date: Wed, 1 Jun 2016 11:02:21 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
 (Inter-RIR Transfers to Specified Recipients)
In-Reply-To: <E754C289-A321-4CD4-AEAF-B672BEE4609A@panix.com>
References: <5744C66C.8050204@arin.net>
	<CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>
	<025E3E2D-6DCA-4B77-AF60-35C391A60256@panix.com>
	<CAC4yj2US3aN9FW0raw5dga11U+_QrzP6imBbg1CX3Tjf6cR+pw@mail.gmail.com>
	<E754C289-A321-4CD4-AEAF-B672BEE4609A@panix.com>
Message-ID: <CAC4yj2WyAgij49RkSLYrJSTB2W3xY7L_wCCOU2-m=ZAx6gGZxQ@mail.gmail.com>

Really?

I can move any IP equal to or larger than the minimum between ARIN OrgIDs
as long as
the entities registered to the OrgID have either the source or recipient
entity owning or
controling the other, or both are under common ownership or control?

Even without a corporate reorganization?

Staff, is this true?

(I am happy to read 8.2 that way, but that is not how I currently read it.)

__Jason

On Wed, Jun 1, 2016 at 9:44 AM, David Huberman <daveid at panix.com> wrote:

> Ah, in this case 8.2 applies.  Number resources which need to move between
> OrgIDs with common ownership can move via 8.2. :-)
>
> On Jun 1, 2016, at 8:39 AM, Jason Schiller <jschiller at google.com> wrote:
>
> My understanding of the problem is that company A is selling a /16.
> Company B buys the /16.
>
> After 3 months, company B finds their projected usage of the IP space
> is no longer needed because their product was canceled, but a
> European division of company B has need of them.
>
> Under current policy company B cannot transfer the address space
> to their european division because:
>
> 1. the source is ineligible for another 9 months because they recently
> received a transfer.
>
> 2. the recipient is ineligible because RIPE does not have a compatible
> needs based policy (maybe this has changed).
>
> This policy would permit the transfer.
>
> Now instead imagine company B has multiple OrgIDs, one for dial-up,
> one for dedicated customers, etc.  They recently decided to have a
> cloud offering, and spun up a new OrgID (under the same legal entity)
> and transfered the /16 for their new cloud offering.
>
> The cloud product fizzles after 3 months, but there is justified need for
> the /16 in part by the dial-up customers and in part by dedicated
> customers.  To properly reflect the usage of the space part of the /16
> needs to be moved to the dial-up OrgID, and the rest to the dedicated
> OrgId.
>
> Same scenario, but instead of one company with multiple OrgIds, it is
> one company with multiple wholly owned subsidiaries, each of which
> have their own OrgID.
>
> I believe 8.2 does not apply unless there was some corporate
> restructuring.
>
> ___Jason
>
> On Wed, Jun 1, 2016 at 9:04 AM, David Huberman <daveid at panix.com> wrote:
>
>> What real scenario are you thinking of that involves in-region companies
>> that isn't an 8.3?  I'm an American and my familiarity with American
>> corporate law and resulting structures is having a hard time thinking of a
>> scenario.  But maybe it's just early and I haven't had my hot chocolate yet
>> :)
>>
>>
>>
>> On Jun 1, 2016, at 7:42 AM, Jason Schiller <jschiller at google.com> wrote:
>>
>> I support as written.
>>
>> However it occurs to me, why doesn't this text also apply to 8.3
>> intra-ARIN specified transfers?
>>
>> 1. I see no reason why intra-compnay transfers where the recipient is
>> outside of the ARIN region, be treated any differently than when the
>> recipient is inside the ARIN region.
>>
>> 2. In fact I think if anything we would want to be equally or more
>> liberal when the recipient is inside the ARIN region to have a greater
>> chance of enforcing anti-flip restrictions (which we cannot easily do
>> outside of the region).
>>
>> 3. I would like to avoid further diverging 8.3 and 8.4.  One could
>> imagine merging 8.3 and 8.4 into a single section, and the community has
>> asked the AC to undertake that work.
>>
>> ___Jason
>>
>> On Tue, May 24, 2016 at 5:23 PM, ARIN <info at arin.net> wrote:
>>
>>>
>>> Recommended Draft Policy ARIN-2015-2 Modify 8.4 (Inter-RIR Transfers to
>>> Specified Recipients)
>>>
>>> On 19 May 2016 the ARIN Advisory Council (AC) advanced 2015-2 to
>>> Recommended Draft Policy status.
>>>
>>> The text of the Recommended Draft Policy is below, and may also be found
>>> at:
>>> https://www.arin.net/policy/proposals/2015_2.html
>>>
>>> You are encouraged to discuss all Recommended Draft Policies on PPML
>>> prior to their presentation at the next ARIN Public Policy Consultation
>>> (PPC). PPML and PPC discussions are invaluable to the AC when determining
>>> community consensus.
>>>
>>> The 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)
>>>
>>>
>>>
>>> Recommended Draft Policy ARIN 2015-2
>>> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>>>
>>> Date: 24 May 2016
>>>
>>> AC's assessment of conformance with the Principles of Internet Number
>>> Resource Policy:
>>>
>>> Draft Policy ARIN 2015-2 contributes to fair and impartial number
>>> resources administration by removing an impediment to the transfer of IPv4
>>> numbering resources to other RIRs when business needs change within the
>>> first 12 months of receipt of a 24 month supply of IP addresses by an
>>> entity via the transfer market. It is technically sound in that it balances
>>> removing limits on transfers of IPv4 numbering resources to other RIRs with
>>> safeguards related to ownership and control described in the draft policy
>>> to reduce the likelihood of fraudulent transactions. There was strong
>>> community support for this draft policy at the NANOG 66 PPC and ARIN 37,
>>> subject only to some suggested editorial changes which have now been
>>> implemented in the latest version.
>>>
>>> Problem Statement:
>>>
>>> Organizations that obtain a 24 month supply of IP addresses via the
>>> transfer market and then have an unexpected change in business plan are
>>> unable to move IP addresses to the proper RIR within the first 12 months of
>>> receipt.
>>>
>>> Policy statement:
>>>
>>> Replace 8.4, bullet 4, to read:
>>>
>>> "Source entities within the ARIN region must not have received a
>>> transfer, allocation, or assignment of IPv4 number resources from ARIN for
>>> the 12 months prior to the approval of a transfer request, unless either
>>> the source or recipient entity owns or controls the other, or both are
>>> under common ownership or control. This restriction does not include M&A
>>> transfers."
>>>
>>> Comments: Organizations that obtain a 24 month supply of IP addresses
>>> via the transfer market and then have an unexpected change in business plan
>>> are unable to move IP addresses to the proper RIR within the first 12
>>> months of receipt. The need to move the resources does not flow from ARIN
>>> policy, but rather from the requirement of certain registries outside the
>>> ARIN region to have the resources moved in order to be used there.
>>>
>>> The intention of this change is to allow organizations to perform
>>> inter-RIR transfers of space received via an 8.3 transfer regardless of the
>>> date transferred to ARIN. A common example is that an organization acquires
>>> a block located in the ARIN region, transfers it to ARIN, then 3 months
>>> later, the organization announces that it wants to launch new services out
>>> of region. Under current policy, the organization is prohibited from moving
>>> some or all of those addresses to that region's Whois if there is a need to
>>> move them to satisfy the rules of the other region requiring the movement
>>> of the resources to that region in order for them to be used there.
>>> Instead, the numbers are locked in ARIN's Whois. It's important to note
>>> that 8.3 transfers are approved for a 24 month supply, and it would not be
>>> unheard of for a business model to change within the first 12 months after
>>> approval. The proposal also introduces a requirement for an affiliation
>>> relationship between the source and recipient entity, based on established
>>> corporate law principles, so as to make it reasonably likely that
>>> eliminating the 12 month anti-flip period in that situation will meet the
>>> needs of organizations that operate networks in more than one region
>>> without encouraging abuse.
>>>
>>> a. Timetable for implementation: Immediate
>>>
>>> b. Anything else: N/A
>>>
>>> #####
>>>
>>> ARIN STAFF & LEGAL ASSESSMENT
>>> Draft Policy ARIN-2015-2
>>> MODIFY 8.4 (INTER-RIR TRANSFERS TO SPECIFIED RECIPIENTS)
>>> https://www.arin.net/policy/proposals/2015_2.html
>>>
>>> Date of Assessment: 17 May 2016
>>>
>>> ___
>>> 1. Summary (Staff Understanding)
>>>
>>> Currently, organizations are unable to act as a source on an 8.4
>>> transfer of IPv4 address space if they have received IPv4 address space in
>>> the past 12 months from ARIN's IPv4 free pool, the waiting list for unmet
>>> requests, or an 8.3 transfer. This draft policy lifts the 12-month
>>> restriction in cases when the source or recipient entity owns or controls
>>> the other, or both are under common ownership or control.
>>>
>>> ___
>>> 2. Comments
>>>
>>> A. ARIN Staff Comments
>>>
>>> * If this policy is implemented, ARIN staff would no longer apply a
>>> 12-month time restriction to organizations who wish to 8.4 transfer IPv4
>>> addresses to themselves or in cases when the source or recipient entity
>>> owns or controls the other, or both are under common ownership or control.
>>>
>>> * This policy could be implemented as written.
>>>
>>> B. ARIN General Counsel ? Legal Assessment
>>>
>>> Concerns raised by the GC regarding previous versions of this policy
>>> have been satisfactorily addressed in the current draft. The current
>>> proposed draft does not create material legal issues for ARIN. In order to
>>> determine when entities are under common ownership or control, traditional
>>> legal standards will be applied by ARIN.
>>>
>>> ___
>>> 3. Resource Impact
>>>
>>> Implementation of this policy would have minimal resource impact. It is
>>> estimated that implementation would occur within 3 months after
>>> ratification by the ARIN Board of Trustees. The following would be needed
>>> in order to implement:
>>>
>>> * Updated guidelines and internal procedures
>>>
>>> * Staff training
>>>
>>> ___
>>> 4. Proposal / Draft Policy Text Assessed
>>>
>>> Draft Policy ARIN 2015-2
>>> Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
>>>
>>> Date: 11 May 2016
>>>
>>> Problem Statement:
>>>
>>> Organizations that obtain a 24 month supply of IP addresses via the
>>> transfer market and then have an unexpected change in business plan are
>>> unable to move IP addresses to the proper RIR within the first 12 months of
>>> receipt.
>>>
>>> Policy statement:
>>>
>>> Replace 8.4, bullet 4, to read: "Source entities within the ARIN region
>>> must not have received a transfer, allocation, or assignment of IPv4 number
>>> resources from ARIN for the 12 months prior to the approval of a transfer
>>> request, unless either the source or recipient entity owns or controls the
>>> other, or both are under common ownership or control. This restriction does
>>> not include M&A transfers."
>>>
>>> Comments: Organizations that obtain a 24 month supply of IP addresses
>>> via the transfer market and then have an unexpected change in business plan
>>> are unable to move IP addresses to the proper RIR within the first 12
>>> months of receipt. The need to move the resources does not flow from ARIN
>>> policy, but rather from the requirement of certain registries outside the
>>> ARIN region to have the resources moved in order to be used there.
>>>
>>> The intention of this change is to allow organizations to perform
>>> inter-RIR transfers of space received via an 8.3 transfer regardless of the
>>> date transferred to ARIN. A common example is that an organization acquires
>>> a block located in the ARIN region, transfers it to ARIN, then 3 months
>>> later, the organization announces that it wants to launch new services out
>>> of region. Under current policy, the organization is prohibited from moving
>>> some or all of those addresses to that region's Whois if there is a need to
>>> move them to satisfy the rules of the other region requiring the movement
>>> of the resources to that region in order for them to be used there.
>>> Instead, the numbers are locked in ARIN's Whois. It's important to note
>>> that 8.3 transfers are approved for a 24 month supply, and it would not be
>>> unheard of for a business model to change within the first 12 months after
>>> approval. The proposal also introduces a requirement for an affiliation
>>> relationship between the source and recipient entity, based on established
>>> corporate law principles, so as to make it reasonably likely that
>>> eliminating the 12 month anti-flip period in that situation will meet the
>>> needs of organizations that operate networks in more than one region
>>> without encouraging abuse.
>>>
>>> a. Timetable for implementation: Immediate
>>> b. Anything else: N/A
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage 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
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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
>
>


-- 
_______________________________________________________
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/20160601/e43a05fc/attachment.htm>

From jcurran at arin.net  Wed Jun  1 11:27:58 2016
From: jcurran at arin.net (John Curran)
Date: Wed, 1 Jun 2016 15:27:58 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
 (Inter-RIR Transfers to Specified Recipients)
In-Reply-To: <CAC4yj2WyAgij49RkSLYrJSTB2W3xY7L_wCCOU2-m=ZAx6gGZxQ@mail.gmail.com>
References: <5744C66C.8050204@arin.net>
	<CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>
	<025E3E2D-6DCA-4B77-AF60-35C391A60256@panix.com>
	<CAC4yj2US3aN9FW0raw5dga11U+_QrzP6imBbg1CX3Tjf6cR+pw@mail.gmail.com>
	<E754C289-A321-4CD4-AEAF-B672BEE4609A@panix.com>
	<CAC4yj2WyAgij49RkSLYrJSTB2W3xY7L_wCCOU2-m=ZAx6gGZxQ@mail.gmail.com>
Message-ID: <559E2C21-7023-4B1F-AD3E-B5B80FE25DBE@corp.arin.net>

On Jun 1, 2016, at 11:02 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:
I can move any IP equal to or larger than the minimum between ARIN OrgIDs as long as
the entities registered to the OrgID have either the source or recipient entity owning or
controling the other, or both are under common ownership or control?

In cases of a reorganization of responsibilities (as you describe above),
number resources may be transferred between related organizations in
accordance with NRPM 8.2.

Even without a corporate reorganization?

Unknown - please distinguish what you mean by a ?corporate reorganization?;
is this distinct from organizations which are undergoing some form of internal
reorganization of functions?

/John

John Curran
President and CEO
ARIN

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

From jschiller at google.com  Wed Jun  1 13:19:11 2016
From: jschiller at google.com (Jason Schiller)
Date: Wed, 1 Jun 2016 13:19:11 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
 (Inter-RIR Transfers to Specified Recipients)
In-Reply-To: <559E2C21-7023-4B1F-AD3E-B5B80FE25DBE@corp.arin.net>
References: <5744C66C.8050204@arin.net>
	<CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>
	<025E3E2D-6DCA-4B77-AF60-35C391A60256@panix.com>
	<CAC4yj2US3aN9FW0raw5dga11U+_QrzP6imBbg1CX3Tjf6cR+pw@mail.gmail.com>
	<E754C289-A321-4CD4-AEAF-B672BEE4609A@panix.com>
	<CAC4yj2WyAgij49RkSLYrJSTB2W3xY7L_wCCOU2-m=ZAx6gGZxQ@mail.gmail.com>
	<559E2C21-7023-4B1F-AD3E-B5B80FE25DBE@corp.arin.net>
Message-ID: <CAC4yj2WJ7Qb=hS0XJR9U144zPa7sZCXcyvQLnSz6oOpEqCd2aQ@mail.gmail.com>

John,

I guess I don't know what is meant by corporate reorganization
as referenced in 8.2.  I assume this means the corporate
structure has changed, for example closing a wholly owned
subsidiary, or moving a subsidiary to a parent higher up in the tree.

I tried to suggest an example where the corporate structure has
not changed.  I no longer need IPs for my orgID X, but could use
them for my OrgID Y and my OrgID Z.  Where X, Y , and Z  have
always been wholly owned subs, and will continue to be so for the
foreseeable future.  Or a completely seperate case where X, Y, and Z
have always been a single legal entity, and will continue to be so for the
foreseeable future.

Does "I have pulled the plug on product P so we don't the need the
IPs but can use them elsewhere" Or "Product Q stopped growing so I no
longer need the unused IP space but can use them elsewhere" qualify as
a corporate re-organization and therefor the transfer permitted under 8.2?

__Jason




On Wed, Jun 1, 2016 at 11:27 AM, John Curran <jcurran at arin.net> wrote:

> On Jun 1, 2016, at 11:02 AM, Jason Schiller <jschiller at google.com> wrote:
>
> I can move any IP equal to or larger than the minimum between ARIN OrgIDs
> as long as
> the entities registered to the OrgID have either the source or recipient
> entity owning or
> controling the other, or both are under common ownership or control?
>
>
> In cases of a reorganization of responsibilities (as you describe above),
> number resources may be transferred between related organizations in
> accordance with NRPM 8.2.
>
> Even without a corporate reorganization?
>
>
> Unknown - please distinguish what you mean by a ?corporate reorganization?;
> is this distinct from organizations which are undergoing some form of
> internal
> reorganization of functions?
>
> /John
>
> John Curran
> President and CEO
> ARIN
>
>


-- 
_______________________________________________________
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/20160601/77145b9d/attachment.htm>

From daveid at panix.com  Wed Jun  1 14:44:41 2016
From: daveid at panix.com (David Huberman)
Date: Wed, 1 Jun 2016 11:44:41 -0700
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
	(Inter-RIR Transfers to Specified Recipients)
In-Reply-To: <CAC4yj2WJ7Qb=hS0XJR9U144zPa7sZCXcyvQLnSz6oOpEqCd2aQ@mail.gmail.com>
References: <5744C66C.8050204@arin.net>
	<CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>
	<025E3E2D-6DCA-4B77-AF60-35C391A60256@panix.com>
	<CAC4yj2US3aN9FW0raw5dga11U+_QrzP6imBbg1CX3Tjf6cR+pw@mail.gmail.com>
	<E754C289-A321-4CD4-AEAF-B672BEE4609A@panix.com>
	<CAC4yj2WyAgij49RkSLYrJSTB2W3xY7L_wCCOU2-m=ZAx6gGZxQ@mail.gmail.com>
	<559E2C21-7023-4B1F-AD3E-B5B80FE25DBE@corp.arin.net>
	<CAC4yj2WJ7Qb=hS0XJR9U144zPa7sZCXcyvQLnSz6oOpEqCd2aQ@mail.gmail.com>
Message-ID: <F06EBBEF-343D-4ABC-8F52-54A5BB56F8FA@panix.com>

"The assets using the number resources currently registered to David Corp are now under the control of Jason Corp.  David Corp and Jason Corp are both subs of LizAndHeather Corp, as shown in this document here."

> On Jun 1, 2016, at 10:19 AM, Jason Schiller <jschiller at google.com> wrote:
> 
> John,
> 
> I guess I don't know what is meant by corporate reorganization 
> as referenced in 8.2.  I assume this means the corporate 
> structure has changed, for example closing a wholly owned 
> subsidiary, or moving a subsidiary to a parent higher up in the tree.
> 
> I tried to suggest an example where the corporate structure has 
> not changed.  I no longer need IPs for my orgID X, but could use 
> them for my OrgID Y and my OrgID Z.  Where X, Y , and Z  have 
> always been wholly owned subs, and will continue to be so for the 
> foreseeable future.  Or a completely seperate case where X, Y, and Z
> have always been a single legal entity, and will continue to be so for the 
> foreseeable future.
> 
> Does "I have pulled the plug on product P so we don't the need the 
> IPs but can use them elsewhere" Or "Product Q stopped growing so I no 
> longer need the unused IP space but can use them elsewhere" qualify as 
> a corporate re-organization and therefor the transfer permitted under 8.2?
> 
> __Jason
> 
> 
> 
> 
>> On Wed, Jun 1, 2016 at 11:27 AM, John Curran <jcurran at arin.net> wrote:
>>> On Jun 1, 2016, at 11:02 AM, Jason Schiller <jschiller at google.com> wrote:
>>> I can move any IP equal to or larger than the minimum between ARIN OrgIDs as long as 
>>> the entities registered to the OrgID have either the source or recipient entity owning or 
>>> controling the other, or both are under common ownership or control?
>> 
>> In cases of a reorganization of responsibilities (as you describe above), 
>> number resources may be transferred between related organizations in 
>> accordance with NRPM 8.2.
>> 
>>> Even without a corporate reorganization?
>> 
>> Unknown - please distinguish what you mean by a ?corporate reorganization?;
>> is this distinct from organizations which are undergoing some form of internal 
>> reorganization of functions?
>> 
>> /John
>> 
>> John Curran
>> President and CEO
>> ARIN
> 
> 
> 
> -- 
> _______________________________________________________
> 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/20160601/60bf3332/attachment.htm>

From jcurran at arin.net  Wed Jun  1 15:51:01 2016
From: jcurran at arin.net (John Curran)
Date: Wed, 1 Jun 2016 19:51:01 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN 2015-2 Modify 8.4
 (Inter-RIR Transfers to Specified Recipients)
In-Reply-To: <F06EBBEF-343D-4ABC-8F52-54A5BB56F8FA@panix.com>
References: <5744C66C.8050204@arin.net>
	<CAC4yj2XaRFeWbEGA4hvgmV+fcjfWFTKRFahm+Gkx1SNrqJk8ww@mail.gmail.com>
	<025E3E2D-6DCA-4B77-AF60-35C391A60256@panix.com>
	<CAC4yj2US3aN9FW0raw5dga11U+_QrzP6imBbg1CX3Tjf6cR+pw@mail.gmail.com>
	<E754C289-A321-4CD4-AEAF-B672BEE4609A@panix.com>
	<CAC4yj2WyAgij49RkSLYrJSTB2W3xY7L_wCCOU2-m=ZAx6gGZxQ@mail.gmail.com>
	<559E2C21-7023-4B1F-AD3E-B5B80FE25DBE@corp.arin.net>
	<CAC4yj2WJ7Qb=hS0XJR9U144zPa7sZCXcyvQLnSz6oOpEqCd2aQ@mail.gmail.com>
	<F06EBBEF-343D-4ABC-8F52-54A5BB56F8FA@panix.com>
Message-ID: <FB850DE2-DB0D-4906-9030-A5ADA0C2BE84@arin.net>

Jason -

David is correct.

Note that we administer the registry per the number resource policy manual,
and that includes generally facilitating requestors towards approval if at all
possible.  The phrase in NRPM 8.2 is simply ?reorganization? and this has wide
applicability for organizations who need restructure responsibilities with their
business units.

If the community would like more stringent criteria applied with respect to the
nature of ?reorganization", it should specify such via explicit policy changes
which meet the principles of Internet number resource policy provided in
the PDP (i.e. enabling fair and impartial number resource administration,
technically sound, supported by the community)

Thanks!
/John


On Jun 1, 2016, at 2:44 PM, David Huberman <daveid at panix.com<mailto:daveid at panix.com>> wrote:

"The assets using the number resources currently registered to David Corp are now under the control of Jason Corp.  David Corp and Jason Corp are both subs of LizAndHeather Corp, as shown in this document here."

On Jun 1, 2016, at 10:19 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:

John,

I guess I don't know what is meant by corporate reorganization
as referenced in 8.2.  I assume this means the corporate
structure has changed, for example closing a wholly owned
subsidiary, or moving a subsidiary to a parent higher up in the tree.

I tried to suggest an example where the corporate structure has
not changed.  I no longer need IPs for my orgID X, but could use
them for my OrgID Y and my OrgID Z.  Where X, Y , and Z  have
always been wholly owned subs, and will continue to be so for the
foreseeable future.  Or a completely seperate case where X, Y, and Z
have always been a single legal entity, and will continue to be so for the
foreseeable future.

Does "I have pulled the plug on product P so we don't the need the
IPs but can use them elsewhere" Or "Product Q stopped growing so I no
longer need the unused IP space but can use them elsewhere" qualify as
a corporate re-organization and therefor the transfer permitted under 8.2?

__Jason




On Wed, Jun 1, 2016 at 11:27 AM, John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:
On Jun 1, 2016, at 11:02 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:
I can move any IP equal to or larger than the minimum between ARIN OrgIDs as long as
the entities registered to the OrgID have either the source or recipient entity owning or
controling the other, or both are under common ownership or control?

In cases of a reorganization of responsibilities (as you describe above),
number resources may be transferred between related organizations in
accordance with NRPM 8.2.

Even without a corporate reorganization?

Unknown - please distinguish what you mean by a ?corporate reorganization?;
is this distinct from organizations which are undergoing some form of internal
reorganization of functions?

/John

John Curran
President and CEO
ARIN




--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|571-266-0006


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

From narten at us.ibm.com  Fri Jun  3 00:53:03 2016
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 03 Jun 2016 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201606030453.u534r3fN009401@rotala.raleigh.ibm.com>

Total of 10 messages in the last 7 days.
 
script run at: Fri Jun  3 00:53:03 EDT 2016
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 40.00% |    4 | 49.76% |   119561 | jschiller at google.com
 30.00% |    3 | 33.37% |    80189 | daveid at panix.com
 20.00% |    2 | 13.82% |    33205 | jcurran at arin.net
 10.00% |    1 |  3.05% |     7321 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   10 |100.00% |   240276 | Total



From info at arin.net  Wed Jun  8 13:24:02 2016
From: info at arin.net (ARIN)
Date: Wed, 8 Jun 2016 13:24:02 -0400
Subject: [arin-ppml] ARIN Board Adopts ARIN-2015-3 and Editorial Update
Message-ID: <21195401-06d8-907e-32e5-38d4c5b475ca@arin.net>


On 20 May 2016 the Board of Trustees adopted the following Recommended 
Draft Policies:

ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy

This new policy will be implemented no later than 31 July 2016.

This is in accordance with the staff assessment that rated the resource 
impact as minimal, requiring three months to implement.

The Board of Trustees also adopted the editorial update to "return" 
language for 8.2 M&A transfers.

This editorial update will be implemented no later than 31 July 2016.

Board of Trustees Meeting Minutes are available at:
https://www.arin.net/about_us/bot/index.html

Draft Policy and Policy 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 narten at us.ibm.com  Fri Jun 10 00:53:02 2016
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 10 Jun 2016 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201606100453.u5A4r2jI005340@rotala.raleigh.ibm.com>

Total of 2 messages in the last 7 days.
 
script run at: Fri Jun 10 00:53:02 EDT 2016
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    1 | 51.35% |     6850 | narten at us.ibm.com
 50.00% |    1 | 48.65% |     6489 | info at arin.net
--------+------+--------+----------+------------------------
100.00% |    2 |100.00% |    13339 | Total



From rs-lists at seastrom.com  Thu Jun 16 15:54:58 2016
From: rs-lists at seastrom.com (Rob Seastrom)
Date: Thu, 16 Jun 2016 15:54:58 -0400
Subject: [arin-ppml] Revision to policy statement for 2015-7
Message-ID: <C0D3B4FC-B90D-434A-ACA3-E2F246B23B20@seastrom.com>


To incorporate feedback received during ARIN 37, the following changes are being made to the policy statement text for 2015-7 - Simplified requirements for demonstrated need for IPv4 transfers.

Policy statement:

Append the follwing bullet point to "Conditions on recipient of the transfer" section in NRPM 8.3 and 8.4

A recipient of IPv4 number resources may, at its option, demonstrate need by having an officer of the requesting organization attest that they will use at least 50% of their aggregate IPv4 addresses (including the requested resources) on an operational network within 24 months, rather than the criteria enumerated in Section 4 of the NRPM.


Old text:

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.

The AC would appreciate your feedback and thoughts.

Thank you,

-Rob



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

From narten at us.ibm.com  Fri Jun 17 00:53:03 2016
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 17 Jun 2016 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201606170453.u5H4r3e3010113@rotala.raleigh.ibm.com>

Total of 2 messages in the last 7 days.
 
script run at: Fri Jun 17 00:53:03 EDT 2016
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    1 | 54.84% |    10242 | rs-lists at seastrom.com
 50.00% |    1 | 45.16% |     8433 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    2 |100.00% |    18675 | Total



From info at arin.net  Tue Jun 21 11:15:02 2016
From: info at arin.net (ARIN)
Date: Tue, 21 Jun 2016 11:15:02 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - June 2016
Message-ID: <576959F6.9030301@arin.net>

In accordance with the ARIN Policy Development Process (PDP), the ARIN 
Advisory Council (AC) met on 16 June 2016.

The AC has advanced the following to Recommended Draft Policy status 
(will be posted separately as such):

	ARIN-2016-1: Reserved Pool Transfer Policy

The AC advances Draft Policies to Recommended Draft Policy status once 
they have been fully developed and meet ARIN's Principles of Internet 
Number Resource Policy. Specifically, these principles are:

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

The AC has advanced the following Proposals to Draft Policy status (each 
will be posted for discussion):

	ARIN-prop-229: Transfers for new entrants
	ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy

The AC advances Proposals to Draft Policy status once they are found to 
be within scope of the PDP, and contain a clear problem statement and 
suggested changes to number resource policy text.

The AC is continuing to work on:

	Recommended Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers 
to Specified Recipients)
	Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need 
for IPv4 transfers
	Draft Policy ARIN-2016-2: Change timeframes for IPv4 requests to 24 months
	Draft Policy ARIN-2016-3: Alternative simplified criteria for 
justifying small IPv4 transfers

The 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)


From info at arin.net  Tue Jun 21 11:40:54 2016
From: info at arin.net (ARIN)
Date: Tue, 21 Jun 2016 11:40:54 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-4: Transfers for new entrants
Message-ID: <57696006.5010305@arin.net>

On 16 June 2016 the ARIN Advisory Council (AC) advanced the following 
Proposal to Draft Policy status:

ARIN-prop-229: Transfers for new entrants

This Draft Policy has been numbered and titled:

Draft Policy ARIN-2016-4: Transfers for new entrants

Draft Policy ARIN-2016-4 is below and can be found at:
https://www.arin.net/policy/proposals/2016_4.html

You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
principles are:

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

The 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-2016-4: Transfers for new entrants

Date: 21 June, 2016
Problem Statement:

New organizations without existing IPv4 space may not always be able to 
qualify for an initial allocation under NRPM 4.2, particularly if they 
are categorized as ISPs and subject to 4.2.2.1.1. Use of /24. Now that 
ARIN's free pool is exhausted, 4.2.1.6. Immediate need states that 
"These cases are exceptional", but that is no longer correct. End user 
organizations requiring less a /24 of address space may also be unable 
to acquire space from their upstream ISP, and may instead need to 
receive a /24 from ARIN via transfer.

Policy statement:

Replace Section 4.2.2 with:

4.2.2. Initial allocation to ISPs

"All ISP organizations without direct assignments or allocations from 
ARIN qualify for an initial allocation of up to a /21, subject to ARIN's 
minimum allocation size. Organizations may qualify for a larger initial 
allocation by documenting how the requested allocation will be utilized 
within 24 months for specified transfers, or three months otherwise. 
ISPs renumbering out of their previous address space will be given a 
reasonable amount of time to do so, and any blocks they are returning 
will not count against their utilization.

Replace Section 4.3.2 to read:

4.3.2 Minimum assignment

ARIN's minimum assignment for end-user organizations is a /24.

End-user organizations without direct assignments or allocations from 
ARIN qualify for an initial assignment of ARIN's minimum assignment size.

Replace the first two sentences of Section 4.3.3. Utilization rate to read:

Organizations may qualify for a larger initial allocation by providing 
appropriate details to verify their 24-month growth projection for 
specified transfers, or 12 months otherwise.

Resulting new section 4.3.3 will be:

Organizations may qualify for a larger initial allocation, by providing 
appropriate details to verify their 24-month growth projection for 
specified transfers, or 12 months otherwise.

The basic criterion that must be met is a 50% utilization rate within 
one year.

A greater utilization rate may be required based on individual network 
requirements. Please refer to RFC 2050 for more information on 
utilization guidelines.

Comments:

Timetable for implementation: Immediate

Anything else

The text in 4.2.2 "for specified transfers, or three months otherwise" 
and the text in 4.3.3 "for specified transfers, or 12 months otherwise" 
should be stricken if ARIN-prop-227 is adopted.


From info at arin.net  Tue Jun 21 12:01:55 2016
From: info at arin.net (ARIN)
Date: Tue, 21 Jun 2016 12:01:55 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion
 Transfer Policy
Message-ID: <576964F3.3010409@arin.net>

On 16 June 2016 the ARIN Advisory Council (AC) advanced the following 
Proposal to Draft Policy status:

ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy

This Draft Policy has been numbered and titled:

Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

Draft Policy ARIN-2016-5 is below and can be found at:
https://www.arin.net/policy/proposals/2016_5.html

You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these 
principles are:

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

The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

Date: 21 June 2016

Problem Statement

Section 4 of the Number Policy Resource Manual was developed over the 
past 15+ years primarily to conservatively manage the IPv4 number free 
pool. Since the IPv4 free pool was depleted in 2015, the policies which 
developed since ARIN's inception may now not be as relevant now that the 
primary function of the registry, with regard to IPv4 numbers, is to 
record transfers.

Since section 4 of the NRPM now contains many use cases that are not as 
relevant, it makes sense to streamline the transfer process and to 
specifically outline the criteria that should be used to process transfers.

Therefore, we propose the following rewrite of the transfer policy, 
section 8 of the NRPM.

The goals of this rewrite are as follows:

 > Separate the criteria that is found in section 4 of the NRPM from the 
transfer process.

 > Provide a clear set of criteria that should be applied across all 
IPv4 transfers.

 > Lower the thresholds on utilization and future allocation size to 
negate the necessity of the corner cases which are currently enumerated 
in section 4 of the NRPM.

 > Reduce the complexity that is currently required for transfers, by 
applying simpler utilization criteria for current usage, and future 
allocation sizing.

Policy statement:

Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.

######

8.2. Mergers, Acquisitions, and Reorganizations

ARIN will consider requests for the transfer of number resources in the 
case of mergers, acquisitions, and reorganizations under the following 
conditions:

 > The current registrant must not be involved in any dispute as to the 
status of the resources to be transferred.

 > The new entity must sign an RSA covering all resources to be transferred.

 > The resources to be transferred will be subject to ARIN policies.

 > The minimum transfer size is the smaller of the original allocation 
size or the applicable minimum allocation size in current policy.

 > For mergers and acquisition transfers, the recipient entity must 
provide evidence that they have acquired assets that use the resources 
to be transferred from the current registrant. ARIN will maintain an 
up-to-date list of acceptable types of documentation.

ARIN will proceed with processing transfer requests even if the number 
resources of the combined organizations exceed what can be justified 
under current ARIN transfer policy as defined in section 8.5. In that 
event, ARIN will work with the resource holder(s) to transfer the extra 
number resources to other organization(s) or accept a voluntary return 
of the extra number resources to ARIN.

8.3. Transfers between Specified Recipients within the ARIN Region

In addition to transfers under section 8.2, IPv4 numbers resources and 
ASNs may be transferred according to the following conditions.

Conditions on source of the transfer:

 > The source entity must be the current registered holder of the IPv4 
address resources, and not be involved in any dispute as to the status 
of those resources.

 > The source entity must not have received a transfer, allocation, or 
assignment of IPv4 number resources from ARIN for the 12 months prior to 
the approval of a transfer request. This restriction does not include 
M&A transfers.

Conditions on recipient of the transfer:

 > The recipients must meet the transfer requirements as defined in 
section 8.5.

 > The resources transferred will be subject to current ARIN policies.

8.4. Inter-RIR Transfers to Specified Recipients

Inter-regional transfers may take place only via RIRs who agree to the 
transfer and share reciprocal, compatible, needs-based policies.

Conditions on source of the transfer:

 > The source entity must be the current rights holder of the IPv4 
address resources recognized by the RIR responsible for the resources, 
and not be involved in any dispute as to the status of those resources.

 > Source entities outside of the ARIN region must meet any requirements 
defined by the RIR where the source entity holds the registration.

 > Source entities within the ARIN region must not have received a 
transfer, allocation, or assignment of IPv4 number resources from ARIN 
for the 12 months prior to the approval of a transfer request. This 
restriction does not include M&A transfers.

Conditions on recipient of the transfer:

 > The conditions on a recipient outside of the ARIN region will be 
defined by the policies of the receiving RIR.

 > Recipients within the ARIN region must meet the transfer requirements 
as defined in section 8.5.

 > Recipients within the ARIN region will be subject to current ARIN 
policies.

8.5. Specified Transfer Recipient Requirements

8.5.1. Registration Services Agreement

Transfer recipients must sign an RSA for the resources being received.

8.5.2. Operational Use

ARIN allocates or assigns blocks of IP addresses to organizations via 
transfer solely for the purpose of use on an operational network.

8.5.3. Minimum transfer size

ARIN's minimum transfer size is a /24.

8.5.4. Initial block

Organizations without direct assignments or allocations from ARIN 
qualify for transfer of an initial block of ARIN's minimum transfer size.

8.5.5. Block size

Organizations may qualify for the transfer of a larger initial block, or 
an additional block, by providing documentation to ARIN which details 
the use of at least 50% of the requested block size within 24 months. An 
officer of the organization shall attest to the documentation provided 
to ARIN.

8.5.6. Efficient utilization of previous blocks

Organizations with direct assignments or allocations from ARIN must have 
efficiently utilized at least 50% of every block in order to receive 
additional space. This includes all space reassigned to their customers.

Comments:

Timetable for implementation: immediately

Anything else: A redline has been provided to help the community 
understand the changes that have been made to the NRPM.


From info at arin.net  Tue Jun 21 12:13:49 2016
From: info at arin.net (ARIN)
Date: Tue, 21 Jun 2016 12:13:49 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-1: Reserved Pool
	Transfer Policy
Message-ID: <576967BD.9020400@arin.net>

On 16 June 2016 the ARIN Advisory Council (AC) advanced the following 
Draft Policy to Recommended Draft Policy status:

ARIN-2016-1: Reserved Pool Transfer Policy

The text of the Recommended Draft Policy is below, and may also be found at:
https://www.arin.net/policy/proposals/2016_1.html

You are encouraged to discuss all Recommended Draft Policies on PPML 
prior to their presentation at the next ARIN Public Policy Consultation 
(PPC). PPML and PPC discussions are invaluable to the AC when 
determining community consensus.

The 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)

Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy

Date: 21 June 2016

AC assessment of conformance with the Principles of Internet Number 
Resource Policy:

This proposal enables fair and impartial number resource administration 
by ensuring that IPv4 resources, which are specially designated for 
critical infrastructure and IPv6 transition, are readily available for 
many years into the future. This is done by ensuring the resources 
remain in their originally designated pool rather than being moved into 
the general IPv4 address pool via a transfer.  This proposal is 
technically sound and is supported by the community.

Problem Statement:

Section 8 of the current NRPM does not distinguish between the transfer 
of blocks from addresses that have been reserved for specific uses and 
other addresses that can be transferred. In sections 4.4 and 4.10 there 
are specific address blocks set aside, based on the need for critical 
infrastructure and IPv6 transitions. Two issues arise if transfers of 
reserved address space occur under the current language of section 8. 
First, if transfers of 4.4 or 4.10 space occur under the current policy 
requirements set forth in sections 8.3 and 8.4, the recipients will be 
able to acquire space that was originally reserved for a specific 
purpose without ever providing evidence that they will be using the 
space for either critical infrastructure or IPv6 transition. Second, if 
we allow an allocation or assignment from the block reserved in section 
4.10 to be transferred out of the region, it would complicate the single 
aggregate from which providers are being asked to allow in block sizes 
smaller than a /24. This policy would limit the transfer of addresses 
from reserved pools.

Policy statement:

Add to Section 8.3 and Section 8.4 under the "Conditions on source of 
the transfer:"

Address resources from a reserved pool (including those designated in 
Section 4.4 and 4.10) are not eligible for transfer.

Timetable for implementation: Immediate

##########

ARIN STAFF & LEGAL ASSESSMENT
Draft Policy ARIN-2016-1
RESERVED POOL TRANSFER POLICY
https://www.arin.net/policy/proposals/2016_1.html

Date of Assessment: 13 June 2016
___
1. Summary (Staff Understanding)

This policy would make IPv4 addresses issued under NRPM 4.4 and 4.10 
ineligible for transfer inside the NRPM 8.3 and 8.4 transfer policies.
___
2. Comments

A. ARIN Staff Comments

* If this policy is implemented, ARIN staff would not allow NRPM 8.3 and 
8.4 transfers to include IPv4 addresses previously issued under NRPM 4.4 
and 4.10 policies.

* ARIN staff would continue to allow IPv4 addresses previously issued 
under NRPM 4.4 and 4.10 to be included in Merger and Acquisition (NRPM 
8.2) transfers.

* This policy could be implemented as written.

B. ARIN General Counsel ? Legal Assessment

The policy does not create a material legal issue. It should be noted 
that ARIN does permit transfers of IPV4 resources pursuant to 8.3 and 
8.4. This policy is an exception to that transferability and is 
consistent with the intent and of the policy by which these allocations 
were made.
___
3. Resource Impact

Implementation of this policy would have minimal resource impact. It is 
estimated that implementation would occur within 3 months after 
ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

* Updated guidelines and internal procedures

* Staff training
___
4. Proposal / Draft Policy Text Assessed

Draft Policy ARIN-2016-1
Reserved Pool Transfer Policy

Date: 22 March 2016

Problem Statement:

Section 8 of the current NRPM does not distinguish between the transfer 
of blocks from addresses that have been reserved for specific uses and 
other addresses that can be transferred. In sections 4.4 and 4.10 there 
are specific address blocks set aside, based on the need for critical 
infrastructure and IPv6 transitions. Two issues arise if transfers of 
reserved address space occur under the current language of section 8. 
First, if transfers of 4.4 or 4.10 space occur under the current policy 
requirements set forth in sections 8.3 and 8.4, the recipients will be 
able to acquire space that was originally reserved for a specific 
purpose without ever providing evidence that they will be using the 
space for either critical infrastructure or IPv6 transition. Second, if 
we allow an allocation or assignment from the block reserved in section 
4.10 to be transferred out of the region, it would complicate the single 
aggregate from which providers are being asked to allow in block sizes 
smaller than a /24. This policy would limit the transfer of addresses 
from reserved pools.

Policy statement:

Add to Section 8.3 and Section 8.4 under the "Conditions on source of 
the transfer:"

Address resources from a reserved pool (including those designated in 
Section 4.4 and 4.10) are not eligible for transfer.

Timetable for implementation: Immediate


From owen at delong.com  Tue Jun 21 12:16:25 2016
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Jun 2016 09:16:25 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <576964F3.3010409@arin.net>
References: <576964F3.3010409@arin.net>
Message-ID: <FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>

I am opposed to this policy proposal.

Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.

The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.

If we want to change IPv4 policy, then let?s change IPv4 policy in section 4.

If we want to change transfer policy for all resources, we can do that cleanly in section 8.

While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.

Owen

> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net> wrote:
> 
> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
> 
> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
> 
> This Draft Policy has been numbered and titled:
> 
> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
> 
> Draft Policy ARIN-2016-5 is below and can be found at:
> https://www.arin.net/policy/proposals/2016_5.html
> 
> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
> 
> 	> Enabling Fair and Impartial Number Resource Administration
> 	> Technically Sound
> 	> Supported by the Community
> 
> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
> 
> Date: 21 June 2016
> 
> Problem Statement
> 
> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
> 
> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
> 
> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.
> 
> The goals of this rewrite are as follows:
> 
> > Separate the criteria that is found in section 4 of the NRPM from the transfer process.
> 
> > Provide a clear set of criteria that should be applied across all IPv4 transfers.
> 
> > Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
> 
> > Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.
> 
> Policy statement:
> 
> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
> 
> ######
> 
> 8.2. Mergers, Acquisitions, and Reorganizations
> 
> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:
> 
> > The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
> 
> > The new entity must sign an RSA covering all resources to be transferred.
> 
> > The resources to be transferred will be subject to ARIN policies.
> 
> > The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
> 
> > For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.
> 
> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.
> 
> 8.3. Transfers between Specified Recipients within the ARIN Region
> 
> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.
> 
> Conditions on source of the transfer:
> 
> > The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
> 
> > The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
> 
> Conditions on recipient of the transfer:
> 
> > The recipients must meet the transfer requirements as defined in section 8.5.
> 
> > The resources transferred will be subject to current ARIN policies.
> 
> 8.4. Inter-RIR Transfers to Specified Recipients
> 
> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
> 
> Conditions on source of the transfer:
> 
> > The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
> 
> > Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
> 
> > Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
> 
> Conditions on recipient of the transfer:
> 
> > The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
> 
> > Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
> 
> > Recipients within the ARIN region will be subject to current ARIN policies.
> 
> 8.5. Specified Transfer Recipient Requirements
> 
> 8.5.1. Registration Services Agreement
> 
> Transfer recipients must sign an RSA for the resources being received.
> 
> 8.5.2. Operational Use
> 
> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
> 
> 8.5.3. Minimum transfer size
> 
> ARIN's minimum transfer size is a /24.
> 
> 8.5.4. Initial block
> 
> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.
> 
> 8.5.5. Block size
> 
> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
> 
> 8.5.6. Efficient utilization of previous blocks
> 
> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.
> 
> Comments:
> 
> Timetable for implementation: immediately
> 
> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Tue Jun 21 12:17:22 2016
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Jun 2016 09:17:22 -0700
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-1: Reserved Pool
	Transfer Policy
In-Reply-To: <576967BD.9020400@arin.net>
References: <576967BD.9020400@arin.net>
Message-ID: <87164683-17BE-48D2-B38A-8E91CD237C82@delong.com>

I support this proposal as written.

Owen

> On Jun 21, 2016, at 09:13 , ARIN <info at arin.net> wrote:
> 
> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status:
> 
> ARIN-2016-1: Reserved Pool Transfer Policy
> 
> The text of the Recommended Draft Policy is below, and may also be found at:
> https://www.arin.net/policy/proposals/2016_1.html
> 
> You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus.
> 
> The 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)
> 
> Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
> 
> Date: 21 June 2016
> 
> AC assessment of conformance with the Principles of Internet Number Resource Policy:
> 
> This proposal enables fair and impartial number resource administration by ensuring that IPv4 resources, which are specially designated for critical infrastructure and IPv6 transition, are readily available for many years into the future. This is done by ensuring the resources remain in their originally designated pool rather than being moved into the general IPv4 address pool via a transfer.  This proposal is technically sound and is supported by the community.
> 
> Problem Statement:
> 
> Section 8 of the current NRPM does not distinguish between the transfer of blocks from addresses that have been reserved for specific uses and other addresses that can be transferred. In sections 4.4 and 4.10 there are specific address blocks set aside, based on the need for critical infrastructure and IPv6 transitions. Two issues arise if transfers of reserved address space occur under the current language of section 8. First, if transfers of 4.4 or 4.10 space occur under the current policy requirements set forth in sections 8.3 and 8.4, the recipients will be able to acquire space that was originally reserved for a specific purpose without ever providing evidence that they will be using the space for either critical infrastructure or IPv6 transition. Second, if we allow an allocation or assignment from the block reserved in section 4.10 to be transferred out of the region, it would complicate the single aggregate from which providers are being asked to allow in block sizes smaller than a /24. This policy would limit the transfer of addresses from reserved pools.
> 
> Policy statement:
> 
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the transfer:"
> 
> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
> 
> Timetable for implementation: Immediate
> 
> ##########
> 
> ARIN STAFF & LEGAL ASSESSMENT
> Draft Policy ARIN-2016-1
> RESERVED POOL TRANSFER POLICY
> https://www.arin.net/policy/proposals/2016_1.html
> 
> Date of Assessment: 13 June 2016
> ___
> 1. Summary (Staff Understanding)
> 
> This policy would make IPv4 addresses issued under NRPM 4.4 and 4.10 ineligible for transfer inside the NRPM 8.3 and 8.4 transfer policies.
> ___
> 2. Comments
> 
> A. ARIN Staff Comments
> 
> * If this policy is implemented, ARIN staff would not allow NRPM 8.3 and 8.4 transfers to include IPv4 addresses previously issued under NRPM 4.4 and 4.10 policies.
> 
> * ARIN staff would continue to allow IPv4 addresses previously issued under NRPM 4.4 and 4.10 to be included in Merger and Acquisition (NRPM 8.2) transfers.
> 
> * This policy could be implemented as written.
> 
> B. ARIN General Counsel ? Legal Assessment
> 
> The policy does not create a material legal issue. It should be noted that ARIN does permit transfers of IPV4 resources pursuant to 8.3 and 8.4. This policy is an exception to that transferability and is consistent with the intent and of the policy by which these allocations were made.
> ___
> 3. Resource Impact
> 
> Implementation of this policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement:
> 
> * Updated guidelines and internal procedures
> 
> * Staff training
> ___
> 4. Proposal / Draft Policy Text Assessed
> 
> Draft Policy ARIN-2016-1
> Reserved Pool Transfer Policy
> 
> Date: 22 March 2016
> 
> Problem Statement:
> 
> Section 8 of the current NRPM does not distinguish between the transfer of blocks from addresses that have been reserved for specific uses and other addresses that can be transferred. In sections 4.4 and 4.10 there are specific address blocks set aside, based on the need for critical infrastructure and IPv6 transitions. Two issues arise if transfers of reserved address space occur under the current language of section 8. First, if transfers of 4.4 or 4.10 space occur under the current policy requirements set forth in sections 8.3 and 8.4, the recipients will be able to acquire space that was originally reserved for a specific purpose without ever providing evidence that they will be using the space for either critical infrastructure or IPv6 transition. Second, if we allow an allocation or assignment from the block reserved in section 4.10 to be transferred out of the region, it would complicate the single aggregate from which providers are being asked to allow in block sizes smaller than a /24. This policy would limit the transfer of addresses from reserved pools.
> 
> Policy statement:
> 
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the transfer:"
> 
> Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.
> 
> Timetable for implementation: Immediate
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From andrew.dul at quark.net  Wed Jun 22 11:46:27 2016
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 22 Jun 2016 08:46:27 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
Message-ID: <782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>

As the primary author of this draft policy, I respectfully disagree with
my AC colleague. 

Now that the free pool has been depleted, it is time to look toward what
future IPv4 (primarily transfer) policy should do.  While this policy
looks complicated, its intention is to create a very simple transfer
policy which allows businesses to predictably and efficiently transfer
IPv4 resources to meet their requirements.

I share with you here a redline which shows the changes that would be
made to section 8.

Andrew

On 6/21/2016 9:16 AM, Owen DeLong wrote:
> I am opposed to this policy proposal.
>
> Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.
>
> The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.
>
> If we want to change IPv4 policy, then let?s change IPv4 policy in section 4.
>
> If we want to change transfer policy for all resources, we can do that cleanly in section 8.
>
> While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.
>
> Owen
>
>> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net> wrote:
>>
>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
>>
>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> This Draft Policy has been numbered and titled:
>>
>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> Draft Policy ARIN-2016-5 is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_5.html
>>
>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
>>
>> 	> Enabling Fair and Impartial Number Resource Administration
>> 	> Technically Sound
>> 	> Supported by the Community
>>
>> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> Date: 21 June 2016
>>
>> Problem Statement
>>
>> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
>>
>> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
>>
>> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.
>>
>> The goals of this rewrite are as follows:
>>
>>> Separate the criteria that is found in section 4 of the NRPM from the transfer process.
>>> Provide a clear set of criteria that should be applied across all IPv4 transfers.
>>> Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
>>> Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.
>> Policy statement:
>>
>> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>>
>> ######
>>
>> 8.2. Mergers, Acquisitions, and Reorganizations
>>
>> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:
>>
>>> The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
>>> The new entity must sign an RSA covering all resources to be transferred.
>>> The resources to be transferred will be subject to ARIN policies.
>>> The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
>>> For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.
>> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.
>>
>> 8.3. Transfers between Specified Recipients within the ARIN Region
>>
>> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
>>> The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The recipients must meet the transfer requirements as defined in section 8.5.
>>> The resources transferred will be subject to current ARIN policies.
>> 8.4. Inter-RIR Transfers to Specified Recipients
>>
>> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
>>> Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
>>> Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
>>> Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
>>> Recipients within the ARIN region will be subject to current ARIN policies.
>> 8.5. Specified Transfer Recipient Requirements
>>
>> 8.5.1. Registration Services Agreement
>>
>> Transfer recipients must sign an RSA for the resources being received.
>>
>> 8.5.2. Operational Use
>>
>> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
>>
>> 8.5.3. Minimum transfer size
>>
>> ARIN's minimum transfer size is a /24.
>>
>> 8.5.4. Initial block
>>
>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.
>>
>> 8.5.5. Block size
>>
>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>>
>> 8.5.6. Efficient utilization of previous blocks
>>
>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.
>>
>> Comments:
>>
>> Timetable for implementation: immediately
>>
>> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Post-IPv4 Free-Pool Depletion Transfer Policy (NRPM 8	redline) - 20160609.pdf
Type: application/pdf
Size: 81312 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160622/d65d0d42/attachment.pdf>

From mike at iptrading.com  Wed Jun 22 12:00:18 2016
From: mike at iptrading.com (Mike Burns)
Date: Wed, 22 Jun 2016 12:00:18 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
References: <576964F3.3010409@arin.net>	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
Message-ID: <000801d1cc9f$2c775720$85660560$@iptrading.com>

Hi Andrew,

I have a couple of questions about the policy proposal.

 On Section 8.5.2 Operational Use.

First, why is this section even in there, does it serve some particular purpose?

Second, why does it refer to assignments and allocations in a section devoted to transfers?

Overall, do we still need the verbiage about "Specified" recipients, why not just recipients?

And lastly for now, does this mean that new buyers will automatically qualify for the minimum without any needs test?


My initial impression is positive. 

Regards,
Mike







-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul
Sent: Wednesday, June 22, 2016 11:46 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

As the primary author of this draft policy, I respectfully disagree with my AC colleague. 

Now that the free pool has been depleted, it is time to look toward what future IPv4 (primarily transfer) policy should do.  While this policy looks complicated, its intention is to create a very simple transfer policy which allows businesses to predictably and efficiently transfer
IPv4 resources to meet their requirements.

I share with you here a redline which shows the changes that would be made to section 8.

Andrew

On 6/21/2016 9:16 AM, Owen DeLong wrote:
> I am opposed to this policy proposal.
>
> Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.
>
> The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.
>
> If we want to change IPv4 policy, then let?s change IPv4 policy in section 4.
>
> If we want to change transfer policy for all resources, we can do that cleanly in section 8.
>
> While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.
>
> Owen
>
>> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net> wrote:
>>
>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
>>
>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> This Draft Policy has been numbered and titled:
>>
>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer 
>> Policy
>>
>> Draft Policy ARIN-2016-5 is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_5.html
>>
>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
>>
>> 	> Enabling Fair and Impartial Number Resource Administration
>> 	> Technically Sound
>> 	> Supported by the Community
>>
>> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer 
>> Policy
>>
>> Date: 21 June 2016
>>
>> Problem Statement
>>
>> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
>>
>> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
>>
>> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.
>>
>> The goals of this rewrite are as follows:
>>
>>> Separate the criteria that is found in section 4 of the NRPM from the transfer process.
>>> Provide a clear set of criteria that should be applied across all IPv4 transfers.
>>> Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
>>> Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.
>> Policy statement:
>>
>> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>>
>> ######
>>
>> 8.2. Mergers, Acquisitions, and Reorganizations
>>
>> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:
>>
>>> The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
>>> The new entity must sign an RSA covering all resources to be transferred.
>>> The resources to be transferred will be subject to ARIN policies.
>>> The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
>>> For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.
>> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.
>>
>> 8.3. Transfers between Specified Recipients within the ARIN Region
>>
>> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
>>> The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The recipients must meet the transfer requirements as defined in section 8.5.
>>> The resources transferred will be subject to current ARIN policies.
>> 8.4. Inter-RIR Transfers to Specified Recipients
>>
>> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
>>> Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
>>> Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
>>> Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
>>> Recipients within the ARIN region will be subject to current ARIN policies.
>> 8.5. Specified Transfer Recipient Requirements
>>
>> 8.5.1. Registration Services Agreement
>>
>> Transfer recipients must sign an RSA for the resources being received.
>>
>> 8.5.2. Operational Use
>>
>> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
>>
>> 8.5.3. Minimum transfer size
>>
>> ARIN's minimum transfer size is a /24.
>>
>> 8.5.4. Initial block
>>
>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.
>>
>> 8.5.5. Block size
>>
>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>>
>> 8.5.6. Efficient utilization of previous blocks
>>
>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.
>>
>> Comments:
>>
>> Timetable for implementation: immediately
>>
>> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN 
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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 scottleibrand at gmail.com  Wed Jun 22 12:15:58 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 22 Jun 2016 11:15:58 -0500
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <000801d1cc9f$2c775720$85660560$@iptrading.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
Message-ID: <CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>

On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <mike at iptrading.com> wrote:

> Hi Andrew,
>
> I have a couple of questions about the policy proposal.
>
>  On Section 8.5.2 Operational Use.
>
> First, why is this section even in there, does it serve some particular
> purpose?
>

It prevents financial speculators, who have no operational use for the
addresses, from acquiring them for speculative purposes.


>
> Second, why does it refer to assignments and allocations in a section
> devoted to transfers?
>
> Overall, do we still need the verbiage about "Specified" recipients, why
> not just recipients?
>

ARIN allocates or assigns blocks of IP addresses to organizations via
transfer.  An organization cannot receive a transfer directly: ARIN must
update the registration of the allocation or assignment to reflect the
specified recipient as the new holder.  This simply reflects existing
policy language and operational practice: nothing is changing here.


> And lastly for now, does this mean that new buyers will automatically
> qualify for the minimum without any needs test?
>

There is still a needs test, but it is now much simpler: recipients without
any previous allocations or assignments (directly or via transfer) simply
have to attest to the fact that the addresses are needed for use on an
operational network.  That is effectively the same as "without any needs
test" for entities operating a network that will actually use the
addresses, while completely locking out speculators who are unwilling to
engage in fraud and risk losing the addresses they acquired.

-Scott


>
> My initial impression is positive.
>
> Regards,
> Mike
>
>
>
>
>
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Andrew Dul
> Sent: Wednesday, June 22, 2016 11:46 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5:
> Post-IPv4-Free-Pool-Depletion Transfer Policy
>
> As the primary author of this draft policy, I respectfully disagree with
> my AC colleague.
>
> Now that the free pool has been depleted, it is time to look toward what
> future IPv4 (primarily transfer) policy should do.  While this policy looks
> complicated, its intention is to create a very simple transfer policy which
> allows businesses to predictably and efficiently transfer
> IPv4 resources to meet their requirements.
>
> I share with you here a redline which shows the changes that would be made
> to section 8.
>
> Andrew
>
> On 6/21/2016 9:16 AM, Owen DeLong wrote:
> > I am opposed to this policy proposal.
> >
> > Given that we are now in a world where the only way to obtain IPv4 space
> is through transfers, I think it makes much more sense to put policy
> changes for IPv4 transfers into section 4 and retain the simplified text
> that exists today in section 8 rather than copying most of section 4 into
> section 8 with revisions in the process.
> >
> > The likely outcome of such an exercise is to create a number of changes
> which may or may not be fully understood by the community. The interaction
> of this rewrite with other types of transferable resources (AS numbers at
> the moment) must also be carefully considered.
> >
> > If we want to change IPv4 policy, then let?s change IPv4 policy in
> section 4.
> >
> > If we want to change transfer policy for all resources, we can do that
> cleanly in section 8.
> >
> > While the NRPM may not be a perfect model of a structured document, this
> proposal would make it significantly worse.
> >
> > Owen
> >
> >> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net> wrote:
> >>
> >> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following
> Proposal to Draft Policy status:
> >>
> >> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
> >>
> >> This Draft Policy has been numbered and titled:
> >>
> >> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
> >> Policy
> >>
> >> Draft Policy ARIN-2016-5 is below and can be found at:
> >> https://www.arin.net/policy/proposals/2016_5.html
> >>
> >> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
> >>
> >>      > Enabling Fair and Impartial Number Resource Administration
> >>      > Technically Sound
> >>      > Supported by the Community
> >>
> >> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
> >> Policy
> >>
> >> Date: 21 June 2016
> >>
> >> Problem Statement
> >>
> >> Section 4 of the Number Policy Resource Manual was developed over the
> past 15+ years primarily to conservatively manage the IPv4 number free
> pool. Since the IPv4 free pool was depleted in 2015, the policies which
> developed since ARIN's inception may now not be as relevant now that the
> primary function of the registry, with regard to IPv4 numbers, is to record
> transfers.
> >>
> >> Since section 4 of the NRPM now contains many use cases that are not as
> relevant, it makes sense to streamline the transfer process and to
> specifically outline the criteria that should be used to process transfers.
> >>
> >> Therefore, we propose the following rewrite of the transfer policy,
> section 8 of the NRPM.
> >>
> >> The goals of this rewrite are as follows:
> >>
> >>> Separate the criteria that is found in section 4 of the NRPM from the
> transfer process.
> >>> Provide a clear set of criteria that should be applied across all IPv4
> transfers.
> >>> Lower the thresholds on utilization and future allocation size to
> negate the necessity of the corner cases which are currently enumerated in
> section 4 of the NRPM.
> >>> Reduce the complexity that is currently required for transfers, by
> applying simpler utilization criteria for current usage, and future
> allocation sizing.
> >> Policy statement:
> >>
> >> Add new section 8.5; update sections 8.2-8.4 as follows to reference
> 8.5.
> >>
> >> ######
> >>
> >> 8.2. Mergers, Acquisitions, and Reorganizations
> >>
> >> ARIN will consider requests for the transfer of number resources in the
> case of mergers, acquisitions, and reorganizations under the following
> conditions:
> >>
> >>> The current registrant must not be involved in any dispute as to the
> status of the resources to be transferred.
> >>> The new entity must sign an RSA covering all resources to be
> transferred.
> >>> The resources to be transferred will be subject to ARIN policies.
> >>> The minimum transfer size is the smaller of the original allocation
> size or the applicable minimum allocation size in current policy.
> >>> For mergers and acquisition transfers, the recipient entity must
> provide evidence that they have acquired assets that use the resources to
> be transferred from the current registrant. ARIN will maintain an
> up-to-date list of acceptable types of documentation.
> >> ARIN will proceed with processing transfer requests even if the number
> resources of the combined organizations exceed what can be justified under
> current ARIN transfer policy as defined in section 8.5. In that event, ARIN
> will work with the resource holder(s) to transfer the extra number
> resources to other organization(s) or accept a voluntary return of the
> extra number resources to ARIN.
> >>
> >> 8.3. Transfers between Specified Recipients within the ARIN Region
> >>
> >> In addition to transfers under section 8.2, IPv4 numbers resources and
> ASNs may be transferred according to the following conditions.
> >>
> >> Conditions on source of the transfer:
> >>
> >>> The source entity must be the current registered holder of the IPv4
> address resources, and not be involved in any dispute as to the status of
> those resources.
> >>> The source entity must not have received a transfer, allocation, or
> assignment of IPv4 number resources from ARIN for the 12 months prior to
> the approval of a transfer request. This restriction does not include M&A
> transfers.
> >> Conditions on recipient of the transfer:
> >>
> >>> The recipients must meet the transfer requirements as defined in
> section 8.5.
> >>> The resources transferred will be subject to current ARIN policies.
> >> 8.4. Inter-RIR Transfers to Specified Recipients
> >>
> >> Inter-regional transfers may take place only via RIRs who agree to the
> transfer and share reciprocal, compatible, needs-based policies.
> >>
> >> Conditions on source of the transfer:
> >>
> >>> The source entity must be the current rights holder of the IPv4
> address resources recognized by the RIR responsible for the resources, and
> not be involved in any dispute as to the status of those resources.
> >>> Source entities outside of the ARIN region must meet any requirements
> defined by the RIR where the source entity holds the registration.
> >>> Source entities within the ARIN region must not have received a
> transfer, allocation, or assignment of IPv4 number resources from ARIN for
> the 12 months prior to the approval of a transfer request. This restriction
> does not include M&A transfers.
> >> Conditions on recipient of the transfer:
> >>
> >>> The conditions on a recipient outside of the ARIN region will be
> defined by the policies of the receiving RIR.
> >>> Recipients within the ARIN region must meet the transfer requirements
> as defined in section 8.5.
> >>> Recipients within the ARIN region will be subject to current ARIN
> policies.
> >> 8.5. Specified Transfer Recipient Requirements
> >>
> >> 8.5.1. Registration Services Agreement
> >>
> >> Transfer recipients must sign an RSA for the resources being received.
> >>
> >> 8.5.2. Operational Use
> >>
> >> ARIN allocates or assigns blocks of IP addresses to organizations via
> transfer solely for the purpose of use on an operational network.
> >>
> >> 8.5.3. Minimum transfer size
> >>
> >> ARIN's minimum transfer size is a /24.
> >>
> >> 8.5.4. Initial block
> >>
> >> Organizations without direct assignments or allocations from ARIN
> qualify for transfer of an initial block of ARIN's minimum transfer size.
> >>
> >> 8.5.5. Block size
> >>
> >> Organizations may qualify for the transfer of a larger initial block,
> or an additional block, by providing documentation to ARIN which details
> the use of at least 50% of the requested block size within 24 months. An
> officer of the organization shall attest to the documentation provided to
> ARIN.
> >>
> >> 8.5.6. Efficient utilization of previous blocks
> >>
> >> Organizations with direct assignments or allocations from ARIN must
> have efficiently utilized at least 50% of every block in order to receive
> additional space. This includes all space reassigned to their customers.
> >>
> >> Comments:
> >>
> >> Timetable for implementation: immediately
> >>
> >> Anything else: A redline has been provided to help the community
> understand the changes that have been made to the NRPM.
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to the ARIN
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160622/e746b3f8/attachment.htm>

From mike at iptrading.com  Wed Jun 22 12:19:30 2016
From: mike at iptrading.com (Mike Burns)
Date: Wed, 22 Jun 2016 12:19:30 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
Message-ID: <001801d1cca1$dad702a0$908507e0$@iptrading.com>

Hi Scott,

 

OK, I understand how that can be relevant in concert with the lack of needs test for the minimum. 

 

So is there no needs test for the minimum?

 

Regards,
Mike

 

 

 

From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
Sent: Wednesday, June 22, 2016 12:16 PM
To: Mike Burns <mike at iptrading.com>
Cc: Andrew Dul <andrew.dul at quark.net>; ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

 

On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

Hi Andrew,

I have a couple of questions about the policy proposal.

 On Section 8.5.2 Operational Use.

First, why is this section even in there, does it serve some particular purpose?

 

It prevents financial speculators, who have no operational use for the addresses, from acquiring them for speculative purposes.

 


Second, why does it refer to assignments and allocations in a section devoted to transfers?

Overall, do we still need the verbiage about "Specified" recipients, why not just recipients?

 

ARIN allocates or assigns blocks of IP addresses to organizations via transfer.  An organization cannot receive a transfer directly: ARIN must update the registration of the allocation or assignment to reflect the specified recipient as the new holder.  This simply reflects existing policy language and operational practice: nothing is changing here.

 


And lastly for now, does this mean that new buyers will automatically qualify for the minimum without any needs test?

 

There is still a needs test, but it is now much simpler: recipients without any previous allocations or assignments (directly or via transfer) simply have to attest to the fact that the addresses are needed for use on an operational network.  That is effectively the same as "without any needs test" for entities operating a network that will actually use the addresses, while completely locking out speculators who are unwilling to engage in fraud and risk losing the addresses they acquired.

 

-Scott

 



My initial impression is positive.

Regards,
Mike








-----Original Message-----
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 Andrew Dul
Sent: Wednesday, June 22, 2016 11:46 AM
To: arin-ppml at arin.net <mailto:arin-ppml at arin.net> 
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

As the primary author of this draft policy, I respectfully disagree with my AC colleague.

Now that the free pool has been depleted, it is time to look toward what future IPv4 (primarily transfer) policy should do.  While this policy looks complicated, its intention is to create a very simple transfer policy which allows businesses to predictably and efficiently transfer
IPv4 resources to meet their requirements.

I share with you here a redline which shows the changes that would be made to section 8.

Andrew

On 6/21/2016 9:16 AM, Owen DeLong wrote:
> I am opposed to this policy proposal.
>
> Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.
>
> The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.
>
> If we want to change IPv4 policy, then let?s change IPv4 policy in section 4.
>
> If we want to change transfer policy for all resources, we can do that cleanly in section 8.
>
> While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.
>
> Owen
>
>> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net <mailto:info at arin.net> > wrote:
>>
>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
>>
>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> This Draft Policy has been numbered and titled:
>>
>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
>> Policy
>>
>> Draft Policy ARIN-2016-5 is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_5.html
>>
>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
>>
>>      > Enabling Fair and Impartial Number Resource Administration
>>      > Technically Sound
>>      > Supported by the Community
>>
>> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
>> Policy
>>
>> Date: 21 June 2016
>>
>> Problem Statement
>>
>> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
>>
>> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
>>
>> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.
>>
>> The goals of this rewrite are as follows:
>>
>>> Separate the criteria that is found in section 4 of the NRPM from the transfer process.
>>> Provide a clear set of criteria that should be applied across all IPv4 transfers.
>>> Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
>>> Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.
>> Policy statement:
>>
>> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>>
>> ######
>>
>> 8.2. Mergers, Acquisitions, and Reorganizations
>>
>> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:
>>
>>> The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
>>> The new entity must sign an RSA covering all resources to be transferred.
>>> The resources to be transferred will be subject to ARIN policies.
>>> The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
>>> For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.
>> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.
>>
>> 8.3. Transfers between Specified Recipients within the ARIN Region
>>
>> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
>>> The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The recipients must meet the transfer requirements as defined in section 8.5.
>>> The resources transferred will be subject to current ARIN policies.
>> 8.4. Inter-RIR Transfers to Specified Recipients
>>
>> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
>>> Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
>>> Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
>>> Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
>>> Recipients within the ARIN region will be subject to current ARIN policies.
>> 8.5. Specified Transfer Recipient Requirements
>>
>> 8.5.1. Registration Services Agreement
>>
>> Transfer recipients must sign an RSA for the resources being received.
>>
>> 8.5.2. Operational Use
>>
>> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
>>
>> 8.5.3. Minimum transfer size
>>
>> ARIN's minimum transfer size is a /24.
>>
>> 8.5.4. Initial block
>>
>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.
>>
>> 8.5.5. Block size
>>
>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>>
>> 8.5.6. Efficient utilization of previous blocks
>>
>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.
>>
>> Comments:
>>
>> Timetable for implementation: immediately
>>
>> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net> ).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net <mailto:info at arin.net>  if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <mailto:info at arin.net>  if you experience any issues.



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

 

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

From mike at iptrading.com  Wed Jun 22 12:24:15 2016
From: mike at iptrading.com (Mike Burns)
Date: Wed, 22 Jun 2016 12:24:15 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
Message-ID: <001d01d1cca2$84c498e0$8e4dcaa0$@iptrading.com>

Hi Scott,

 

I apologize, I did not scroll down and see  your other comments.

My fault for top-posting.

 

If recipients have to attest that they are using the addresses on an operational network, why do we need 8.5.2? The attestation would as you say prevent financial speculators from acquiring them for speculative purposes.

 

Is the attestation required for first time initial transfers of the minimum?

It doesn?t seem to read that way.

 

Regards,
Mike

 

 

 

 

 

 

From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
Sent: Wednesday, June 22, 2016 12:16 PM
To: Mike Burns <mike at iptrading.com>
Cc: Andrew Dul <andrew.dul at quark.net>; ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

 

On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

Hi Andrew,

I have a couple of questions about the policy proposal.

 On Section 8.5.2 Operational Use.

First, why is this section even in there, does it serve some particular purpose?

 

It prevents financial speculators, who have no operational use for the addresses, from acquiring them for speculative purposes.

 


Second, why does it refer to assignments and allocations in a section devoted to transfers?

Overall, do we still need the verbiage about "Specified" recipients, why not just recipients?

 

ARIN allocates or assigns blocks of IP addresses to organizations via transfer.  An organization cannot receive a transfer directly: ARIN must update the registration of the allocation or assignment to reflect the specified recipient as the new holder.  This simply reflects existing policy language and operational practice: nothing is changing here.

 


And lastly for now, does this mean that new buyers will automatically qualify for the minimum without any needs test?

 

There is still a needs test, but it is now much simpler: recipients without any previous allocations or assignments (directly or via transfer) simply have to attest to the fact that the addresses are needed for use on an operational network.  That is effectively the same as "without any needs test" for entities operating a network that will actually use the addresses, while completely locking out speculators who are unwilling to engage in fraud and risk losing the addresses they acquired.

 

-Scott

 



My initial impression is positive.

Regards,
Mike








-----Original Message-----
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 Andrew Dul
Sent: Wednesday, June 22, 2016 11:46 AM
To: arin-ppml at arin.net <mailto:arin-ppml at arin.net> 
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

As the primary author of this draft policy, I respectfully disagree with my AC colleague.

Now that the free pool has been depleted, it is time to look toward what future IPv4 (primarily transfer) policy should do.  While this policy looks complicated, its intention is to create a very simple transfer policy which allows businesses to predictably and efficiently transfer
IPv4 resources to meet their requirements.

I share with you here a redline which shows the changes that would be made to section 8.

Andrew

On 6/21/2016 9:16 AM, Owen DeLong wrote:
> I am opposed to this policy proposal.
>
> Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.
>
> The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.
>
> If we want to change IPv4 policy, then let?s change IPv4 policy in section 4.
>
> If we want to change transfer policy for all resources, we can do that cleanly in section 8.
>
> While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.
>
> Owen
>
>> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net <mailto:info at arin.net> > wrote:
>>
>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
>>
>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> This Draft Policy has been numbered and titled:
>>
>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
>> Policy
>>
>> Draft Policy ARIN-2016-5 is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_5.html
>>
>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
>>
>>      > Enabling Fair and Impartial Number Resource Administration
>>      > Technically Sound
>>      > Supported by the Community
>>
>> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
>> Policy
>>
>> Date: 21 June 2016
>>
>> Problem Statement
>>
>> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
>>
>> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
>>
>> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.
>>
>> The goals of this rewrite are as follows:
>>
>>> Separate the criteria that is found in section 4 of the NRPM from the transfer process.
>>> Provide a clear set of criteria that should be applied across all IPv4 transfers.
>>> Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
>>> Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.
>> Policy statement:
>>
>> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>>
>> ######
>>
>> 8.2. Mergers, Acquisitions, and Reorganizations
>>
>> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:
>>
>>> The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
>>> The new entity must sign an RSA covering all resources to be transferred.
>>> The resources to be transferred will be subject to ARIN policies.
>>> The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
>>> For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.
>> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.
>>
>> 8.3. Transfers between Specified Recipients within the ARIN Region
>>
>> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
>>> The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The recipients must meet the transfer requirements as defined in section 8.5.
>>> The resources transferred will be subject to current ARIN policies.
>> 8.4. Inter-RIR Transfers to Specified Recipients
>>
>> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
>>> Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
>>> Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
>>> Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
>>> Recipients within the ARIN region will be subject to current ARIN policies.
>> 8.5. Specified Transfer Recipient Requirements
>>
>> 8.5.1. Registration Services Agreement
>>
>> Transfer recipients must sign an RSA for the resources being received.
>>
>> 8.5.2. Operational Use
>>
>> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
>>
>> 8.5.3. Minimum transfer size
>>
>> ARIN's minimum transfer size is a /24.
>>
>> 8.5.4. Initial block
>>
>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.
>>
>> 8.5.5. Block size
>>
>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>>
>> 8.5.6. Efficient utilization of previous blocks
>>
>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.
>>
>> Comments:
>>
>> Timetable for implementation: immediately
>>
>> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net> ).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net <mailto:info at arin.net>  if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <mailto:info at arin.net>  if you experience any issues.



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

 

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

From scottleibrand at gmail.com  Wed Jun 22 12:30:45 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 22 Jun 2016 11:30:45 -0500
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <001d01d1cca2$84c498e0$8e4dcaa0$@iptrading.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<001d01d1cca2$84c498e0$8e4dcaa0$@iptrading.com>
Message-ID: <CAGkMwz4hn6AvrvMFGcqkch96kMhOmWLup7pUk+tm-Fi9LTtf3w@mail.gmail.com>

On Wed, Jun 22, 2016 at 11:24 AM, Mike Burns <mike at iptrading.com> wrote:

> Hi Scott,
>
>
>
> I apologize, I did not scroll down and see  your other comments.
>
> My fault for top-posting.
>
>
>
> If recipients have to attest that they are using the addresses on an
> operational network, why do we need 8.5.2? The attestation would as you say
> prevent financial speculators from acquiring them for speculative purposes.
>
>
>
> Is the attestation required for first time initial transfers of the
> minimum?
>
> It doesn?t seem to read that way.
>

8.5.2 is the policy text that supports requiring the recipient to attest
that they are using the addresses on an operational network.  If that part
is unclear, we would welcome suggestions for improving the text.  There is
a further attestation in 8.5.5 as well for organizations requesting more
than the minimum.

-Scott

>

>
>
>
>
> *From:* Scott Leibrand [mailto:scottleibrand at gmail.com]
> *Sent:* Wednesday, June 22, 2016 12:16 PM
> *To:* Mike Burns <mike at iptrading.com>
> *Cc:* Andrew Dul <andrew.dul at quark.net>; ARIN-PPML List <
> arin-ppml at arin.net>
>
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2016-5:
> Post-IPv4-Free-Pool-Depletion Transfer Policy
>
>
>
> On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <mike at iptrading.com> wrote:
>
> Hi Andrew,
>
> I have a couple of questions about the policy proposal.
>
>  On Section 8.5.2 Operational Use.
>
> First, why is this section even in there, does it serve some particular
> purpose?
>
>
>
> It prevents financial speculators, who have no operational use for the
> addresses, from acquiring them for speculative purposes.
>
>
>
>
> Second, why does it refer to assignments and allocations in a section
> devoted to transfers?
>
> Overall, do we still need the verbiage about "Specified" recipients, why
> not just recipients?
>
>
>
> ARIN allocates or assigns blocks of IP addresses to organizations via
> transfer.  An organization cannot receive a transfer directly: ARIN must
> update the registration of the allocation or assignment to reflect the
> specified recipient as the new holder.  This simply reflects existing
> policy language and operational practice: nothing is changing here.
>
>
>
>
> And lastly for now, does this mean that new buyers will automatically
> qualify for the minimum without any needs test?
>
>
>
> There is still a needs test, but it is now much simpler: recipients
> without any previous allocations or assignments (directly or via transfer)
> simply have to attest to the fact that the addresses are needed for use on
> an operational network.  That is effectively the same as "without any needs
> test" for entities operating a network that will actually use the
> addresses, while completely locking out speculators who are unwilling to
> engage in fraud and risk losing the addresses they acquired.
>
>
>
> -Scott
>
>
>
>
>
> My initial impression is positive.
>
> Regards,
> Mike
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Andrew Dul
> Sent: Wednesday, June 22, 2016 11:46 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5:
> Post-IPv4-Free-Pool-Depletion Transfer Policy
>
> As the primary author of this draft policy, I respectfully disagree with
> my AC colleague.
>
> Now that the free pool has been depleted, it is time to look toward what
> future IPv4 (primarily transfer) policy should do.  While this policy looks
> complicated, its intention is to create a very simple transfer policy which
> allows businesses to predictably and efficiently transfer
> IPv4 resources to meet their requirements.
>
> I share with you here a redline which shows the changes that would be made
> to section 8.
>
> Andrew
>
> On 6/21/2016 9:16 AM, Owen DeLong wrote:
> > I am opposed to this policy proposal.
> >
> > Given that we are now in a world where the only way to obtain IPv4 space
> is through transfers, I think it makes much more sense to put policy
> changes for IPv4 transfers into section 4 and retain the simplified text
> that exists today in section 8 rather than copying most of section 4 into
> section 8 with revisions in the process.
> >
> > The likely outcome of such an exercise is to create a number of changes
> which may or may not be fully understood by the community. The interaction
> of this rewrite with other types of transferable resources (AS numbers at
> the moment) must also be carefully considered.
> >
> > If we want to change IPv4 policy, then let?s change IPv4 policy in
> section 4.
> >
> > If we want to change transfer policy for all resources, we can do that
> cleanly in section 8.
> >
> > While the NRPM may not be a perfect model of a structured document, this
> proposal would make it significantly worse.
> >
> > Owen
> >
> >> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net> wrote:
> >>
> >> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following
> Proposal to Draft Policy status:
> >>
> >> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
> >>
> >> This Draft Policy has been numbered and titled:
> >>
> >> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
> >> Policy
> >>
> >> Draft Policy ARIN-2016-5 is below and can be found at:
> >> https://www.arin.net/policy/proposals/2016_5.html
> >>
> >> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
> >>
> >>      > Enabling Fair and Impartial Number Resource Administration
> >>      > Technically Sound
> >>      > Supported by the Community
> >>
> >> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
> >> Policy
> >>
> >> Date: 21 June 2016
> >>
> >> Problem Statement
> >>
> >> Section 4 of the Number Policy Resource Manual was developed over the
> past 15+ years primarily to conservatively manage the IPv4 number free
> pool. Since the IPv4 free pool was depleted in 2015, the policies which
> developed since ARIN's inception may now not be as relevant now that the
> primary function of the registry, with regard to IPv4 numbers, is to record
> transfers.
> >>
> >> Since section 4 of the NRPM now contains many use cases that are not as
> relevant, it makes sense to streamline the transfer process and to
> specifically outline the criteria that should be used to process transfers.
> >>
> >> Therefore, we propose the following rewrite of the transfer policy,
> section 8 of the NRPM.
> >>
> >> The goals of this rewrite are as follows:
> >>
> >>> Separate the criteria that is found in section 4 of the NRPM from the
> transfer process.
> >>> Provide a clear set of criteria that should be applied across all IPv4
> transfers.
> >>> Lower the thresholds on utilization and future allocation size to
> negate the necessity of the corner cases which are currently enumerated in
> section 4 of the NRPM.
> >>> Reduce the complexity that is currently required for transfers, by
> applying simpler utilization criteria for current usage, and future
> allocation sizing.
> >> Policy statement:
> >>
> >> Add new section 8.5; update sections 8.2-8.4 as follows to reference
> 8.5.
> >>
> >> ######
> >>
> >> 8.2. Mergers, Acquisitions, and Reorganizations
> >>
> >> ARIN will consider requests for the transfer of number resources in the
> case of mergers, acquisitions, and reorganizations under the following
> conditions:
> >>
> >>> The current registrant must not be involved in any dispute as to the
> status of the resources to be transferred.
> >>> The new entity must sign an RSA covering all resources to be
> transferred.
> >>> The resources to be transferred will be subject to ARIN policies.
> >>> The minimum transfer size is the smaller of the original allocation
> size or the applicable minimum allocation size in current policy.
> >>> For mergers and acquisition transfers, the recipient entity must
> provide evidence that they have acquired assets that use the resources to
> be transferred from the current registrant. ARIN will maintain an
> up-to-date list of acceptable types of documentation.
> >> ARIN will proceed with processing transfer requests even if the number
> resources of the combined organizations exceed what can be justified under
> current ARIN transfer policy as defined in section 8.5. In that event, ARIN
> will work with the resource holder(s) to transfer the extra number
> resources to other organization(s) or accept a voluntary return of the
> extra number resources to ARIN.
> >>
> >> 8.3. Transfers between Specified Recipients within the ARIN Region
> >>
> >> In addition to transfers under section 8.2, IPv4 numbers resources and
> ASNs may be transferred according to the following conditions.
> >>
> >> Conditions on source of the transfer:
> >>
> >>> The source entity must be the current registered holder of the IPv4
> address resources, and not be involved in any dispute as to the status of
> those resources.
> >>> The source entity must not have received a transfer, allocation, or
> assignment of IPv4 number resources from ARIN for the 12 months prior to
> the approval of a transfer request. This restriction does not include M&A
> transfers.
> >> Conditions on recipient of the transfer:
> >>
> >>> The recipients must meet the transfer requirements as defined in
> section 8.5.
> >>> The resources transferred will be subject to current ARIN policies.
> >> 8.4. Inter-RIR Transfers to Specified Recipients
> >>
> >> Inter-regional transfers may take place only via RIRs who agree to the
> transfer and share reciprocal, compatible, needs-based policies.
> >>
> >> Conditions on source of the transfer:
> >>
> >>> The source entity must be the current rights holder of the IPv4
> address resources recognized by the RIR responsible for the resources, and
> not be involved in any dispute as to the status of those resources.
> >>> Source entities outside of the ARIN region must meet any requirements
> defined by the RIR where the source entity holds the registration.
> >>> Source entities within the ARIN region must not have received a
> transfer, allocation, or assignment of IPv4 number resources from ARIN for
> the 12 months prior to the approval of a transfer request. This restriction
> does not include M&A transfers.
> >> Conditions on recipient of the transfer:
> >>
> >>> The conditions on a recipient outside of the ARIN region will be
> defined by the policies of the receiving RIR.
> >>> Recipients within the ARIN region must meet the transfer requirements
> as defined in section 8.5.
> >>> Recipients within the ARIN region will be subject to current ARIN
> policies.
> >> 8.5. Specified Transfer Recipient Requirements
> >>
> >> 8.5.1. Registration Services Agreement
> >>
> >> Transfer recipients must sign an RSA for the resources being received.
> >>
> >> 8.5.2. Operational Use
> >>
> >> ARIN allocates or assigns blocks of IP addresses to organizations via
> transfer solely for the purpose of use on an operational network.
> >>
> >> 8.5.3. Minimum transfer size
> >>
> >> ARIN's minimum transfer size is a /24.
> >>
> >> 8.5.4. Initial block
> >>
> >> Organizations without direct assignments or allocations from ARIN
> qualify for transfer of an initial block of ARIN's minimum transfer size.
> >>
> >> 8.5.5. Block size
> >>
> >> Organizations may qualify for the transfer of a larger initial block,
> or an additional block, by providing documentation to ARIN which details
> the use of at least 50% of the requested block size within 24 months. An
> officer of the organization shall attest to the documentation provided to
> ARIN.
> >>
> >> 8.5.6. Efficient utilization of previous blocks
> >>
> >> Organizations with direct assignments or allocations from ARIN must
> have efficiently utilized at least 50% of every block in order to receive
> additional space. This includes all space reassigned to their customers.
> >>
> >> Comments:
> >>
> >> Timetable for implementation: immediately
> >>
> >> Anything else: A redline has been provided to help the community
> understand the changes that have been made to the NRPM.
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to the ARIN
> >> Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160622/2270e2c5/attachment.htm>

From jrl at lodden.com  Wed Jun 22 11:33:16 2016
From: jrl at lodden.com (jrl at lodden.com)
Date: Wed, 22 Jun 2016 18:33:16 +0300
Subject: [arin-ppml] announcement
Message-ID: <00008ae6f84d$1b840b94$e672f61f$@lodden.com>

Hi,

I've got an announcement for you, you may be interested, you can find more information here <http://ntyspijoxa.theberkleecafe.com/lntpij>

Hope this helps, jrl at lodden.com

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

From owen at delong.com  Wed Jun 22 13:30:44 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 22 Jun 2016 10:30:44 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
Message-ID: <372DC1BE-372D-45A8-BBA6-9937D978D8EF@delong.com>


> On Jun 22, 2016, at 08:46 , Andrew Dul <andrew.dul at quark.net> wrote:
> 
> As the primary author of this draft policy, I respectfully disagree with
> my AC colleague. 
> 
> Now that the free pool has been depleted, it is time to look toward what
> future IPv4 (primarily transfer) policy should do.  While this policy
> looks complicated, its intention is to create a very simple transfer
> policy which allows businesses to predictably and efficiently transfer
> IPv4 resources to meet their requirements.

I don?t disagree with your intent, but I disagree that what you have
proposed achieves that intent.

You are eliminating key safeguards from the transfer policy while simultaneously
changing several of the criteria that have previously applied to transfers of
IPv4 space under section 4.

In addition, there may be unintended effects on the transfer of ASNs.

> I share with you here a redline which shows the changes that would be
> made to section 8.

The redline doesn?t begin to cover it because it does nothing to evaluate how
removing the existing interactions with section 4 compares to existing policy
implementation.

As a result, the redline ends up looking deceptively minor.

Owen

> 
> Andrew
> 
> On 6/21/2016 9:16 AM, Owen DeLong wrote:
>> I am opposed to this policy proposal.
>> 
>> Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.
>> 
>> The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.
>> 
>> If we want to change IPv4 policy, then let?s change IPv4 policy in section 4.
>> 
>> If we want to change transfer policy for all resources, we can do that cleanly in section 8.
>> 
>> While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.
>> 
>> Owen
>> 
>>> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net> wrote:
>>> 
>>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
>>> 
>>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>> 
>>> This Draft Policy has been numbered and titled:
>>> 
>>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>> 
>>> Draft Policy ARIN-2016-5 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2016_5.html
>>> 
>>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
>>> 
>>> 	> Enabling Fair and Impartial Number Resource Administration
>>> 	> Technically Sound
>>> 	> Supported by the Community
>>> 
>>> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>> 
>>> Date: 21 June 2016
>>> 
>>> Problem Statement
>>> 
>>> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
>>> 
>>> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
>>> 
>>> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.
>>> 
>>> The goals of this rewrite are as follows:
>>> 
>>>> Separate the criteria that is found in section 4 of the NRPM from the transfer process.
>>>> Provide a clear set of criteria that should be applied across all IPv4 transfers.
>>>> Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
>>>> Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.
>>> Policy statement:
>>> 
>>> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>>> 
>>> ######
>>> 
>>> 8.2. Mergers, Acquisitions, and Reorganizations
>>> 
>>> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:
>>> 
>>>> The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
>>>> The new entity must sign an RSA covering all resources to be transferred.
>>>> The resources to be transferred will be subject to ARIN policies.
>>>> The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
>>>> For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.
>>> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.
>>> 
>>> 8.3. Transfers between Specified Recipients within the ARIN Region
>>> 
>>> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.
>>> 
>>> Conditions on source of the transfer:
>>> 
>>>> The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
>>>> The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>>> Conditions on recipient of the transfer:
>>> 
>>>> The recipients must meet the transfer requirements as defined in section 8.5.
>>>> The resources transferred will be subject to current ARIN policies.
>>> 8.4. Inter-RIR Transfers to Specified Recipients
>>> 
>>> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
>>> 
>>> Conditions on source of the transfer:
>>> 
>>>> The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
>>>> Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
>>>> Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>>> Conditions on recipient of the transfer:
>>> 
>>>> The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
>>>> Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
>>>> Recipients within the ARIN region will be subject to current ARIN policies.
>>> 8.5. Specified Transfer Recipient Requirements
>>> 
>>> 8.5.1. Registration Services Agreement
>>> 
>>> Transfer recipients must sign an RSA for the resources being received.
>>> 
>>> 8.5.2. Operational Use
>>> 
>>> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
>>> 
>>> 8.5.3. Minimum transfer size
>>> 
>>> ARIN's minimum transfer size is a /24.
>>> 
>>> 8.5.4. Initial block
>>> 
>>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.
>>> 
>>> 8.5.5. Block size
>>> 
>>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>>> 
>>> 8.5.6. Efficient utilization of previous blocks
>>> 
>>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.
>>> 
>>> Comments:
>>> 
>>> Timetable for implementation: immediately
>>> 
>>> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage 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.
> 
> 
> <Post-IPv4 Free-Pool Depletion Transfer Policy (NRPM 8 redline) - 20160609.pdf>_______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 mike at iptrading.com  Wed Jun 22 14:00:20 2016
From: mike at iptrading.com (Mike Burns)
Date: Wed, 22 Jun 2016 14:00:20 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <CAGkMwz4hn6AvrvMFGcqkch96kMhOmWLup7pUk+tm-Fi9LTtf3w@mail.gmail.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<001d01d1cca2$84c498e0$8e4dcaa0$@iptrading.com>
	<CAGkMwz4hn6AvrvMFGcqkch96kMhOmWLup7pUk+tm-Fi9LTtf3w@mail.gmail.com>
Message-ID: <004801d1ccaf$f15be690$d413b3b0$@iptrading.com>

Hi Scott and Andrew,

 

To me, 8.5.2 seems a little redundant considering 1.2:

 

8.5.2. Operational Use

ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.

 

1.2. Conservation

 

The principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources.

 

Due to the requirement for uniqueness, Internet number resources of each type are drawn from a common number space. Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks.

 

8.5.2 goes even farther than the language in 1.2. Specifically the word ?solely? rather than ?in support.? What if I don?t need them now but I will within 24 months, is that solely for the purpose of use, or is that for planning purposes?

 

I still don?t see the purpose of this section unless it?s window dressing to slide the no-needs minimum through.

 

I think it would be improved by eliminating 8.5.2 and renumbering the rest.

 

So maybe the language is a little cluttered for my taste, what with ?specified? this and that and , but I am inclined to support it as a step forward in simplifying and incentivizing accurate registration of transfers.

 

True section 8 is growing but maybe someday we can prune section 4 as we simplify IPv4 address distribution.

Pace Owen, we should let section 4 wither away rather than cling to it. Section 4 was for the free pool, it?s silly to retain that language and paradigm in today?s market environment.  The evidence is in, and the needs test (especially filtered through section 4 language) is not necessary to comply with NRPM 1.2. Conservation is provided by price and IPv6 provides all the protection from ?speculators? we need. Or maybe somehow RIPE is immune from insidious speculation despite the lack of a needs test?

 

Regards,

Mike

 

 

From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
Sent: Wednesday, June 22, 2016 12:31 PM
To: Mike Burns <mike at iptrading.com>
Cc: Andrew Dul <andrew.dul at quark.net>; ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

 

On Wed, Jun 22, 2016 at 11:24 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

Hi Scott,

 

I apologize, I did not scroll down and see  your other comments.

My fault for top-posting.

 

If recipients have to attest that they are using the addresses on an operational network, why do we need 8.5.2? The attestation would as you say prevent financial speculators from acquiring them for speculative purposes.

 

Is the attestation required for first time initial transfers of the minimum?

It doesn?t seem to read that way.

 

8.5.2 is the policy text that supports requiring the recipient to attest that they are using the addresses on an operational network.  If that part is unclear, we would welcome suggestions for improving the text.  There is a further attestation in 8.5.5 as well for organizations requesting more than the minimum.

 

-Scott

 

 

 

From: Scott Leibrand [mailto:scottleibrand at gmail.com <mailto:scottleibrand at gmail.com> ] 
Sent: Wednesday, June 22, 2016 12:16 PM
To: Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> >
Cc: Andrew Dul <andrew.dul at quark.net <mailto:andrew.dul at quark.net> >; ARIN-PPML List <arin-ppml at arin.net <mailto:arin-ppml at arin.net> >


Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

 

On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

Hi Andrew,

I have a couple of questions about the policy proposal.

 On Section 8.5.2 Operational Use.

First, why is this section even in there, does it serve some particular purpose?

 

It prevents financial speculators, who have no operational use for the addresses, from acquiring them for speculative purposes.

 


Second, why does it refer to assignments and allocations in a section devoted to transfers?

Overall, do we still need the verbiage about "Specified" recipients, why not just recipients?

 

ARIN allocates or assigns blocks of IP addresses to organizations via transfer.  An organization cannot receive a transfer directly: ARIN must update the registration of the allocation or assignment to reflect the specified recipient as the new holder.  This simply reflects existing policy language and operational practice: nothing is changing here.

 


And lastly for now, does this mean that new buyers will automatically qualify for the minimum without any needs test?

 

There is still a needs test, but it is now much simpler: recipients without any previous allocations or assignments (directly or via transfer) simply have to attest to the fact that the addresses are needed for use on an operational network.  That is effectively the same as "without any needs test" for entities operating a network that will actually use the addresses, while completely locking out speculators who are unwilling to engage in fraud and risk losing the addresses they acquired.

 

-Scott

 



My initial impression is positive.

Regards,
Mike








-----Original Message-----
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 Andrew Dul
Sent: Wednesday, June 22, 2016 11:46 AM
To: arin-ppml at arin.net <mailto:arin-ppml at arin.net> 
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

As the primary author of this draft policy, I respectfully disagree with my AC colleague.

Now that the free pool has been depleted, it is time to look toward what future IPv4 (primarily transfer) policy should do.  While this policy looks complicated, its intention is to create a very simple transfer policy which allows businesses to predictably and efficiently transfer
IPv4 resources to meet their requirements.

I share with you here a redline which shows the changes that would be made to section 8.

Andrew

On 6/21/2016 9:16 AM, Owen DeLong wrote:
> I am opposed to this policy proposal.
>
> Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.
>
> The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.
>
> If we want to change IPv4 policy, then let?s change IPv4 policy in section 4.
>
> If we want to change transfer policy for all resources, we can do that cleanly in section 8.
>
> While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.
>
> Owen
>
>> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net <mailto:info at arin.net> > wrote:
>>
>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
>>
>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>
>> This Draft Policy has been numbered and titled:
>>
>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
>> Policy
>>
>> Draft Policy ARIN-2016-5 is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_5.html
>>
>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
>>
>>      > Enabling Fair and Impartial Number Resource Administration
>>      > Technically Sound
>>      > Supported by the Community
>>
>> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
>> Policy
>>
>> Date: 21 June 2016
>>
>> Problem Statement
>>
>> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
>>
>> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
>>
>> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.
>>
>> The goals of this rewrite are as follows:
>>
>>> Separate the criteria that is found in section 4 of the NRPM from the transfer process.
>>> Provide a clear set of criteria that should be applied across all IPv4 transfers.
>>> Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
>>> Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.
>> Policy statement:
>>
>> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>>
>> ######
>>
>> 8.2. Mergers, Acquisitions, and Reorganizations
>>
>> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:
>>
>>> The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
>>> The new entity must sign an RSA covering all resources to be transferred.
>>> The resources to be transferred will be subject to ARIN policies.
>>> The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
>>> For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.
>> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.
>>
>> 8.3. Transfers between Specified Recipients within the ARIN Region
>>
>> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
>>> The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The recipients must meet the transfer requirements as defined in section 8.5.
>>> The resources transferred will be subject to current ARIN policies.
>> 8.4. Inter-RIR Transfers to Specified Recipients
>>
>> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
>>
>> Conditions on source of the transfer:
>>
>>> The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
>>> Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
>>> Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>> Conditions on recipient of the transfer:
>>
>>> The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
>>> Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
>>> Recipients within the ARIN region will be subject to current ARIN policies.
>> 8.5. Specified Transfer Recipient Requirements
>>
>> 8.5.1. Registration Services Agreement
>>
>> Transfer recipients must sign an RSA for the resources being received.
>>
>> 8.5.2. Operational Use
>>
>> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
>>
>> 8.5.3. Minimum transfer size
>>
>> ARIN's minimum transfer size is a /24.
>>
>> 8.5.4. Initial block
>>
>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.
>>
>> 8.5.5. Block size
>>
>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>>
>> 8.5.6. Efficient utilization of previous blocks
>>
>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.
>>
>> Comments:
>>
>> Timetable for implementation: immediately
>>
>> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net> ).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net <mailto:info at arin.net>  if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net> ).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <mailto:info at arin.net>  if you experience any issues.



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

 

 

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

From rbf+arin-ppml at panix.com  Wed Jun 22 14:26:37 2016
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Wed, 22 Jun 2016 13:26:37 -0500
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
Message-ID: <20160622182636.GA15225@panix.com>

On Wed, Jun 22, 2016 at 11:15:58AM -0500, Scott Leibrand wrote:
> On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <mike at iptrading.com> wrote:
> 
> > Hi Andrew,
> >
> > I have a couple of questions about the policy proposal.
> >
> >  On Section 8.5.2 Operational Use.
> >
> > First, why is this section even in there, does it serve some particular
> > purpose?
> >
> 
> It prevents financial speculators, who have no operational use for the
> addresses, from acquiring them for speculative purposes.

If that's the intent, I think it would better to make "operational
network" part of the actual requirements, rather than have a general
"ARIN transfers for the purposes of use on an operational network"
platitude, and then interpret that as a condition of transfer rather
than a general statement of a goal we consider worthy.

For example, for an entity wanting to get a /24 under 8.5.4, ARIN would
first validate that the organization had no existing direct assignments
or allocations, but then what?  How would they implement 8.5.2?  Ask
"do you plan to use this on an operational network"?  Request officer
attestation as to plans to use the /24 on an operational network?  Do
nothing and approve the transfer on the theory that the requester is on
his honor to abide by 8.5.2 even without being asked about it?  Approve
the transfer unless ARIN had some specific reason to believe that the
proposed transfer was for the purposes of financial speculation? 
Something else?

As for 8.5.5, would 8.5.2 be of any effect given that documentation is
already required.  (Is 8.5.2 the thing that would allow ARIN to reject
documention along the lines of "we will, within 24 months, make use of
the transferred space for the purposes of financial speculation"?  That
seems like overkill; before run-out, ARIN didn't need something like
8.5.2 to reject requests for free-pool assignments that came in with a
justification of "financial speculation" -- I don't know that they
ever received such, but I'm sure they would have rejected it had they
received such.)

If we want ARIN to impose an operational network requirement, we should
be clear what that means. 

All that said, I support the goals of this proposal.  I agree that
8.5.2 is non- or poorly- operative (but keeping it would not cause me
to drop my support for the proposal), and have no opinion on Owen's
proposal to do it in section 4 rather than 8, but I support the
elimination of justification for the first /24, and the proposed 8.5.5
requirements for subsequent or larger tansfers.  I note that it's
possible that there will be small free-pool assignments made going
forward, so doing this in section 4, as opposed to section 8, is not a
purely editorial change.

(Proposed sections referenced above are quoted below for reference.)

    8.5.2. Operational Use

    ARIN allocates or assigns blocks of IP addresses to organizations via
    transfer solely for the purpose of use on an operational network.
      
    8.5.4. Initial block
        
    Organizations without direct assignments or allocations from ARIN
    qualify for transfer of an initial block of ARIN's minimum transfer size.

    8.5.5. Block size

    Organizations may qualify for the transfer of a larger initial block,
    or an additional block, by providing documentation to ARIN which details
    the use of at least 50% of the requested block size within 24 months. An
    officer of the organization shall attest to the documentation provided to
    ARIN.

     --  Brett


From owen at delong.com  Wed Jun 22 19:02:20 2016
From: owen at delong.com (Owen DeLong)
Date: Wed, 22 Jun 2016 16:02:20 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <004801d1ccaf$f15be690$d413b3b0$@iptrading.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<001d01d1cca2$84c498e0$8e4dcaa0$@iptrading.com>
	<CAGkMwz4hn6AvrvMFGcqkch96kMhOmWLup7pUk+tm-Fi9LTtf3w@mail.gmail.com>
	<004801d1ccaf$f15be690$d413b3b0$@iptrading.com>
Message-ID: <63F2EAD1-5912-4399-BC93-DC9A97063652@delong.com>


> On Jun 22, 2016, at 11:00 , Mike Burns <mike at iptrading.com> wrote:
> 
> Hi Scott and Andrew,
>  
> To me, 8.5.2 seems a little redundant considering 1.2:
>  
> 8.5.2. Operational Use
> 
> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
>  
> 1.2. Conservation
>  
> The principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources.
>  
> Due to the requirement for uniqueness, Internet number resources of each type are drawn from a common number space. Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks.
>  
> 8.5.2 goes even farther than the language in 1.2. Specifically the word ?solely? rather than ?in support.? What if I don?t need them now but I will within 24 months, is that solely for the purpose of use, or is that for planning purposes?
>  
> I still don?t see the purpose of this section unless it?s window dressing to slide the no-needs minimum through.
>  
> I think it would be improved by eliminating 8.5.2 and renumbering the rest.
>  
> So maybe the language is a little cluttered for my taste, what with ?specified? this and that and , but I am inclined to support it as a step forward in simplifying and incentivizing accurate registration of transfers.
>  
> True section 8 is growing but maybe someday we can prune section 4 as we simplify IPv4 address distribution.
> Pace Owen, we should let section 4 wither away rather than cling to it. Section 4 was for the free pool, it?s silly to retain that language and paradigm in today?s market environment.  The evidence is in, and the needs test (especially filtered through section 4 language) is not necessary to comply with NRPM 1.2. Conservation is provided by price and IPv6 provides all the protection from ?speculators? we need. Or maybe somehow RIPE is immune from insidious speculation despite the lack of a needs test?

Technically, RIPE has a needs test. I?ll grant you it?s not much of one, but it probably is enough to limit speculation.

Owen

>  
> Regards,
> Mike
>  
>  
> From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
> Sent: Wednesday, June 22, 2016 12:31 PM
> To: Mike Burns <mike at iptrading.com>
> Cc: Andrew Dul <andrew.dul at quark.net>; ARIN-PPML List <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>  
> On Wed, Jun 22, 2016 at 11:24 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>> wrote:
>> Hi Scott,
>>  
>> I apologize, I did not scroll down and see  your other comments.
>> My fault for top-posting.
>>  
>> If recipients have to attest that they are using the addresses on an operational network, why do we need 8.5.2? The attestation would as you say prevent financial speculators from acquiring them for speculative purposes.
>>  
>> Is the attestation required for first time initial transfers of the minimum?
>> It doesn?t seem to read that way.
>  
> 8.5.2 is the policy text that supports requiring the recipient to attest that they are using the addresses on an operational network.  If that part is unclear, we would welcome suggestions for improving the text.  There is a further attestation in 8.5.5 as well for organizations requesting more than the minimum.
>  
> -Scott
>  
>>  
>>  
>> From: Scott Leibrand [mailto:scottleibrand at gmail.com <mailto:scottleibrand at gmail.com>] 
>> Sent: Wednesday, June 22, 2016 12:16 PM
>> To: Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>>
>> Cc: Andrew Dul <andrew.dul at quark.net <mailto:andrew.dul at quark.net>>; ARIN-PPML List <arin-ppml at arin.net <mailto:arin-ppml at arin.net>>
>> 
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>  
>> On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com>> wrote:
>>> Hi Andrew,
>>> 
>>> I have a couple of questions about the policy proposal.
>>> 
>>>  On Section 8.5.2 Operational Use.
>>> 
>>> First, why is this section even in there, does it serve some particular purpose?
>>  
>> It prevents financial speculators, who have no operational use for the addresses, from acquiring them for speculative purposes.
>>  
>>> 
>>> Second, why does it refer to assignments and allocations in a section devoted to transfers?
>>> 
>>> Overall, do we still need the verbiage about "Specified" recipients, why not just recipients?
>>  
>> ARIN allocates or assigns blocks of IP addresses to organizations via transfer.  An organization cannot receive a transfer directly: ARIN must update the registration of the allocation or assignment to reflect the specified recipient as the new holder.  This simply reflects existing policy language and operational practice: nothing is changing here.
>>  
>>> 
>>> And lastly for now, does this mean that new buyers will automatically qualify for the minimum without any needs test?
>>  
>> There is still a needs test, but it is now much simpler: recipients without any previous allocations or assignments (directly or via transfer) simply have to attest to the fact that the addresses are needed for use on an operational network.  That is effectively the same as "without any needs test" for entities operating a network that will actually use the addresses, while completely locking out speculators who are unwilling to engage in fraud and risk losing the addresses they acquired.
>>  
>> -Scott
>>  
>>> 
>>> 
>>> My initial impression is positive.
>>> 
>>> Regards,
>>> Mike
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> 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 Andrew Dul
>>> Sent: Wednesday, June 22, 2016 11:46 AM
>>> To: arin-ppml at arin.net <mailto:arin-ppml at arin.net>
>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>> 
>>> As the primary author of this draft policy, I respectfully disagree with my AC colleague.
>>> 
>>> Now that the free pool has been depleted, it is time to look toward what future IPv4 (primarily transfer) policy should do.  While this policy looks complicated, its intention is to create a very simple transfer policy which allows businesses to predictably and efficiently transfer
>>> IPv4 resources to meet their requirements.
>>> 
>>> I share with you here a redline which shows the changes that would be made to section 8.
>>> 
>>> Andrew
>>> 
>>> On 6/21/2016 9:16 AM, Owen DeLong wrote:
>>> > I am opposed to this policy proposal.
>>> >
>>> > Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.
>>> >
>>> > The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.
>>> >
>>> > If we want to change IPv4 policy, then let?s change IPv4 policy in section 4.
>>> >
>>> > If we want to change transfer policy for all resources, we can do that cleanly in section 8.
>>> >
>>> > While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.
>>> >
>>> > Owen
>>> >
>>> >> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net <mailto:info at arin.net>> wrote:
>>> >>
>>> >> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
>>> >>
>>> >> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>> >>
>>> >> This Draft Policy has been numbered and titled:
>>> >>
>>> >> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
>>> >> Policy
>>> >>
>>> >> Draft Policy ARIN-2016-5 is below and can be found at:
>>> >> https://www.arin.net/policy/proposals/2016_5.html <https://www.arin.net/policy/proposals/2016_5.html>
>>> >>
>>> >> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
>>> >>
>>> >>      > Enabling Fair and Impartial Number Resource Administration
>>> >>      > Technically Sound
>>> >>      > Supported by the Community
>>> >>
>>> >> The PDP can be found at:
>>> >> https://www.arin.net/policy/pdp.html <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 <https://www.arin.net/policy/proposals/index.html>
>>> >>
>>> >> Regards,
>>> >>
>>> >> Communications and Member Services
>>> >> American Registry for Internet Numbers (ARIN)
>>> >>
>>> >> ##########
>>> >>
>>> >> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer
>>> >> Policy
>>> >>
>>> >> Date: 21 June 2016
>>> >>
>>> >> Problem Statement
>>> >>
>>> >> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
>>> >>
>>> >> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
>>> >>
>>> >> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.
>>> >>
>>> >> The goals of this rewrite are as follows:
>>> >>
>>> >>> Separate the criteria that is found in section 4 of the NRPM from the transfer process.
>>> >>> Provide a clear set of criteria that should be applied across all IPv4 transfers.
>>> >>> Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
>>> >>> Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.
>>> >> Policy statement:
>>> >>
>>> >> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>>> >>
>>> >> ######
>>> >>
>>> >> 8.2. Mergers, Acquisitions, and Reorganizations
>>> >>
>>> >> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:
>>> >>
>>> >>> The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
>>> >>> The new entity must sign an RSA covering all resources to be transferred.
>>> >>> The resources to be transferred will be subject to ARIN policies.
>>> >>> The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
>>> >>> For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.
>>> >> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.
>>> >>
>>> >> 8.3. Transfers between Specified Recipients within the ARIN Region
>>> >>
>>> >> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.
>>> >>
>>> >> Conditions on source of the transfer:
>>> >>
>>> >>> The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
>>> >>> The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>>> >> Conditions on recipient of the transfer:
>>> >>
>>> >>> The recipients must meet the transfer requirements as defined in section 8.5.
>>> >>> The resources transferred will be subject to current ARIN policies.
>>> >> 8.4. Inter-RIR Transfers to Specified Recipients
>>> >>
>>> >> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
>>> >>
>>> >> Conditions on source of the transfer:
>>> >>
>>> >>> The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
>>> >>> Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
>>> >>> Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>>> >> Conditions on recipient of the transfer:
>>> >>
>>> >>> The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
>>> >>> Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
>>> >>> Recipients within the ARIN region will be subject to current ARIN policies.
>>> >> 8.5. Specified Transfer Recipient Requirements
>>> >>
>>> >> 8.5.1. Registration Services Agreement
>>> >>
>>> >> Transfer recipients must sign an RSA for the resources being received.
>>> >>
>>> >> 8.5.2. Operational Use
>>> >>
>>> >> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
>>> >>
>>> >> 8.5.3. Minimum transfer size
>>> >>
>>> >> ARIN's minimum transfer size is a /24.
>>> >>
>>> >> 8.5.4. Initial block
>>> >>
>>> >> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.
>>> >>
>>> >> 8.5.5. Block size
>>> >>
>>> >> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>>> >>
>>> >> 8.5.6. Efficient utilization of previous blocks
>>> >>
>>> >> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.
>>> >>
>>> >> Comments:
>>> >>
>>> >> Timetable for implementation: immediately
>>> >>
>>> >> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.
>>> >> _______________________________________________
>>> >> 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 <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 <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/20160622/f5d7aa1a/attachment.htm>

From andrew.dul at quark.net  Wed Jun 22 21:47:03 2016
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 22 Jun 2016 18:47:03 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <20160622182636.GA15225@panix.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
Message-ID: <96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>

Hi Brett,

On 6/22/2016 11:26 AM, Brett Frankenberger wrote:
> On Wed, Jun 22, 2016 at 11:15:58AM -0500, Scott Leibrand wrote:
>> On Wed, Jun 22, 2016 at 11:00 AM, Mike Burns <mike at iptrading.com> wrote:
>>
>>> Hi Andrew,
>>>
>>> I have a couple of questions about the policy proposal.
>>>
>>>  On Section 8.5.2 Operational Use.
>>>
>>> First, why is this section even in there, does it serve some particular
>>> purpose?
>>>
>> It prevents financial speculators, who have no operational use for the
>> addresses, from acquiring them for speculative purposes.
> If that's the intent, I think it would better to make "operational
> network" part of the actual requirements, rather than have a general
> "ARIN transfers for the purposes of use on an operational network"
> platitude, and then interpret that as a condition of transfer rather
> than a general statement of a goal we consider worthy.
>
> For example, for an entity wanting to get a /24 under 8.5.4, ARIN would
> first validate that the organization had no existing direct assignments
> or allocations, but then what?  How would they implement 8.5.2?  Ask
> "do you plan to use this on an operational network"?  Request officer
> attestation as to plans to use the /24 on an operational network?  Do
> nothing and approve the transfer on the theory that the requester is on
> his honor to abide by 8.5.2 even without being asked about it?  Approve
> the transfer unless ARIN had some specific reason to believe that the
> proposed transfer was for the purposes of financial speculation? 
> Something else?

The point of 8.5.2 is to clarify that the community believes that IPv4
addresses are to be used on operational networks, not as resources to be
held for some other purpose (e.g. financial speculation).  We ask that
an officer of the organization to attest to ensure that the organization
understands the nature of the transaction and doesn't commit its $ in
support of other goals.  I believe having it in section 8 helps
organizations clearly understand the requirements for transfer.  (e.g.
They don't have to hunt around in other sections for other
requirements.) I, personally, believe that the base requirement for any
transfer is that the organization intend to use it on an operational
network. 


>
> As for 8.5.5, would 8.5.2 be of any effect given that documentation is
> already required. 

8.8.5 is used when 8.5.4 is not used.  So if you are a new org w/o any
address space from ARIN, you have to meet requirements 8.5.1-4.  8.5.5 &
8.5.6 are used for organizations which do not have address space from
ARIN or who want more than the minimum.

>  (Is 8.5.2 the thing that would allow ARIN to reject
> documention along the lines of "we will, within 24 months, make use of
> the transferred space for the purposes of financial speculation"?  That
> seems like overkill; before run-out, ARIN didn't need something like
> 8.5.2 to reject requests for free-pool assignments that came in with a
> justification of "financial speculation" -- I don't know that they
> ever received such, but I'm sure they would have rejected it had they
> received such.)

ARIN would have rejected a free-pool request prior to run-out for a
financial speculator because they didn't show evidence (via needs-test)
how they would be using the addresses on a network.  If we don't have
any requirement that IP number resources are to be used on an
operational network, then an organization can come to ARIN and have
resources transferred into their organization.  ARIN follows the
policies we set, so if our policies are silent about the types of
organizations who are eligible for resources, then ARIN must assume that
all organizations are eligible to receive transferred resources.

We are certainly open to other language if you would like to suggest
something, to clarify our intent.

Andrew


> If we want ARIN to impose an operational network requirement, we should
> be clear what that means. 
>
> All that said, I support the goals of this proposal.  I agree that
> 8.5.2 is non- or poorly- operative (but keeping it would not cause me
> to drop my support for the proposal), and have no opinion on Owen's
> proposal to do it in section 4 rather than 8, but I support the
> elimination of justification for the first /24, and the proposed 8.5.5
> requirements for subsequent or larger tansfers.  I note that it's
> possible that there will be small free-pool assignments made going
> forward, so doing this in section 4, as opposed to section 8, is not a
> purely editorial change.
>
> (Proposed sections referenced above are quoted below for reference.)
>
>     8.5.2. Operational Use
>
>     ARIN allocates or assigns blocks of IP addresses to organizations via
>     transfer solely for the purpose of use on an operational network.
>       
>     8.5.4. Initial block
>         
>     Organizations without direct assignments or allocations from ARIN
>     qualify for transfer of an initial block of ARIN's minimum transfer size.
>
>     8.5.5. Block size
>
>     Organizations may qualify for the transfer of a larger initial block,
>     or an additional block, by providing documentation to ARIN which details
>     the use of at least 50% of the requested block size within 24 months. An
>     officer of the organization shall attest to the documentation provided to
>     ARIN.
>
>      --  Brett
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 rbf+arin-ppml at panix.com  Wed Jun 22 22:54:10 2016
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Wed, 22 Jun 2016 21:54:10 -0500
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
Message-ID: <20160623025410.GA3707@panix.com>

On Wed, Jun 22, 2016 at 06:47:03PM -0700, Andrew Dul wrote:
> Hi Brett,
> 
> On 6/22/2016 11:26 AM, Brett Frankenberger wrote:
> >
> > For example, for an entity wanting to get a /24 under 8.5.4, ARIN would
> > first validate that the organization had no existing direct assignments
> > or allocations, but then what?  How would they implement 8.5.2?  Ask
> > "do you plan to use this on an operational network"?  Request officer
> > attestation as to plans to use the /24 on an operational network?  Do
> > nothing and approve the transfer on the theory that the requester is on
> > his honor to abide by 8.5.2 even without being asked about it?  Approve
> > the transfer unless ARIN had some specific reason to believe that the
> > proposed transfer was for the purposes of financial speculation? 
> > Something else?
> 
> The point of 8.5.2 is to clarify that the community believes that IPv4
> addresses are to be used on operational networks, not as resources to be
> held for some other purpose (e.g. financial speculation).  We ask that
> an officer of the organization to attest to ensure that the organization
> understands the nature of the transaction and doesn't commit its $ in
> support of other goals.  

8.5.4 as proposed does not include any officer attestation language. 
Is it your understanding that the implementation of 8.5.4 and 8.5.2
would result, in the case of an 8.5.4 transfer, in ARIN requiring an
officer attestation to the effect that the /24 will be used on an
operational network?  If we want an officer to attest to the usage in
that case, shouldn't that be written into the policy (as was done for
8.5.5)?

> >  (Is 8.5.2 the thing that would allow ARIN to reject
> > documention along the lines of "we will, within 24 months, make use of
> > the transferred space for the purposes of financial speculation"?  That
> > seems like overkill; before run-out, ARIN didn't need something like
> > 8.5.2 to reject requests for free-pool assignments that came in with a
> > justification of "financial speculation" -- I don't know that they
> > ever received such, but I'm sure they would have rejected it had they
> > received such.)
> 
> ARIN would have rejected a free-pool request prior to run-out for a
> financial speculator because they didn't show evidence (via needs-test)
> how they would be using the addresses on a network.  If we don't have
> any requirement that IP number resources are to be used on an
> operational network, then an organization can come to ARIN and have
> resources transferred into their organization.  ARIN follows the
> policies we set, so if our policies are silent about the types of
> organizations who are eligible for resources, then ARIN must assume that
> all organizations are eligible to receive transferred resources.

So by this policy, we are:

(a) Stating that transfers -- even 8.5.4 transfers of a /24 to an
organization that currently has no direct assignments or allocations --
are only for organizations that intend to use them on an operational
network.

(b) Leaving it to ARIN staff to determine how to verify that in the
case of 8.5.4?

As a matter of policy, I'm OK with that.  But 8.5.2 seems a misleading
way to get there.

> We are certainly open to other language if you would like to suggest
> something, to clarify our intent.

     8.5.4. Initial block
         
     Organizations without direct assignments or allocations from ARIN
     qualify for transfer of an initial block of ARIN's minimum transfer size.

That language suggests that if I am an organization with no direct
assignment or allocation, I qualify for a transfer of a /24.  What you
appear to be saying is that the actual policy (due to the contribution
of 8.5.2) is that I qualify for a /24 if I am an organization with no
direct assignmetns or allocations, *and* I intend to use them on an
operational network.

If the latter is the intended policy, I would write it that way:

   8.5.4:  Organizations without direct assignments or allocations from
           ARIN qualify for a transfer of an initial block of ARIN's
           minimum transfer size, provided the organization intends to
           use the transferred block on an operational network.

8.5.2 could then be removed (or, if it was left, it would at least not
appear inconsistent with 8.5.4.)

(By way of analogy, if our intent is that 8.5.2 would effectively
impose an additional constraint on an 8.5.4 transfer, then we have an
NRPM that is conceptually like:
   SECTION A:  All children are entitled to a lollipop.
   SECTION B:  Actually, only children that plan to consume the lollipop
               are entitled to a lollopop.
That strikes me as poorly drafted.)

     -- Brett


From michael at linuxmagic.com  Thu Jun 23 19:58:21 2016
From: michael at linuxmagic.com (Michael Peddemors)
Date: Thu, 23 Jun 2016 16:58:21 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
Message-ID: <576C779D.5000409@linuxmagic.com>

On 16-06-22 06:47 PM, Andrew Dul wrote:
> The point of 8.5.2 is to clarify that the community believes that IPv4
> addresses are to be used on operational networks, not as resources to be
> held for some other purpose (e.g. financial speculation).  We ask that
> an officer of the organization to attest to ensure that the organization
> understands the nature of the transaction and doesn't commit its $ in
> support of other goals.  I believe having it in section 8 helps
> organizations clearly understand the requirements for transfer.  (e.g.
> They don't have to hunt around in other sections for other
> requirements.) I, personally, believe that the base requirement for any
> transfer is that the organization intend to use it on an operational
> network.

Only concern I have, is that it has no real teeth.. You can always 
'make' it operational, we have seen recent allotments simply rented out 
to spammers who want virgin IP space.. boom.. now it is used/operational

But it is a slippery slope... question is, does the community want to 
declare what 'operational' means? Do we get into the conversation of 
what IP(s) should be used for?

And no use putting a definition in, unless the community and ARIN and 
it's board are willing to commit to enforcement..

Opinion is that this doesn't really 'clarify' in any meaningful way..

I think 8.5.2 needs to be more black or white, and not really a vague 
'opinion' declaration..

Either it is definite, and has teeth, or no need to add it at all.

IMHO

Definition: Operational ???


-- 
"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 bononlines at gmail.com  Thu Jun 23 22:29:09 2016
From: bononlines at gmail.com (Bon Onlines)
Date: Fri, 24 Jun 2016 04:29:09 +0200
Subject: [arin-ppml] What happen to the IPs after they are unallocated from
	a company?
Message-ID: <CANV0cTk0VDWRxGnw0rrsfnVh6eyQ4hxBa5h2136A9Z_MhBEs=g@mail.gmail.com>

Hello guys,

newly I have read a thread in wht which explain how a company names
Fevvo Inc abused a lot of IPs and ARIN has revoked their IPs. all of
their Ips are now unallocated http://bgp.he.net/AS63294#_prefixes, so
just a question, will ARIN now allocate these IPs to other companies
on the waiting list? or how does it work?

Thanks


From narten at us.ibm.com  Fri Jun 24 00:53:03 2016
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 24 Jun 2016 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201606240453.u5O4r3kB026484@rotala.raleigh.ibm.com>

Total of 21 messages in the last 7 days.
 
script run at: Fri Jun 24 00:53:03 EDT 2016
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 19.05% |    4 | 26.45% |   152598 | mike at iptrading.com
 19.05% |    4 | 20.22% |   116657 | owen at delong.com
  9.52% |    2 | 24.62% |   142030 | andrew.dul at quark.net
 19.05% |    4 |  7.02% |    40513 | info at arin.net
  9.52% |    2 | 13.83% |    79752 | scottleibrand at gmail.com
  9.52% |    2 |  3.57% |    20603 | rbf+arin-ppml at panix.com
  4.76% |    1 |  1.52% |     8755 | michael at linuxmagic.com
  4.76% |    1 |  1.47% |     8487 | narten at us.ibm.com
  4.76% |    1 |  1.29% |     7467 | bononlines at gmail.com
--------+------+--------+----------+------------------------
100.00% |   21 |100.00% |   576862 | Total



From jcurran at arin.net  Fri Jun 24 06:44:11 2016
From: jcurran at arin.net (John Curran)
Date: Fri, 24 Jun 2016 10:44:11 +0000
Subject: [arin-ppml] What happen to the IPs after they are unallocated
 from	a company?
In-Reply-To: <CANV0cTk0VDWRxGnw0rrsfnVh6eyQ4hxBa5h2136A9Z_MhBEs=g@mail.gmail.com>
References: <CANV0cTk0VDWRxGnw0rrsfnVh6eyQ4hxBa5h2136A9Z_MhBEs=g@mail.gmail.com>
Message-ID: <8E266756-0CAF-4B35-B98D-D0B318AFB814@corp.arin.net>

On Jun 23, 2016, at 10:29 PM, Bon Onlines <bononlines at gmail.com> wrote:
> 
> Hello guys,
> 
> newly I have read a thread in wht which explain how a company names
> Fevvo Inc abused a lot of IPs and ARIN has revoked their IPs. all of
> their Ips are now unallocated http://bgp.he.net/AS63294#_prefixes, so
> just a question, will ARIN now allocate these IPs to other companies
> on the waiting list? or how does it work?

Yes, ARIN will hold the resources for a short time (to allow remedy in 
case of error, provide the community time to update filters, etc.) and 
then will issue these resources to parties on the waiting list. 

Thanks,
/John

John Curran
President and CEO
ARIN



From jcurran at arin.net  Fri Jun 24 06:58:03 2016
From: jcurran at arin.net (John Curran)
Date: Fri, 24 Jun 2016 10:58:03 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <576C779D.5000409@linuxmagic.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
	<576C779D.5000409@linuxmagic.com>
Message-ID: <4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>

On Jun 23, 2016, at 7:58 PM, Michael Peddemors <michael at linuxmagic.com> wrote:
> 
> On 16-06-22 06:47 PM, Andrew Dul wrote:
>> The point of 8.5.2 is to clarify that the community believes that IPv4
>> addresses are to be used on operational networks, not as resources to be
>> held for some other purpose (e.g. financial speculation).  We ask that
>> an officer of the organization to attest to ensure that the organization
>> understands the nature of the transaction and doesn't commit its $ in
>> support of other goals.  I believe having it in section 8 helps
>> organizations clearly understand the requirements for transfer.  (e.g.
>> They don't have to hunt around in other sections for other
>> requirements.) I, personally, believe that the base requirement for any
>> transfer is that the organization intend to use it on an operational
>> network.
> 
> Only concern I have, is that it has no real teeth.. You can always 'make' it operational, we have seen recent allotments simply rented out to spammers who want virgin IP space.. boom.. now it is used/operational

Michael - 
 
   That particular case wouldn?t qualify, as they would have to detail their usage of
   the IP address space on their own operational networks (if there is a different 
   intent of the policy, the language should be changed to make that quite clear.) 
 
   I do believe such a provision would have significant teeth with respect to inhibiting
   IP address blocks as a viable large scale investment opportunity.   While those 
   of questionable repute may want work around such provisions, it would be rather
   difficult to establish a formal vehicle (i.e. fund) for investment in IP resource blocks 
   based on a requirement for the necessary representations and the associated risk 
   of loss of the entire investment in cases of fraud.   Other than that circumstance, 
   I agree that it would be fairly straightforward for most operating companies to make
   reasonable representations based on anticipated needs without significant concern.

Thanks!
/John

John Curran
President and CEO
ARIN


From mike at iptrading.com  Fri Jun 24 09:59:41 2016
From: mike at iptrading.com (Mike Burns)
Date: Fri, 24 Jun 2016 09:59:41 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
	<576C779D.5000409@linuxmagic.com>
	<4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>
Message-ID: <00c501d1ce20$a7ded910$f79c8b30$@iptrading.com>



   I do believe such a provision would have significant teeth with respect to inhibiting
   IP address blocks as a viable large scale investment opportunity.   While those 
   of questionable repute may want work around such provisions, it would be rather
   difficult to establish a formal vehicle (i.e. fund) for investment in IP resource blocks 
   based on a requirement for the necessary representations and the associated risk 
   of loss of the entire investment in cases of fraud.   Other than that circumstance, 
   I agree that it would be fairly straightforward for most operating companies to make
   reasonable representations based on anticipated needs without significant concern.

Thanks!
/John


Now the boogeyman has morphed into a hypothetical formal investment fund for IPv4 addresses. Despite zero evidence of anybody buying addresses and then reselling them for profit, we are asked to include this non-operational chaff in the NRPM. Despite an atomized supply, despite anti-flip provisions, despite IPv6 in the offing.  I wonder again what is keeping this fictional investment fund from opening a RIPE LIR and buying all they want? 

For what it's worth, there are active buyers today seeking to acquire millions of addresses which they desperately need for their operational networks and planned growth. Guess what, despite having the largest warchests around, they can't find sellers capable of meeting their needs. Why do you think a fund would have any more luck? Where is your evidence that 8.5.2 would have significant teeth regarding its inhibiting effect on viable large scale investments in ipv4? Is this just your opinion?

John, people can have different views on whether IP blocks should be treated as other commodities, and thus hedged, invested in, or speculated on. There is no need to cast aspersions on those who have this view, and your language about "questionable repute" goes beyond policy advice and veers into policy partisanship.

Regards,
Mike






From scottleibrand at gmail.com  Fri Jun 24 10:08:58 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 24 Jun 2016 14:08:58 +0000 (UTC)
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <00c501d1ce20$a7ded910$f79c8b30$@iptrading.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
	<576C779D.5000409@linuxmagic.com>
	<4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>
	<00c501d1ce20$a7ded910$f79c8b30$@iptrading.com>
Message-ID: <EF501E8D91217774.6DAB6491-CC3E-41BA-8184-008BF264C60F@mail.outlook.com>

Mike,
I think you're misunderstanding the intent here. This very simple "operational use" clause, that doesn't interfere with *any* legitimate transfers, is all that should be needed to prevent financial speculation, and allow us to dramatically simplify the needs test, or even remove it entirely in some cases (like the /24 for new entrants). Unless you see some actual harm that the clause would do, please just consider it "insurance" against an unlikely event that some people are concerned about, so we can move on to actually simplifying the rest of the policy.?

-Scott




On Fri, Jun 24, 2016 at 8:59 AM -0500, "Mike Burns" <mike at iptrading.com> wrote:












   I do believe such a provision would have significant teeth with respect to inhibiting
   IP address blocks as a viable large scale investment opportunity.   While those 
   of questionable repute may want work around such provisions, it would be rather
   difficult to establish a formal vehicle (i.e. fund) for investment in IP resource blocks 
   based on a requirement for the necessary representations and the associated risk 
   of loss of the entire investment in cases of fraud.   Other than that circumstance, 
   I agree that it would be fairly straightforward for most operating companies to make
   reasonable representations based on anticipated needs without significant concern.

Thanks!
/John


Now the boogeyman has morphed into a hypothetical formal investment fund for IPv4 addresses. Despite zero evidence of anybody buying addresses and then reselling them for profit, we are asked to include this non-operational chaff in the NRPM. Despite an atomized supply, despite anti-flip provisions, despite IPv6 in the offing.  I wonder again what is keeping this fictional investment fund from opening a RIPE LIR and buying all they want? 

For what it's worth, there are active buyers today seeking to acquire millions of addresses which they desperately need for their operational networks and planned growth. Guess what, despite having the largest warchests around, they can't find sellers capable of meeting their needs. Why do you think a fund would have any more luck? Where is your evidence that 8.5.2 would have significant teeth regarding its inhibiting effect on viable large scale investments in ipv4? Is this just your opinion?

John, people can have different views on whether IP blocks should be treated as other commodities, and thus hedged, invested in, or speculated on. There is no need to cast aspersions on those who have this view, and your language about "questionable repute" goes beyond policy advice and veers into policy partisanship.

Regards,
Mike




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

From mike at iptrading.com  Fri Jun 24 10:17:19 2016
From: mike at iptrading.com (Mike Burns)
Date: Fri, 24 Jun 2016 10:17:19 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <EF501E8D91217774.6DAB6491-CC3E-41BA-8184-008BF264C60F@mail.outlook.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
	<576C779D.5000409@linuxmagic.com>
	<4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>
	<00c501d1ce20$a7ded910$f79c8b30$@iptrading.com>
	<EF501E8D91217774.6DAB6491-CC3E-41BA-8184-008BF264C60F@mail.outlook.com>
Message-ID: <00d001d1ce23$1e42b340$5ac819c0$@iptrading.com>

Hi Scott,

 

I see the harm in the inclusion of non-operational text which seems to put into the NRPM something like a specific community expression against financial speculation which I think is not necessary. This inclusion could end up being a Trojan horse for future policy which could hinge on the assumption that the ARIN community had made this overt expression.

 

As I said I support the intent of simplifying the transfer policy but I don?t think 8.5.2 is necessary in light of NRPM 1.2 Conservation:  Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks.

 

 

On the assumption that we don?t want wasted or non-op verbiage in the NRPM, why is this section required?

 

Regards,

Mike

 

 

 

 

 

 

From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
Sent: Friday, June 24, 2016 10:09 AM
To: Mike Burns <mike at iptrading.com>; Michael Peddemors <michael at linuxmagic.com>; John Curran <jcurran at arin.net>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

 

Mike,

 

I think you're misunderstanding the intent here. This very simple "operational use" clause, that doesn't interfere with *any* legitimate transfers, is all that should be needed to prevent financial speculation, and allow us to dramatically simplify the needs test, or even remove it entirely in some cases (like the /24 for new entrants). Unless you see some actual harm that the clause would do, please just consider it "insurance" against an unlikely event that some people are concerned about, so we can move on to actually simplifying the rest of the policy. 

-Scott

 





On Fri, Jun 24, 2016 at 8:59 AM -0500, "Mike Burns" <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

 
 
   I do believe such a provision would have significant teeth with respect to inhibiting
   IP address blocks as a viable large scale investment opportunity.   While those 
   of questionable repute may want work around such provisions, it would be rather
   difficult to establish a formal vehicle (i.e. fund) for investment in IP resource blocks 
   based on a requirement for the necessary representations and the associated risk 
   of loss of the entire investment in cases of fraud.   Other than that circumstance, 
   I agree that it would be fairly straightforward for most operating companies to make
   reasonable representations based on anticipated needs without significant concern.
 
Thanks!
/John
 
 
Now the boogeyman has morphed into a hypothetical formal investment fund for IPv4 addresses. Despite zero evidence of anybody buying addresses and then reselling them for profit, we are asked to include this non-operational chaff in the NRPM. Despite an atomized supply, despite anti-flip provisions, despite IPv6 in the offing.  I wonder again what is keeping this fictional investment fund from opening a RIPE LIR and buying all they want? 
 
For what it's worth, there are active buyers today seeking to acquire millions of addresses which they desperately need for their operational networks and planned growth. Guess what, despite having the largest warchests around, they can't find sellers capable of meeting their needs. Why do you think a fund would have any more luck? Where is your evidence that 8.5.2 would have significant teeth regarding its inhibiting effect on viable large scale investments in ipv4? Is this just your opinion?
 
John, people can have different views on whether IP blocks should be treated as other commodities, and thus hedged, invested in, or speculated on. There is no need to cast aspersions on those who have this view, and your language about "questionable repute" goes beyond policy advice and veers into policy partisanship.
 
Regards,
Mike
 
 
 
 
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net> ).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net <mailto:info at arin.net>  if you experience any issues.

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

From scottleibrand at gmail.com  Fri Jun 24 10:22:11 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 24 Jun 2016 14:22:11 +0000 (UTC)
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <00d001d1ce23$1e42b340$5ac819c0$@iptrading.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
	<576C779D.5000409@linuxmagic.com>
	<4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>
	<00c501d1ce20$a7ded910$f79c8b30$@iptrading.com>
	<EF501E8D91217774.6DAB6491-CC3E-41BA-8184-008BF264C60F@mail.outlook.com>
	<00d001d1ce23$1e42b340$5ac819c0$@iptrading.com>
Message-ID: <EF501E8D91217774.DC19A7BA-8880-4227-8634-AF0EF8997B26@mail.outlook.com>

I am assuming we'll need to tighten up this language to make it more operational: specifically requiring attestation of operational use, not just making a general statement about ARIN only issuing space to operational networks. Would that help address your concern? If so, let's revisit after Andrew and I and the AC shepherds figure out the exact revision we want there, unless you have any specific suggestions for language we should consider.?

-Scott

		_____________________________
From: Mike Burns <mike at iptrading.com>
Sent: Friday, June 24, 2016 9:17 AM
Subject: RE: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
To: Scott Leibrand <scottleibrand at gmail.com>, Michael Peddemors <michael at linuxmagic.com>, John Curran <jcurran at arin.net>
Cc:  <arin-ppml at arin.net>




Hi Scott,

?

I see the harm in the inclusion of non-operational text which seems to put into the NRPM something like a specific community expression against financial speculation which I think is not necessary. This inclusion could end up being a Trojan horse for future policy which could hinge on the assumption that the ARIN community had made this overt expression.

?

As I said I support the intent of simplifying the transfer policy but I don?t think 8.5.2 is necessary in light of NRPM 1.2 Conservation: ?Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks.

?

?

On the assumption that we don?t want wasted or non-op verbiage in the NRPM, why is this section required?

?

Regards,

Mike

?

?

?

?

?

?

From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
Sent: Friday, June 24, 2016 10:09 AM
To: Mike Burns <mike at iptrading.com>; Michael Peddemors <michael at linuxmagic.com>; John Curran <jcurran at arin.net>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

?

Mike,

?

I think you're misunderstanding the intent here. This very simple "operational use" clause, that doesn't interfere with *any* legitimate transfers, is all that should be needed to prevent financial speculation, and allow us to dramatically simplify the needs test, or even remove it entirely in some cases (like the /24 for new entrants). Unless you see some actual harm that the clause would do, please just consider it "insurance" against an unlikely event that some people are concerned about, so we can move on to actually simplifying the rest of the policy.?

-Scott

?





On Fri, Jun 24, 2016 at 8:59 AM -0500, "Mike Burns" <mike at iptrading.com> wrote:???? I do believe such a provision would have significant teeth with respect to inhibiting?? IP address blocks as a viable large scale investment opportunity.?? While those ???of questionable repute may want work around such provisions, it would be rather?? difficult to establish a formal vehicle (i.e. fund) for investment in IP resource blocks ???based on a requirement for the necessary representations and the associated risk ???of loss of the entire investment in cases of fraud.?? Other than that circumstance, ???I agree that it would be fairly straightforward for most operating companies to make?? reasonable representations based on anticipated needs without significant concern.?Thanks!/John??Now the boogeyman has morphed into a hypothetical formal investment fund for IPv4 addresses. Despite zero evidence of anybody buying addresses and then reselling them for profit, we are asked to include this non-operational chaff in the NRPM. Despite an atomized supply, despite anti-flip provisions, despite IPv6 in the offing.? I wonder again what is keeping this fictional investment fund from opening a RIPE LIR and buying all they want? ?For what it's worth, there are active buyers today seeking to acquire millions of addresses which they desperately need for their operational networks and planned growth. Guess what, despite having the largest warchests around, they can't find sellers capable of meeting their needs. Why do you think a fund would have any more luck? Where is your evidence that 8.5.2 would have significant teeth regarding its inhibiting effect on viable large scale investments in ipv4? Is this just your opinion??John, people can have different views on whether IP blocks should be treated as other commodities, and thus hedged, invested in, or speculated on. There is no need to cast aspersions on those who have this view, and your language about "questionable repute" goes beyond policy advice and veers into policy partisanship.?Regards,Mike????_______________________________________________PPMLYou are receiving this message because you are subscribed tothe ARIN Public Policy Mailing List (ARIN-PPML at arin.net).Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-ppmlPlease 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/20160624/5449018c/attachment.htm>

From mike at iptrading.com  Fri Jun 24 10:52:21 2016
From: mike at iptrading.com (Mike Burns)
Date: Fri, 24 Jun 2016 10:52:21 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
	Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <EF501E8D91217774.DC19A7BA-8880-4227-8634-AF0EF8997B26@mail.outlook.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
	<576C779D.5000409@linuxmagic.com>
	<4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>
	<00c501d1ce20$a7ded910$f79c8b30$@iptrading.com>
	<EF501E8D91217774.6DAB6491-CC3E-41BA-8184-008BF264C60F@mail.outlook.com>
	<00d001d1ce23$1e42b340$5ac819c0$@iptrading.com>
	<EF501E8D91217774.DC19A7BA-8880-4227-8634-AF0EF8997B26@mail.outlook.com>
Message-ID: <00f301d1ce28$035dd5f0$0a1981d0$@iptrading.com>

Hi Scott,

 

I would support the policy even with 8.5.2, having registered my concerns.

 

I would support it more if 8.5.2 was removed, and transfer needs were determined under the already-operative NRPM 1.2 text calling for efficient distribution to organizations who have a technical need for the addresses in support of operational networks. We shouldn?t copy bits of operational text and stick them in every section simply to afford convenience to those who can?t be bothered to find them in section 1.

 

Let an officer attest to the fact that they need the addresses in support of an operational network, fine.  The real functional attestation of need is the corporation paying for the addresses and that won?t change.

 

So I would encourage simplification via the removal of 8.5.2 on the basis that it goes beyond 1.2 through the use of the word ?solely?, which will lead to confusion with buyers who either don?t yet have an operational network, or buyers who are buying for strictly planning purposes.

 

Regards,

Mike

 

 

 

 

 

 

 

From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
Sent: Friday, June 24, 2016 10:22 AM
To: Mike Burns <mike at iptrading.com>; Michael Peddemors <michael at linuxmagic.com>; John Curran <jcurran at arin.net>
Cc: arin-ppml at arin.net
Subject: RE: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

 

I am assuming we'll need to tighten up this language to make it more operational: specifically requiring attestation of operational use, not just making a general statement about ARIN only issuing space to operational networks. Would that help address your concern? If so, let's revisit after Andrew and I and the AC shepherds figure out the exact revision we want there, unless you have any specific suggestions for language we should consider. 

-Scott

 

_____________________________
From: Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> >
Sent: Friday, June 24, 2016 9:17 AM
Subject: RE: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
To: Scott Leibrand <scottleibrand at gmail.com <mailto:scottleibrand at gmail.com> >, Michael Peddemors <michael at linuxmagic.com <mailto:michael at linuxmagic.com> >, John Curran <jcurran at arin.net <mailto:jcurran at arin.net> >
Cc: <arin-ppml at arin.net <mailto:arin-ppml at arin.net> >



Hi Scott,

 

I see the harm in the inclusion of non-operational text which seems to put into the NRPM something like a specific community expression against financial speculation which I think is not necessary. This inclusion could end up being a Trojan horse for future policy which could hinge on the assumption that the ARIN community had made this overt expression.

 

As I said I support the intent of simplifying the transfer policy but I don?t think 8.5.2 is necessary in light of NRPM 1.2 Conservation:  Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks.

 

 

On the assumption that we don?t want wasted or non-op verbiage in the NRPM, why is this section required?

 

Regards,

Mike

 

 

 

 

 

 

From: Scott Leibrand [mailto:scottleibrand at gmail.com] 
Sent: Friday, June 24, 2016 10:09 AM
To: Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> >; Michael Peddemors <michael at linuxmagic.com <mailto:michael at linuxmagic.com> >; John Curran <jcurran at arin.net <mailto:jcurran at arin.net> >
Cc: arin-ppml at arin.net <mailto:arin-ppml at arin.net> 
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

 

Mike,

 

I think you're misunderstanding the intent here. This very simple "operational use" clause, that doesn't interfere with *any* legitimate transfers, is all that should be needed to prevent financial speculation, and allow us to dramatically simplify the needs test, or even remove it entirely in some cases (like the /24 for new entrants). Unless you see some actual harm that the clause would do, please just consider it "insurance" against an unlikely event that some people are concerned about, so we can move on to actually simplifying the rest of the policy. 

-Scott

 

 

On Fri, Jun 24, 2016 at 8:59 AM -0500, "Mike Burns" <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

 
 
   I do believe such a provision would have significant teeth with respect to inhibiting
   IP address blocks as a viable large scale investment opportunity.   While those 
   of questionable repute may want work around such provisions, it would be rather
   difficult to establish a formal vehicle (i.e. fund) for investment in IP resource blocks 
   based on a requirement for the necessary representations and the associated risk 
   of loss of the entire investment in cases of fraud.   Other than that circumstance, 
   I agree that it would be fairly straightforward for most operating companies to make
   reasonable representations based on anticipated needs without significant concern.
 
Thanks!
/John
 
 
Now the boogeyman has morphed into a hypothetical formal investment fund for IPv4 addresses. Despite zero evidence of anybody buying addresses and then reselling them for profit, we are asked to include this non-operational chaff in the NRPM. Despite an atomized supply, despite anti-flip provisions, despite IPv6 in the offing.  I wonder again what is keeping this fictional investment fund from opening a RIPE LIR and buying all they want? 
 
For what it's worth, there are active buyers today seeking to acquire millions of addresses which they desperately need for their operational networks and planned growth. Guess what, despite having the largest warchests around, they can't find sellers capable of meeting their needs. Why do you think a fund would have any more luck? Where is your evidence that 8.5.2 would have significant teeth regarding its inhibiting effect on viable large scale investments in ipv4? Is this just your opinion?
 
John, people can have different views on whether IP blocks should be treated as other commodities, and thus hedged, invested in, or speculated on. There is no need to cast aspersions on those who have this view, and your language about "questionable repute" goes beyond policy advice and veers into policy partisanship.
 
Regards,
Mike
 
 
 
 
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net> ).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net <mailto:info at arin.net>  if you experience any issues.

 

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

From andrew.dul at quark.net  Fri Jun 24 11:51:47 2016
From: andrew.dul at quark.net (Andrew Dul)
Date: Fri, 24 Jun 2016 08:51:47 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <20160623025410.GA3707@panix.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
	<20160623025410.GA3707@panix.com>
Message-ID: <47c33513-588d-7f17-4f3a-fc973b5b5412@quark.net>

On 6/22/2016 7:54 PM, Brett Frankenberger wrote:
>
>> We are certainly open to other language if you would like to suggest
>> something, to clarify our intent.
>      8.5.4. Initial block
>          
>      Organizations without direct assignments or allocations from ARIN
>      qualify for transfer of an initial block of ARIN's minimum transfer size.
>
> That language suggests that if I am an organization with no direct
> assignment or allocation, I qualify for a transfer of a /24.  What you
> appear to be saying is that the actual policy (due to the contribution
> of 8.5.2) is that I qualify for a /24 if I am an organization with no
> direct assignmetns or allocations, *and* I intend to use them on an
> operational network.
>
> If the latter is the intended policy, I would write it that way:
>
>    8.5.4:  Organizations without direct assignments or allocations from
>            ARIN qualify for a transfer of an initial block of ARIN's
>            minimum transfer size, provided the organization intends to
>            use the transferred block on an operational network.
>
> 8.5.2 could then be removed (or, if it was left, it would at least not
> appear inconsistent with 8.5.4.)
>
> (By way of analogy, if our intent is that 8.5.2 would effectively
> impose an additional constraint on an 8.5.4 transfer, then we have an
> NRPM that is conceptually like:
>    SECTION A:  All children are entitled to a lollipop.
>    SECTION B:  Actually, only children that plan to consume the lollipop
>                are entitled to a lollopop.
> That strikes me as poorly drafted.)
Brett,

Thanks for the suggested rewrite for additional clarity.  I'll take that
into account as we consider updates to this policy draft in the future.

Andrew


From jcurran at arin.net  Fri Jun 24 11:49:15 2016
From: jcurran at arin.net (John Curran)
Date: Fri, 24 Jun 2016 15:49:15 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <00c501d1ce20$a7ded910$f79c8b30$@iptrading.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<000801d1cc9f$2c775720$85660560$@iptrading.com>
	<CAGkMwz5r7x95q6SmfAZUoq-MbWyNDFXDnfEjf2djjstgiwobFw@mail.gmail.com>
	<20160622182636.GA15225@panix.com>
	<96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
	<576C779D.5000409@linuxmagic.com>
	<4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>
	<00c501d1ce20$a7ded910$f79c8b30$@iptrading.com>
Message-ID: <265BCC74-B7E7-49F5-AF2C-0E8D2EF0EA5A@arin.net>

On Jun 24, 2016, at 9:59 AM, Mike Burns <mike at iptrading.com> wrote:
> 
> Now the boogeyman has morphed into a hypothetical formal investment fund for IPv4 addresses.

Mike - 
 
    I have had financial organizations ask me specifically about ?investability?
    in IPv4 number resources, and explained both our current policies and the 
    policy development process (I also pointed them at the list of transfer
    facilitators, to gain additional perspectives from the ?market? itself.) 

> Despite zero evidence of anybody buying addresses and then reselling them for profit, we are asked to include this non-operational chaff in the NRPM.

    I have no idea if it is prudent to include this provision or not, but was
    noting that it could have a material effect in some cases.  

> ... Where is your evidence that 8.5.2 would have significant teeth regarding its inhibiting effect on viable large scale investments in ipv4? Is this just your opinion?

    Having explained the requirements for compliance with transfer policy and 
    the potential for resource review and reclamation in the case of fraudulent
    representations during a transfer, the financial types that I have spoken to
    have indicated exactly that point - their risk management departments would 
    not sign off on an investment structure that requires representations that are
    not clearly and evidently valid.  
 
    There is no doubt that the present representations required are sufficient to
    preclude their direct speculation in IPv4 number resources, and my point 
    was only that if the community continues to desire that outcome, it may be
    achievable with less complicated (but still legal strong) policy language, 
    such as that contained in 8.5.2.  (I will leave it to you and others on the list
    the entirely different questions of whether that outcome is desirable or not?)

> John, people can have different views on whether IP blocks should be treated as other commodities, and thus hedged, invested in, or speculated on. There is no need to cast aspersions on those who have this view, and your language about "questionable repute" goes beyond policy advice and veers into policy partisanship.

    See above - I have no desire to cast aspersions on any policy positions,
    but I am obligated to support the policy development process and this 
    includes sharing information that might not be otherwise apparent to the 
    community.

Thanks!
/John

John Curran
President and CEO
ARIN



From matthew at matthew.at  Fri Jun 24 14:16:43 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 24 Jun 2016 18:16:43 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>
Message-ID: <em07e692b8-80c1-4463-bea4-d74e1af23b12@matthew-t5500>

[Top-posting because the specifics don't matter]

Deck chairs. Titanic. If y'all would go deploy the worldwide native IPv6 
Internet, none of what happens to IPv4 - including it all being bought 
up by "evil speculators" - matters one bit. The amount of time spent 
discussing IPv4 policy in the past few months, never mind the amount of 
hand-wringing about possible outcomes if the policy is "exploited" by 
someone is probably sufficient to have just built the replacement that 
I'm told doesn't suffer from any of these issues. Among other things, 
the "little guys" that needs assessment is supposedly protecting 
(despite ample evidence that /8s are getting locked up outside of policy 
by large organizations with perceived need) can go get all the IPv6 
space they need, right now, without any trouble.

Is there a way to submit a proposal to the policy development process 
itself to block any and all future policy changes that impact IPv4 so we 
can just vote on that and then stop this nonsense?

Matthew Kaufman

------ Original Message ------
From: "John Curran" <jcurran at arin.net>
To: "Michael Peddemors" <michael at linuxmagic.com>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Sent: 6/24/2016 3:58:03 AM
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: 
Post-IPv4-Free-Pool-Depletion Transfer Policy

>On Jun 23, 2016, at 7:58 PM, Michael Peddemors <michael at linuxmagic.com> 
>wrote:
>>
>>  On 16-06-22 06:47 PM, Andrew Dul wrote:
>>>  The point of 8.5.2 is to clarify that the community believes that 
>>>IPv4
>>>  addresses are to be used on operational networks, not as resources 
>>>to be
>>>  held for some other purpose (e.g. financial speculation).  We ask 
>>>that
>>>  an officer of the organization to attest to ensure that the 
>>>organization
>>>  understands the nature of the transaction and doesn't commit its $ 
>>>in
>>>  support of other goals.  I believe having it in section 8 helps
>>>  organizations clearly understand the requirements for transfer.  
>>>(e.g.
>>>  They don't have to hunt around in other sections for other
>>>  requirements.) I, personally, believe that the base requirement for 
>>>any
>>>  transfer is that the organization intend to use it on an operational
>>>  network.
>>
>>  Only concern I have, is that it has no real teeth.. You can always 
>>'make' it operational, we have seen recent allotments simply rented 
>>out to spammers who want virgin IP space.. boom.. now it is 
>>used/operational
>
>Michael -
>
>    That particular case wouldn?t qualify, as they would have to detail 
>their usage of
>    the IP address space on their own operational networks (if there is 
>a different
>    intent of the policy, the language should be changed to make that 
>quite clear.)
>
>    I do believe such a provision would have significant teeth with 
>respect to inhibiting
>    IP address blocks as a viable large scale investment opportunity.   
>While those
>    of questionable repute may want work around such provisions, it 
>would be rather
>    difficult to establish a formal vehicle (i.e. fund) for investment 
>in IP resource blocks
>    based on a requirement for the necessary representations and the 
>associated risk
>    of loss of the entire investment in cases of fraud.   Other than 
>that circumstance,
>    I agree that it would be fairly straightforward for most operating 
>companies to make
>    reasonable representations based on anticipated needs without 
>significant concern.
>
>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 matthew at matthew.at  Fri Jun 24 14:19:19 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 24 Jun 2016 18:19:19 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <265BCC74-B7E7-49F5-AF2C-0E8D2EF0EA5A@arin.net>
Message-ID: <ema607720b-a7be-4621-b869-5391a53612e0@matthew-t5500>



------ Original Message ------
From: "John Curran" <jcurran at arin.net>
To: "Mike Burns" <mike at iptrading.com>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Sent: 6/24/2016 8:49:15 AM
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: 
Post-IPv4-Free-Pool-Depletion Transfer Policy

>
>     Having explained the requirements for compliance with transfer 
>policy and
>     the potential for resource review and reclamation in the case of 
>fraudulent
>     representations during a transfer, the financial types that I have 
>spoken to
>     have indicated exactly that point - their risk management 
>departments would
>     not sign off on an investment structure that requires 
>representations that are
>     not clearly and evidently valid.
>

Too bad Enron isn't still around, as I believe that must be the last 
time there ever was or will ever be a financial speculation operation 
that appeared to ignore potentially fraudulent activity.

Matthew Kaufman



From Matthew.Wilder at telus.com  Fri Jun 24 14:53:45 2016
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Fri, 24 Jun 2016 12:53:45 -0600
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <em07e692b8-80c1-4463-bea4-d74e1af23b12@matthew-t5500>
References: <4D3F45E1-594E-4570-A75D-013213723FDE@corp.arin.net>
	<em07e692b8-80c1-4463-bea4-d74e1af23b12@matthew-t5500>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B23FBFFB308@WP40044.corp.ads>

It's probably a good time to stop the Titanic reference.  Sure IPv6 deployment has reached 12% globally, but my most optimistic projections show that IPv4 is going to be relevant for a half decade more from now.  I think the Titanic sunk in less time if I'm not mistaken.

Transfer policies are going to be the most stable source of IPv4 addresses post-depletion so it does make good sense to have good policies for those organizations who need it.

mw

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Kaufman
Sent: June 24, 2016 11:17 AM
To: John Curran; Michael Peddemors
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

[Top-posting because the specifics don't matter]

Deck chairs. Titanic. If y'all would go deploy the worldwide native IPv6 Internet, none of what happens to IPv4 - including it all being bought up by "evil speculators" - matters one bit. The amount of time spent discussing IPv4 policy in the past few months, never mind the amount of hand-wringing about possible outcomes if the policy is "exploited" by someone is probably sufficient to have just built the replacement that I'm told doesn't suffer from any of these issues. Among other things, the "little guys" that needs assessment is supposedly protecting (despite ample evidence that /8s are getting locked up outside of policy by large organizations with perceived need) can go get all the IPv6 space they need, right now, without any trouble.

Is there a way to submit a proposal to the policy development process itself to block any and all future policy changes that impact IPv4 so we can just vote on that and then stop this nonsense?

Matthew Kaufman

------ Original Message ------
From: "John Curran" <jcurran at arin.net>
To: "Michael Peddemors" <michael at linuxmagic.com>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Sent: 6/24/2016 3:58:03 AM
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: 
Post-IPv4-Free-Pool-Depletion Transfer Policy

>On Jun 23, 2016, at 7:58 PM, Michael Peddemors <michael at linuxmagic.com>
>wrote:
>>
>>  On 16-06-22 06:47 PM, Andrew Dul wrote:
>>>  The point of 8.5.2 is to clarify that the community believes that
>>>IPv4
>>>  addresses are to be used on operational networks, not as resources 
>>>to be
>>>  held for some other purpose (e.g. financial speculation).  We ask 
>>>that
>>>  an officer of the organization to attest to ensure that the 
>>>organization
>>>  understands the nature of the transaction and doesn't commit its $ 
>>>in
>>>  support of other goals.  I believe having it in section 8 helps
>>>  organizations clearly understand the requirements for transfer.  
>>>(e.g.
>>>  They don't have to hunt around in other sections for other
>>>  requirements.) I, personally, believe that the base requirement for 
>>>any
>>>  transfer is that the organization intend to use it on an 
>>>operational
>>>  network.
>>
>>  Only concern I have, is that it has no real teeth.. You can always 
>>'make' it operational, we have seen recent allotments simply rented 
>>out to spammers who want virgin IP space.. boom.. now it is 
>>used/operational
>
>Michael -
>
>    That particular case wouldn?t qualify, as they would have to detail 
>their usage of
>    the IP address space on their own operational networks (if there is 
>a different
>    intent of the policy, the language should be changed to make that 
>quite clear.)
>
>    I do believe such a provision would have significant teeth with 
>respect to inhibiting
>    IP address blocks as a viable large scale investment opportunity.   
>While those
>    of questionable repute may want work around such provisions, it 
>would be rather
>    difficult to establish a formal vehicle (i.e. fund) for investment 
>in IP resource blocks
>    based on a requirement for the necessary representations and the 
>associated risk
>    of loss of the entire investment in cases of fraud.   Other than 
>that circumstance,
>    I agree that it would be fairly straightforward for most operating 
>companies to make
>    reasonable representations based on anticipated needs without 
>significant concern.
>
>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.

_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage 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  Fri Jun 24 14:23:20 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 24 Jun 2016 18:23:20 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <96281eea-9f08-cb6e-bad8-1277ded65327@quark.net>
Message-ID: <em7494df8a-200e-4953-ba35-4996542930ca@matthew-t5500>


From: "Andrew Dul" <andrew.dul at quark.net>:
>The point of 8.5.2 is to clarify that the community believes that IPv4
>addresses are to be used on operational networks, not as resources to 
>be
>held for some other purpose (e.g. financial speculation).

Why? Who cares? IPv4 is dead. Go deploy IPv6 and ignore what happens 
with IPv4.

If it all gets bought up by speculators then you'll be forced to 
actually build the IPv6 Internet and then the speculators lose all their 
money. Good for you, bad for them. Problem solved.

Matthew Kaufman



From matthew at matthew.at  Fri Jun 24 16:37:36 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 24 Jun 2016 20:37:36 +0000
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B23FBFFB308@WP40044.corp.ads>
Message-ID: <emf551baaf-d490-4a96-88a6-383b40140a3e@matthew-t5500>


From: "Matthew Wilder" <Matthew.Wilder at telus.com>:


>It's probably a good time to stop the Titanic reference.  Sure IPv6 
>deployment has reached 12% globally, but my most optimistic projections 
>show that IPv4 is going to be relevant for a half decade more from now. 
>  I think the Titanic sunk in less time if I'm not mistaken.

Only because we're all here talking about IPv4 policy instead of 
deploying IPv6.

>
>Transfer policies are going to be the most stable source of IPv4 
>addresses post-depletion so it does make good sense to have good 
>policies for those organizations who need it.

Why?

Organizations who need it are arguably doing something wrong. Why should 
we have policies any better/different than the existing ones? More 
importantly, why is changing the policies we have now a good use of 
anyone's time?

Matthew Kaufman



From scottleibrand at gmail.com  Fri Jun 24 17:09:22 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 24 Jun 2016 14:09:22 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <emf551baaf-d490-4a96-88a6-383b40140a3e@matthew-t5500>
References: <DE229826F48ABD4CBF754E5AA6CFC14B23FBFFB308@WP40044.corp.ads>
	<emf551baaf-d490-4a96-88a6-383b40140a3e@matthew-t5500>
Message-ID: <CAGkMwz7cmZgxoxz3LGwvdPZ+hx00dJu=vtGzKHcTCjJEqGCgjA@mail.gmail.com>

Matthew,

Have converted your network to IPv6-only, turned off IPv4, and returned
your IPv4 addresses to ARIN?  If not, I think you know why IPv4 is still
necessary, and why new and growing networks still need to acquire IPv4
addresses.  And as long as organizations still need to get IPv4 addresses,
simplifying the policies for doing so will save far more time for
applicants (to spend on IPv6 deployment if they want) than it will cost in
discussing the policies.  I don't think I can say the same about Titanic
meta-discussions, though.

-Scott

On Fri, Jun 24, 2016 at 1:37 PM, Matthew Kaufman <matthew at matthew.at> wrote:

>
> From: "Matthew Wilder" <Matthew.Wilder at telus.com>:
>
>
> It's probably a good time to stop the Titanic reference.  Sure IPv6
>> deployment has reached 12% globally, but my most optimistic projections
>> show that IPv4 is going to be relevant for a half decade more from now.  I
>> think the Titanic sunk in less time if I'm not mistaken.
>>
>
> Only because we're all here talking about IPv4 policy instead of deploying
> IPv6.
>
>
>> Transfer policies are going to be the most stable source of IPv4
>> addresses post-depletion so it does make good sense to have good policies
>> for those organizations who need it.
>>
>
> Why?
>
> Organizations who need it are arguably doing something wrong. Why should
> we have policies any better/different than the existing ones? More
> importantly, why is changing the policies we have now a good use of
> anyone's time?
>
> 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/20160624/48551d53/attachment.htm>

From matthew at matthew.at  Sat Jun 25 02:20:05 2016
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 24 Jun 2016 23:20:05 -0700
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <CAGkMwz7cmZgxoxz3LGwvdPZ+hx00dJu=vtGzKHcTCjJEqGCgjA@mail.gmail.com>
References: <DE229826F48ABD4CBF754E5AA6CFC14B23FBFFB308@WP40044.corp.ads>
	<emf551baaf-d490-4a96-88a6-383b40140a3e@matthew-t5500>
	<CAGkMwz7cmZgxoxz3LGwvdPZ+hx00dJu=vtGzKHcTCjJEqGCgjA@mail.gmail.com>
Message-ID: <576E2295.6030603@matthew.at>



On 6/24/16 2:09 PM, Scott Leibrand wrote:
> Matthew,
>
> Have converted your network to IPv6-only

No, because neither of my two transit providers have IPv6 yet. Hopefully 
that's not because they're spending all their time debating IPv4 policy.

> , turned off IPv4,

See above.

> and returned your IPv4 addresses to ARIN?

Why would I return my IPv4 addresses to ARIN? First off, I didn't get 
them from ARIN... and second, I hear they're going to be quite valuable 
to speculators.

Matthew Kaufman



From cblecker at gmail.com  Sat Jun 25 15:53:59 2016
From: cblecker at gmail.com (Christoph Blecker)
Date: Sat, 25 Jun 2016 12:53:59 -0700
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-1: Reserved Pool
 Transfer Policy
In-Reply-To: <576967BD.9020400@arin.net>
References: <576967BD.9020400@arin.net>
Message-ID: <CADx2oGEp9-XC6q6LzBykoi-DJrYq0AdvAKknVdoPUc9OHjfyZw@mail.gmail.com>

I support this policy proposal as written.

Cheers,
Christoph

On 21 June 2016 at 09:13, ARIN <info at arin.net> wrote:

> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following
> Draft Policy to Recommended Draft Policy status:
>
> ARIN-2016-1: Reserved Pool Transfer Policy
>
> The text of the Recommended Draft Policy is below, and may also be found
> at:
> https://www.arin.net/policy/proposals/2016_1.html
>
> You are encouraged to discuss all Recommended Draft Policies on PPML prior
> to their presentation at the next ARIN Public Policy Consultation (PPC).
> PPML and PPC discussions are invaluable to the AC when determining
> community consensus.
>
> The 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)
>
> Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
>
> Date: 21 June 2016
>
> AC assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> This proposal enables fair and impartial number resource administration by
> ensuring that IPv4 resources, which are specially designated for critical
> infrastructure and IPv6 transition, are readily available for many years
> into the future. This is done by ensuring the resources remain in their
> originally designated pool rather than being moved into the general IPv4
> address pool via a transfer.  This proposal is technically sound and is
> supported by the community.
>
> Problem Statement:
>
> Section 8 of the current NRPM does not distinguish between the transfer of
> blocks from addresses that have been reserved for specific uses and other
> addresses that can be transferred. In sections 4.4 and 4.10 there are
> specific address blocks set aside, based on the need for critical
> infrastructure and IPv6 transitions. Two issues arise if transfers of
> reserved address space occur under the current language of section 8.
> First, if transfers of 4.4 or 4.10 space occur under the current policy
> requirements set forth in sections 8.3 and 8.4, the recipients will be able
> to acquire space that was originally reserved for a specific purpose
> without ever providing evidence that they will be using the space for
> either critical infrastructure or IPv6 transition. Second, if we allow an
> allocation or assignment from the block reserved in section 4.10 to be
> transferred out of the region, it would complicate the single aggregate
> from which providers are being asked to allow in block sizes smaller than a
> /24. This policy would limit the transfer of addresses from reserved pools.
>
> Policy statement:
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> Timetable for implementation: Immediate
>
> ##########
>
> ARIN STAFF & LEGAL ASSESSMENT
> Draft Policy ARIN-2016-1
> RESERVED POOL TRANSFER POLICY
> https://www.arin.net/policy/proposals/2016_1.html
>
> Date of Assessment: 13 June 2016
> ___
> 1. Summary (Staff Understanding)
>
> This policy would make IPv4 addresses issued under NRPM 4.4 and 4.10
> ineligible for transfer inside the NRPM 8.3 and 8.4 transfer policies.
> ___
> 2. Comments
>
> A. ARIN Staff Comments
>
> * If this policy is implemented, ARIN staff would not allow NRPM 8.3 and
> 8.4 transfers to include IPv4 addresses previously issued under NRPM 4.4
> and 4.10 policies.
>
> * ARIN staff would continue to allow IPv4 addresses previously issued
> under NRPM 4.4 and 4.10 to be included in Merger and Acquisition (NRPM 8.2)
> transfers.
>
> * This policy could be implemented as written.
>
> B. ARIN General Counsel ? Legal Assessment
>
> The policy does not create a material legal issue. It should be noted that
> ARIN does permit transfers of IPV4 resources pursuant to 8.3 and 8.4. This
> policy is an exception to that transferability and is consistent with the
> intent and of the policy by which these allocations were made.
> ___
> 3. Resource Impact
>
> Implementation of this policy would have minimal resource impact. It is
> estimated that implementation would occur within 3 months after
> ratification by the ARIN Board of Trustees. The following would be needed
> in order to implement:
>
> * Updated guidelines and internal procedures
>
> * Staff training
> ___
> 4. Proposal / Draft Policy Text Assessed
>
> Draft Policy ARIN-2016-1
> Reserved Pool Transfer Policy
>
> Date: 22 March 2016
>
> Problem Statement:
>
> Section 8 of the current NRPM does not distinguish between the transfer of
> blocks from addresses that have been reserved for specific uses and other
> addresses that can be transferred. In sections 4.4 and 4.10 there are
> specific address blocks set aside, based on the need for critical
> infrastructure and IPv6 transitions. Two issues arise if transfers of
> reserved address space occur under the current language of section 8.
> First, if transfers of 4.4 or 4.10 space occur under the current policy
> requirements set forth in sections 8.3 and 8.4, the recipients will be able
> to acquire space that was originally reserved for a specific purpose
> without ever providing evidence that they will be using the space for
> either critical infrastructure or IPv6 transition. Second, if we allow an
> allocation or assignment from the block reserved in section 4.10 to be
> transferred out of the region, it would complicate the single aggregate
> from which providers are being asked to allow in block sizes smaller than a
> /24. This policy would limit the transfer of addresses from reserved pools.
>
> Policy statement:
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> Timetable for implementation: Immediate
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160625/2549d3d2/attachment.htm>

From jschiller at google.com  Sat Jun 25 17:55:15 2016
From: jschiller at google.com (Jason Schiller)
Date: Sat, 25 Jun 2016 17:55:15 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-1: Reserved Pool
 Transfer Policy
In-Reply-To: <576967BD.9020400@arin.net>
References: <576967BD.9020400@arin.net>
Message-ID: <CAC4yj2V8PpKBzdJC+3CQzkzJ5CTZAA4cO-aeLtAzv_wCgi6=8w@mail.gmail.com>

I support as written.

__Jason

On Tue, Jun 21, 2016 at 12:13 PM, ARIN <info at arin.net> wrote:

> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following
> Draft Policy to Recommended Draft Policy status:
>
> ARIN-2016-1: Reserved Pool Transfer Policy
>
> The text of the Recommended Draft Policy is below, and may also be found
> at:
> https://www.arin.net/policy/proposals/2016_1.html
>
> You are encouraged to discuss all Recommended Draft Policies on PPML prior
> to their presentation at the next ARIN Public Policy Consultation (PPC).
> PPML and PPC discussions are invaluable to the AC when determining
> community consensus.
>
> The 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)
>
> Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
>
> Date: 21 June 2016
>
> AC assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> This proposal enables fair and impartial number resource administration by
> ensuring that IPv4 resources, which are specially designated for critical
> infrastructure and IPv6 transition, are readily available for many years
> into the future. This is done by ensuring the resources remain in their
> originally designated pool rather than being moved into the general IPv4
> address pool via a transfer.  This proposal is technically sound and is
> supported by the community.
>
> Problem Statement:
>
> Section 8 of the current NRPM does not distinguish between the transfer of
> blocks from addresses that have been reserved for specific uses and other
> addresses that can be transferred. In sections 4.4 and 4.10 there are
> specific address blocks set aside, based on the need for critical
> infrastructure and IPv6 transitions. Two issues arise if transfers of
> reserved address space occur under the current language of section 8.
> First, if transfers of 4.4 or 4.10 space occur under the current policy
> requirements set forth in sections 8.3 and 8.4, the recipients will be able
> to acquire space that was originally reserved for a specific purpose
> without ever providing evidence that they will be using the space for
> either critical infrastructure or IPv6 transition. Second, if we allow an
> allocation or assignment from the block reserved in section 4.10 to be
> transferred out of the region, it would complicate the single aggregate
> from which providers are being asked to allow in block sizes smaller than a
> /24. This policy would limit the transfer of addresses from reserved pools.
>
> Policy statement:
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> Timetable for implementation: Immediate
>
> ##########
>
> ARIN STAFF & LEGAL ASSESSMENT
> Draft Policy ARIN-2016-1
> RESERVED POOL TRANSFER POLICY
> https://www.arin.net/policy/proposals/2016_1.html
>
> Date of Assessment: 13 June 2016
> ___
> 1. Summary (Staff Understanding)
>
> This policy would make IPv4 addresses issued under NRPM 4.4 and 4.10
> ineligible for transfer inside the NRPM 8.3 and 8.4 transfer policies.
> ___
> 2. Comments
>
> A. ARIN Staff Comments
>
> * If this policy is implemented, ARIN staff would not allow NRPM 8.3 and
> 8.4 transfers to include IPv4 addresses previously issued under NRPM 4.4
> and 4.10 policies.
>
> * ARIN staff would continue to allow IPv4 addresses previously issued
> under NRPM 4.4 and 4.10 to be included in Merger and Acquisition (NRPM 8.2)
> transfers.
>
> * This policy could be implemented as written.
>
> B. ARIN General Counsel ? Legal Assessment
>
> The policy does not create a material legal issue. It should be noted that
> ARIN does permit transfers of IPV4 resources pursuant to 8.3 and 8.4. This
> policy is an exception to that transferability and is consistent with the
> intent and of the policy by which these allocations were made.
> ___
> 3. Resource Impact
>
> Implementation of this policy would have minimal resource impact. It is
> estimated that implementation would occur within 3 months after
> ratification by the ARIN Board of Trustees. The following would be needed
> in order to implement:
>
> * Updated guidelines and internal procedures
>
> * Staff training
> ___
> 4. Proposal / Draft Policy Text Assessed
>
> Draft Policy ARIN-2016-1
> Reserved Pool Transfer Policy
>
> Date: 22 March 2016
>
> Problem Statement:
>
> Section 8 of the current NRPM does not distinguish between the transfer of
> blocks from addresses that have been reserved for specific uses and other
> addresses that can be transferred. In sections 4.4 and 4.10 there are
> specific address blocks set aside, based on the need for critical
> infrastructure and IPv6 transitions. Two issues arise if transfers of
> reserved address space occur under the current language of section 8.
> First, if transfers of 4.4 or 4.10 space occur under the current policy
> requirements set forth in sections 8.3 and 8.4, the recipients will be able
> to acquire space that was originally reserved for a specific purpose
> without ever providing evidence that they will be using the space for
> either critical infrastructure or IPv6 transition. Second, if we allow an
> allocation or assignment from the block reserved in section 4.10 to be
> transferred out of the region, it would complicate the single aggregate
> from which providers are being asked to allow in block sizes smaller than a
> /24. This policy would limit the transfer of addresses from reserved pools.
>
> Policy statement:
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> Timetable for implementation: Immediate
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.




-- 
_______________________________________________________
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/20160625/dc2ca962/attachment.htm>

From jschiller at google.com  Sat Jun 25 18:38:12 2016
From: jschiller at google.com (Jason Schiller)
Date: Sat, 25 Jun 2016 18:38:12 -0400
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <372DC1BE-372D-45A8-BBA6-9937D978D8EF@delong.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<372DC1BE-372D-45A8-BBA6-9937D978D8EF@delong.com>
Message-ID: <CAC4yj2U4FkCJw8CP_dQO-7JO4=eB9NoSBVja-cqvZ-T94KCyrg@mail.gmail.com>

Would it be beneficial to do a rewrite as Andrew did, but simply make it
editorial without changing the intent or implementation of the policy.
Then do a red line for intent changes?

This would enable use to discuss the simplification and re-organization
without getting bogged down in disagreement over changes.

Once we agree on the non-policy impacting editorial re-write, then we could
look at red-line changes, and decide which policy changes have support and
which do not. We could then move forward with the changes that are
supported, tweak the text a bit, and discuss it in the fall without getting
bogged down in discussions about the re-organization.

Andrew, Owen, what do you think?

__Jason

On Wed, Jun 22, 2016 at 1:30 PM, Owen DeLong <owen at delong.com> wrote:

>
> > On Jun 22, 2016, at 08:46 , Andrew Dul <andrew.dul at quark.net> wrote:
> >
> > As the primary author of this draft policy, I respectfully disagree with
> > my AC colleague.
> >
> > Now that the free pool has been depleted, it is time to look toward what
> > future IPv4 (primarily transfer) policy should do.  While this policy
> > looks complicated, its intention is to create a very simple transfer
> > policy which allows businesses to predictably and efficiently transfer
> > IPv4 resources to meet their requirements.
>
> I don?t disagree with your intent, but I disagree that what you have
> proposed achieves that intent.
>
> You are eliminating key safeguards from the transfer policy while
> simultaneously
> changing several of the criteria that have previously applied to transfers
> of
> IPv4 space under section 4.
>
> In addition, there may be unintended effects on the transfer of ASNs.
>
> > I share with you here a redline which shows the changes that would be
> > made to section 8.
>
> The redline doesn?t begin to cover it because it does nothing to evaluate
> how
> removing the existing interactions with section 4 compares to existing
> policy
> implementation.
>
> As a result, the redline ends up looking deceptively minor.
>
> Owen
>
> >
> > Andrew
> >
> > On 6/21/2016 9:16 AM, Owen DeLong wrote:
> >> I am opposed to this policy proposal.
> >>
> >> Given that we are now in a world where the only way to obtain IPv4
> space is through transfers, I think it makes much more sense to put policy
> changes for IPv4 transfers into section 4 and retain the simplified text
> that exists today in section 8 rather than copying most of section 4 into
> section 8 with revisions in the process.
> >>
> >> The likely outcome of such an exercise is to create a number of changes
> which may or may not be fully understood by the community. The interaction
> of this rewrite with other types of transferable resources (AS numbers at
> the moment) must also be carefully considered.
> >>
> >> If we want to change IPv4 policy, then let?s change IPv4 policy in
> section 4.
> >>
> >> If we want to change transfer policy for all resources, we can do that
> cleanly in section 8.
> >>
> >> While the NRPM may not be a perfect model of a structured document,
> this proposal would make it significantly worse.
> >>
> >> Owen
> >>
> >>> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net> wrote:
> >>>
> >>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following
> Proposal to Draft Policy status:
> >>>
> >>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
> >>>
> >>> This Draft Policy has been numbered and titled:
> >>>
> >>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
> >>>
> >>> Draft Policy ARIN-2016-5 is below and can be found at:
> >>> https://www.arin.net/policy/proposals/2016_5.html
> >>>
> >>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
> >>>
> >>>     > Enabling Fair and Impartial Number Resource Administration
> >>>     > Technically Sound
> >>>     > Supported by the Community
> >>>
> >>> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
> >>>
> >>> Date: 21 June 2016
> >>>
> >>> Problem Statement
> >>>
> >>> Section 4 of the Number Policy Resource Manual was developed over the
> past 15+ years primarily to conservatively manage the IPv4 number free
> pool. Since the IPv4 free pool was depleted in 2015, the policies which
> developed since ARIN's inception may now not be as relevant now that the
> primary function of the registry, with regard to IPv4 numbers, is to record
> transfers.
> >>>
> >>> Since section 4 of the NRPM now contains many use cases that are not
> as relevant, it makes sense to streamline the transfer process and to
> specifically outline the criteria that should be used to process transfers.
> >>>
> >>> Therefore, we propose the following rewrite of the transfer policy,
> section 8 of the NRPM.
> >>>
> >>> The goals of this rewrite are as follows:
> >>>
> >>>> Separate the criteria that is found in section 4 of the NRPM from the
> transfer process.
> >>>> Provide a clear set of criteria that should be applied across all
> IPv4 transfers.
> >>>> Lower the thresholds on utilization and future allocation size to
> negate the necessity of the corner cases which are currently enumerated in
> section 4 of the NRPM.
> >>>> Reduce the complexity that is currently required for transfers, by
> applying simpler utilization criteria for current usage, and future
> allocation sizing.
> >>> Policy statement:
> >>>
> >>> Add new section 8.5; update sections 8.2-8.4 as follows to reference
> 8.5.
> >>>
> >>> ######
> >>>
> >>> 8.2. Mergers, Acquisitions, and Reorganizations
> >>>
> >>> ARIN will consider requests for the transfer of number resources in
> the case of mergers, acquisitions, and reorganizations under the following
> conditions:
> >>>
> >>>> The current registrant must not be involved in any dispute as to the
> status of the resources to be transferred.
> >>>> The new entity must sign an RSA covering all resources to be
> transferred.
> >>>> The resources to be transferred will be subject to ARIN policies.
> >>>> The minimum transfer size is the smaller of the original allocation
> size or the applicable minimum allocation size in current policy.
> >>>> For mergers and acquisition transfers, the recipient entity must
> provide evidence that they have acquired assets that use the resources to
> be transferred from the current registrant. ARIN will maintain an
> up-to-date list of acceptable types of documentation.
> >>> ARIN will proceed with processing transfer requests even if the number
> resources of the combined organizations exceed what can be justified under
> current ARIN transfer policy as defined in section 8.5. In that event, ARIN
> will work with the resource holder(s) to transfer the extra number
> resources to other organization(s) or accept a voluntary return of the
> extra number resources to ARIN.
> >>>
> >>> 8.3. Transfers between Specified Recipients within the ARIN Region
> >>>
> >>> In addition to transfers under section 8.2, IPv4 numbers resources and
> ASNs may be transferred according to the following conditions.
> >>>
> >>> Conditions on source of the transfer:
> >>>
> >>>> The source entity must be the current registered holder of the IPv4
> address resources, and not be involved in any dispute as to the status of
> those resources.
> >>>> The source entity must not have received a transfer, allocation, or
> assignment of IPv4 number resources from ARIN for the 12 months prior to
> the approval of a transfer request. This restriction does not include M&A
> transfers.
> >>> Conditions on recipient of the transfer:
> >>>
> >>>> The recipients must meet the transfer requirements as defined in
> section 8.5.
> >>>> The resources transferred will be subject to current ARIN policies.
> >>> 8.4. Inter-RIR Transfers to Specified Recipients
> >>>
> >>> Inter-regional transfers may take place only via RIRs who agree to the
> transfer and share reciprocal, compatible, needs-based policies.
> >>>
> >>> Conditions on source of the transfer:
> >>>
> >>>> The source entity must be the current rights holder of the IPv4
> address resources recognized by the RIR responsible for the resources, and
> not be involved in any dispute as to the status of those resources.
> >>>> Source entities outside of the ARIN region must meet any requirements
> defined by the RIR where the source entity holds the registration.
> >>>> Source entities within the ARIN region must not have received a
> transfer, allocation, or assignment of IPv4 number resources from ARIN for
> the 12 months prior to the approval of a transfer request. This restriction
> does not include M&A transfers.
> >>> Conditions on recipient of the transfer:
> >>>
> >>>> The conditions on a recipient outside of the ARIN region will be
> defined by the policies of the receiving RIR.
> >>>> Recipients within the ARIN region must meet the transfer requirements
> as defined in section 8.5.
> >>>> Recipients within the ARIN region will be subject to current ARIN
> policies.
> >>> 8.5. Specified Transfer Recipient Requirements
> >>>
> >>> 8.5.1. Registration Services Agreement
> >>>
> >>> Transfer recipients must sign an RSA for the resources being received.
> >>>
> >>> 8.5.2. Operational Use
> >>>
> >>> ARIN allocates or assigns blocks of IP addresses to organizations via
> transfer solely for the purpose of use on an operational network.
> >>>
> >>> 8.5.3. Minimum transfer size
> >>>
> >>> ARIN's minimum transfer size is a /24.
> >>>
> >>> 8.5.4. Initial block
> >>>
> >>> Organizations without direct assignments or allocations from ARIN
> qualify for transfer of an initial block of ARIN's minimum transfer size.
> >>>
> >>> 8.5.5. Block size
> >>>
> >>> Organizations may qualify for the transfer of a larger initial block,
> or an additional block, by providing documentation to ARIN which details
> the use of at least 50% of the requested block size within 24 months. An
> officer of the organization shall attest to the documentation provided to
> ARIN.
> >>>
> >>> 8.5.6. Efficient utilization of previous blocks
> >>>
> >>> Organizations with direct assignments or allocations from ARIN must
> have efficiently utilized at least 50% of every block in order to receive
> additional space. This includes all space reassigned to their customers.
> >>>
> >>> Comments:
> >>>
> >>> Timetable for implementation: immediately
> >>>
> >>> Anything else: A redline has been provided to help the community
> understand the changes that have been made to the NRPM.
> >>> _______________________________________________
> >>> PPML
> >>> You are receiving this message because you are subscribed to
> >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>> Unsubscribe or manage 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.
> >
> >
> > <Post-IPv4 Free-Pool Depletion Transfer Policy (NRPM 8 redline) -
> 20160609.pdf>_______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage 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.
>



-- 
_______________________________________________________
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/20160625/f4f086a3/attachment.htm>

From scottleibrand at gmail.com  Sat Jun 25 22:24:19 2016
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Sun, 26 Jun 2016 02:24:19 +0000 (UTC)
Subject: [arin-ppml] Draft Policy ARIN-2016-5:
 Post-IPv4-Free-Pool-Depletion Transfer Policy
In-Reply-To: <CAC4yj2U4FkCJw8CP_dQO-7JO4=eB9NoSBVja-cqvZ-T94KCyrg@mail.gmail.com>
References: <576964F3.3010409@arin.net>
	<FF697443-25E0-4775-AE1B-A0E619AFDFE6@delong.com>
	<782aab88-0c05-4d81-9d42-b6eb0f20693e@quark.net>
	<372DC1BE-372D-45A8-BBA6-9937D978D8EF@delong.com>
	<CAC4yj2U4FkCJw8CP_dQO-7JO4=eB9NoSBVja-cqvZ-T94KCyrg@mail.gmail.com>
Message-ID: <EF501E8D91217774.26E663E0-F426-4B03-9D15-26EBAE813528@mail.outlook.com>

I've tried (to make editorial changes that don't change policy, just simplify it), and couldn't find any that usefully simplified policy with absolutely zero changes. If you are instead suggesting a wholesale duplication of sections 4 and 5 into section 8, as a precursor to simplifying the duplicated text, I wouldn't want to do that as a separate proposal, or we risk ending up with just the duplication and no simplification.?
-Scott

		_____________________________
From: Jason Schiller <jschiller at google.com>
Sent: Saturday, June 25, 2016 5:38 PM
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
To: Owen DeLong <owen at delong.com>
Cc:  <arin-ppml at arin.net>


Would it be beneficial to do a rewrite as Andrew did, but simply make it editorial without changing the intent or implementation of the policy.? Then do a red line for intent changes??
This would enable use to discuss the simplification and re-organization without getting bogged down in disagreement over changes. ?
Once we agree on the non-policy impacting editorial re-write, then we could look at red-line changes, and decide which policy changes have support and which do not. We could then move forward with the changes that are supported, tweak the text a bit, and discuss it in the fall without getting bogged down in discussions about the re-organization.
Andrew, Owen, what do you think?
__Jason?
On Wed, Jun 22, 2016 at 1:30 PM, Owen DeLong <owen at delong.com> wrote:

> On Jun 22, 2016, at 08:46 , Andrew Dul <andrew.dul at quark.net> wrote:
>
> As the primary author of this draft policy, I respectfully disagree with
> my AC colleague.
>
> Now that the free pool has been depleted, it is time to look toward what
> future IPv4 (primarily transfer) policy should do.? While this policy
> looks complicated, its intention is to create a very simple transfer
> policy which allows businesses to predictably and efficiently transfer
> IPv4 resources to meet their requirements.

I don?t disagree with your intent, but I disagree that what you have
proposed achieves that intent.

You are eliminating key safeguards from the transfer policy while simultaneously
changing several of the criteria that have previously applied to transfers of
IPv4 space under section 4.

In addition, there may be unintended effects on the transfer of ASNs.

> I share with you here a redline which shows the changes that would be
> made to section 8.

The redline doesn?t begin to cover it because it does nothing to evaluate how
removing the existing interactions with section 4 compares to existing policy
implementation.

As a result, the redline ends up looking deceptively minor.

Owen

>
> Andrew
>
> On 6/21/2016 9:16 AM, Owen DeLong wrote:
>> I am opposed to this policy proposal.
>>
>> Given that we are now in a world where the only way to obtain IPv4 space is through transfers, I think it makes much more sense to put policy changes for IPv4 transfers into section 4 and retain the simplified text that exists today in section 8 rather than copying most of section 4 into section 8 with revisions in the process.
>>
>> The likely outcome of such an exercise is to create a number of changes which may or may not be fully understood by the community. The interaction of this rewrite with other types of transferable resources (AS numbers at the moment) must also be carefully considered.
>>
>> If we want to change IPv4 policy, then let?s change IPv4 policy in section 4.
>>
>> If we want to change transfer policy for all resources, we can do that cleanly in section 8.
>>
>> While the NRPM may not be a perfect model of a structured document, this proposal would make it significantly worse.
>>
>> Owen
>>
>>> On Jun 21, 2016, at 09:01 , ARIN <info at arin.net> wrote:
>>>
>>> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
>>>
>>> ARIN-prop-230: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>>
>>> This Draft Policy has been numbered and titled:
>>>
>>> Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>>
>>> Draft Policy ARIN-2016-5 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2016_5.html
>>>
>>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). Specifically, these principles are:
>>>
>>>? ? ?> Enabling Fair and Impartial Number Resource Administration
>>>? ? ?> Technically Sound
>>>? ? ?> Supported by the Community
>>>
>>> The 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-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
>>>
>>> Date: 21 June 2016
>>>
>>> Problem Statement
>>>
>>> Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN's inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.
>>>
>>> Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.
>>>
>>> Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.
>>>
>>> The goals of this rewrite are as follows:
>>>
>>>> Separate the criteria that is found in section 4 of the NRPM from the transfer process.
>>>> Provide a clear set of criteria that should be applied across all IPv4 transfers.
>>>> Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
>>>> Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.
>>> Policy statement:
>>>
>>> Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.
>>>
>>> ######
>>>
>>> 8.2. Mergers, Acquisitions, and Reorganizations
>>>
>>> ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:
>>>
>>>> The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
>>>> The new entity must sign an RSA covering all resources to be transferred.
>>>> The resources to be transferred will be subject to ARIN policies.
>>>> The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
>>>> For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.
>>> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.
>>>
>>> 8.3. Transfers between Specified Recipients within the ARIN Region
>>>
>>> In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.
>>>
>>> Conditions on source of the transfer:
>>>
>>>> The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
>>>> The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>>> Conditions on recipient of the transfer:
>>>
>>>> The recipients must meet the transfer requirements as defined in section 8.5.
>>>> The resources transferred will be subject to current ARIN policies.
>>> 8.4. Inter-RIR Transfers to Specified Recipients
>>>
>>> Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.
>>>
>>> Conditions on source of the transfer:
>>>
>>>> The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
>>>> Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
>>>> Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
>>> Conditions on recipient of the transfer:
>>>
>>>> The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
>>>> Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
>>>> Recipients within the ARIN region will be subject to current ARIN policies.
>>> 8.5. Specified Transfer Recipient Requirements
>>>
>>> 8.5.1. Registration Services Agreement
>>>
>>> Transfer recipients must sign an RSA for the resources being received.
>>>
>>> 8.5.2. Operational Use
>>>
>>> ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.
>>>
>>> 8.5.3. Minimum transfer size
>>>
>>> ARIN's minimum transfer size is a /24.
>>>
>>> 8.5.4. Initial block
>>>
>>> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN's minimum transfer size.
>>>
>>> 8.5.5. Block size
>>>
>>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
>>>
>>> 8.5.6. Efficient utilization of previous blocks
>>>
>>> Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.
>>>
>>> Comments:
>>>
>>> Timetable for implementation: immediately
>>>
>>> Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage 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.
>
>
> <Post-IPv4 Free-Pool Depletion Transfer Policy (NRPM 8 redline) - 20160609.pdf>_______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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.


-- 
_______________________________________________________
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/20160626/f12b63f5/attachment.htm>

From bjones at vt.edu  Sun Jun 26 00:03:38 2016
From: bjones at vt.edu (Brian Jones)
Date: Sun, 26 Jun 2016 00:03:38 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-1: Reserved Pool
 Transfer Policy
In-Reply-To: <576967BD.9020400@arin.net>
References: <576967BD.9020400@arin.net>
Message-ID: <CANyqO+E0d_78WRTkEhs-TbM8y-RsVZ2JGUNWA_h+iR65D2ti=w@mail.gmail.com>

I support this proposal as written.
__
Brian Jones
On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Draft
Policy to Recommended Draft Policy status:

ARIN-2016-1: Reserved Pool Transfer Policy

The text of the Recommended Draft Policy is below, and may also be found at:
https://www.arin.net/policy/proposals/2016_1.html

You are encouraged to discuss all Recommended Draft Policies on PPML prior
to their presentation at the next ARIN Public Policy Consultation (PPC).
PPML and PPC discussions are invaluable to the AC when determining
community consensus.

The 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)

Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy

Date: 21 June 2016

AC assessment of conformance with the Principles of Internet Number
Resource Policy:

This proposal enables fair and impartial number resource administration by
ensuring that IPv4 resources, which are specially designated for critical
infrastructure and IPv6 transition, are readily available for many years
into the future. This is done by ensuring the resources remain in their
originally designated pool rather than being moved into the general IPv4
address pool via a transfer.  This proposal is technically sound and is
supported by the community.

Problem Statement:

Section 8 of the current NRPM does not distinguish between the transfer of
blocks from addresses that have been reserved for specific uses and other
addresses that can be transferred. In sections 4.4 and 4.10 there are
specific address blocks set aside, based on the need for critical
infrastructure and IPv6 transitions. Two issues arise if transfers of
reserved address space occur under the current language of section 8.
First, if transfers of 4.4 or 4.10 space occur under the current policy
requirements set forth in sections 8.3 and 8.4, the recipients will be able
to acquire space that was originally reserved for a specific purpose
without ever providing evidence that they will be using the space for
either critical infrastructure or IPv6 transition. Second, if we allow an
allocation or assignment from the block reserved in section 4.10 to be
transferred out of the region, it would complicate the single aggregate
from which providers are being asked to allow in block sizes smaller than a
/24. This policy would limit the transfer of addresses from reserved pools.

Policy statement:

Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
transfer:"

Address resources from a reserved pool (including those designated in
Section 4.4 and 4.10) are not eligible for transfer.

Timetable for implementation: Immediate

##########

ARIN STAFF & LEGAL ASSESSMENT
Draft Policy ARIN-2016-1
RESERVED POOL TRANSFER POLICY
https://www.arin.net/policy/proposals/2016_1.html

Date of Assessment: 13 June 2016
___
1. Summary (Staff Understanding)

This policy would make IPv4 addresses issued under NRPM 4.4 and 4.10
ineligible for transfer inside the NRPM 8.3 and 8.4 transfer policies.
___
2. Comments

A. ARIN Staff Comments

* If this policy is implemented, ARIN staff would not allow NRPM 8.3 and
8.4 transfers to include IPv4 addresses previously issued under NRPM 4.4
and 4.10 policies.

* ARIN staff would continue to allow IPv4 addresses previously issued under
NRPM 4.4 and 4.10 to be included in Merger and Acquisition (NRPM 8.2)
transfers.

* This policy could be implemented as written.

B. ARIN General Counsel ? Legal Assessment

The policy does not create a material legal issue. It should be noted that
ARIN does permit transfers of IPV4 resources pursuant to 8.3 and 8.4. This
policy is an exception to that transferability and is consistent with the
intent and of the policy by which these allocations were made.
___
3. Resource Impact

Implementation of this policy would have minimal resource impact. It is
estimated that implementation would occur within 3 months after
ratification by the ARIN Board of Trustees. The following would be needed
in order to implement:

* Updated guidelines and internal procedures

* Staff training
___
4. Proposal / Draft Policy Text Assessed

Draft Policy ARIN-2016-1
Reserved Pool Transfer Policy

Date: 22 March 2016

Problem Statement:

Section 8 of the current NRPM does not distinguish between the transfer of
blocks from addresses that have been reserved for specific uses and other
addresses that can be transferred. In sections 4.4 and 4.10 there are
specific address blocks set aside, based on the need for critical
infrastructure and IPv6 transitions. Two issues arise if transfers of
reserved address space occur under the current language of section 8.
First, if transfers of 4.4 or 4.10 space occur under the current policy
requirements set forth in sections 8.3 and 8.4, the recipients will be able
to acquire space that was originally reserved for a specific purpose
without ever providing evidence that they will be using the space for
either critical infrastructure or IPv6 transition. Second, if we allow an
allocation or assignment from the block reserved in section 4.10 to be
transferred out of the region, it would complicate the single aggregate
from which providers are being asked to allow in block sizes smaller than a
/24. This policy would limit the transfer of addresses from reserved pools.

Policy statement:

Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
transfer:"

Address resources from a reserved pool (including those designated in
Section 4.4 and 4.10) are not eligible for transfer.

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

From jrl at lodden.com  Mon Jun 27 04:02:49 2016
From: jrl at lodden.com (jrl at lodden.com)
Date: Mon, 27 Jun 2016 11:02:49 +0300
Subject: [arin-ppml] (no subject)
Message-ID: <0000fc934d4f$6fb90235$d5a53b80$@lodden.com>



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

From cspears.lists at gmail.com  Mon Jun 27 11:24:20 2016
From: cspears.lists at gmail.com (Chris Spears)
Date: Mon, 27 Jun 2016 11:24:20 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-1: Reserved Pool
 Transfer Policy
In-Reply-To: <576967BD.9020400@arin.net>
References: <576967BD.9020400@arin.net>
Message-ID: <CA+b8Ukv30RC0NeP8efdzwYrLBK62X6O_QzEEEmQaBO24LwUbCw@mail.gmail.com>

I support this proposal as written.

On Tue, Jun 21, 2016 at 12:13 PM, ARIN <info at arin.net> wrote:
> On 16 June 2016 the ARIN Advisory Council (AC) advanced the following Draft
> Policy to Recommended Draft Policy status:
>
> ARIN-2016-1: Reserved Pool Transfer Policy
>
> The text of the Recommended Draft Policy is below, and may also be found at:
> https://www.arin.net/policy/proposals/2016_1.html
>
> You are encouraged to discuss all Recommended Draft Policies on PPML prior
> to their presentation at the next ARIN Public Policy Consultation (PPC).
> PPML and PPC discussions are invaluable to the AC when determining community
> consensus.
>
> The 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)
>
> Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
>
> Date: 21 June 2016
>
> AC assessment of conformance with the Principles of Internet Number Resource
> Policy:
>
> This proposal enables fair and impartial number resource administration by
> ensuring that IPv4 resources, which are specially designated for critical
> infrastructure and IPv6 transition, are readily available for many years
> into the future. This is done by ensuring the resources remain in their
> originally designated pool rather than being moved into the general IPv4
> address pool via a transfer.  This proposal is technically sound and is
> supported by the community.
>
> Problem Statement:
>
> Section 8 of the current NRPM does not distinguish between the transfer of
> blocks from addresses that have been reserved for specific uses and other
> addresses that can be transferred. In sections 4.4 and 4.10 there are
> specific address blocks set aside, based on the need for critical
> infrastructure and IPv6 transitions. Two issues arise if transfers of
> reserved address space occur under the current language of section 8. First,
> if transfers of 4.4 or 4.10 space occur under the current policy
> requirements set forth in sections 8.3 and 8.4, the recipients will be able
> to acquire space that was originally reserved for a specific purpose without
> ever providing evidence that they will be using the space for either
> critical infrastructure or IPv6 transition. Second, if we allow an
> allocation or assignment from the block reserved in section 4.10 to be
> transferred out of the region, it would complicate the single aggregate from
> which providers are being asked to allow in block sizes smaller than a /24.
> This policy would limit the transfer of addresses from reserved pools.
>
> Policy statement:
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> Timetable for implementation: Immediate
>
> ##########
>
> ARIN STAFF & LEGAL ASSESSMENT
> Draft Policy ARIN-2016-1
> RESERVED POOL TRANSFER POLICY
> https://www.arin.net/policy/proposals/2016_1.html
>
> Date of Assessment: 13 June 2016
> ___
> 1. Summary (Staff Understanding)
>
> This policy would make IPv4 addresses issued under NRPM 4.4 and 4.10
> ineligible for transfer inside the NRPM 8.3 and 8.4 transfer policies.
> ___
> 2. Comments
>
> A. ARIN Staff Comments
>
> * If this policy is implemented, ARIN staff would not allow NRPM 8.3 and 8.4
> transfers to include IPv4 addresses previously issued under NRPM 4.4 and
> 4.10 policies.
>
> * ARIN staff would continue to allow IPv4 addresses previously issued under
> NRPM 4.4 and 4.10 to be included in Merger and Acquisition (NRPM 8.2)
> transfers.
>
> * This policy could be implemented as written.
>
> B. ARIN General Counsel ? Legal Assessment
>
> The policy does not create a material legal issue. It should be noted that
> ARIN does permit transfers of IPV4 resources pursuant to 8.3 and 8.4. This
> policy is an exception to that transferability and is consistent with the
> intent and of the policy by which these allocations were made.
> ___
> 3. Resource Impact
>
> Implementation of this policy would have minimal resource impact. It is
> estimated that implementation would occur within 3 months after ratification
> by the ARIN Board of Trustees. The following would be needed in order to
> implement:
>
> * Updated guidelines and internal procedures
>
> * Staff training
> ___
> 4. Proposal / Draft Policy Text Assessed
>
> Draft Policy ARIN-2016-1
> Reserved Pool Transfer Policy
>
> Date: 22 March 2016
>
> Problem Statement:
>
> Section 8 of the current NRPM does not distinguish between the transfer of
> blocks from addresses that have been reserved for specific uses and other
> addresses that can be transferred. In sections 4.4 and 4.10 there are
> specific address blocks set aside, based on the need for critical
> infrastructure and IPv6 transitions. Two issues arise if transfers of
> reserved address space occur under the current language of section 8. First,
> if transfers of 4.4 or 4.10 space occur under the current policy
> requirements set forth in sections 8.3 and 8.4, the recipients will be able
> to acquire space that was originally reserved for a specific purpose without
> ever providing evidence that they will be using the space for either
> critical infrastructure or IPv6 transition. Second, if we allow an
> allocation or assignment from the block reserved in section 4.10 to be
> transferred out of the region, it would complicate the single aggregate from
> which providers are being asked to allow in block sizes smaller than a /24.
> This policy would limit the transfer of addresses from reserved pools.
>
> Policy statement:
>
> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> transfer:"
>
> Address resources from a reserved pool (including those designated in
> Section 4.4 and 4.10) are not eligible for transfer.
>
> Timetable for implementation: Immediate
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From hvgeekwtrvl at gmail.com  Tue Jun 28 21:12:02 2016
From: hvgeekwtrvl at gmail.com (james machado)
Date: Tue, 28 Jun 2016 18:12:02 -0700
Subject: [arin-ppml] Recommended Draft Policy ARIN-2016-1: Reserved Pool
 Transfer Policy
In-Reply-To: <CA+b8Ukv30RC0NeP8efdzwYrLBK62X6O_QzEEEmQaBO24LwUbCw@mail.gmail.com>
References: <576967BD.9020400@arin.net>
	<CA+b8Ukv30RC0NeP8efdzwYrLBK62X6O_QzEEEmQaBO24LwUbCw@mail.gmail.com>
Message-ID: <CADVasu4JAHdOX1SPQ5z-enLK0LzW22B0XcS4xBYxu6KbsgkX2A@mail.gmail.com>

I support this proposal as written.

James

On Mon, Jun 27, 2016 at 8:24 AM, Chris Spears <cspears.lists at gmail.com>
wrote:

> I support this proposal as written.
>
> On Tue, Jun 21, 2016 at 12:13 PM, ARIN <info at arin.net> wrote:
> > On 16 June 2016 the ARIN Advisory Council (AC) advanced the following
> Draft
> > Policy to Recommended Draft Policy status:
> >
> > ARIN-2016-1: Reserved Pool Transfer Policy
> >
> > The text of the Recommended Draft Policy is below, and may also be found
> at:
> > https://www.arin.net/policy/proposals/2016_1.html
> >
> > You are encouraged to discuss all Recommended Draft Policies on PPML
> prior
> > to their presentation at the next ARIN Public Policy Consultation (PPC).
> > PPML and PPC discussions are invaluable to the AC when determining
> community
> > consensus.
> >
> > The 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)
> >
> > Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
> >
> > Date: 21 June 2016
> >
> > AC assessment of conformance with the Principles of Internet Number
> Resource
> > Policy:
> >
> > This proposal enables fair and impartial number resource administration
> by
> > ensuring that IPv4 resources, which are specially designated for critical
> > infrastructure and IPv6 transition, are readily available for many years
> > into the future. This is done by ensuring the resources remain in their
> > originally designated pool rather than being moved into the general IPv4
> > address pool via a transfer.  This proposal is technically sound and is
> > supported by the community.
> >
> > Problem Statement:
> >
> > Section 8 of the current NRPM does not distinguish between the transfer
> of
> > blocks from addresses that have been reserved for specific uses and other
> > addresses that can be transferred. In sections 4.4 and 4.10 there are
> > specific address blocks set aside, based on the need for critical
> > infrastructure and IPv6 transitions. Two issues arise if transfers of
> > reserved address space occur under the current language of section 8.
> First,
> > if transfers of 4.4 or 4.10 space occur under the current policy
> > requirements set forth in sections 8.3 and 8.4, the recipients will be
> able
> > to acquire space that was originally reserved for a specific purpose
> without
> > ever providing evidence that they will be using the space for either
> > critical infrastructure or IPv6 transition. Second, if we allow an
> > allocation or assignment from the block reserved in section 4.10 to be
> > transferred out of the region, it would complicate the single aggregate
> from
> > which providers are being asked to allow in block sizes smaller than a
> /24.
> > This policy would limit the transfer of addresses from reserved pools.
> >
> > Policy statement:
> >
> > Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> > transfer:"
> >
> > Address resources from a reserved pool (including those designated in
> > Section 4.4 and 4.10) are not eligible for transfer.
> >
> > Timetable for implementation: Immediate
> >
> > ##########
> >
> > ARIN STAFF & LEGAL ASSESSMENT
> > Draft Policy ARIN-2016-1
> > RESERVED POOL TRANSFER POLICY
> > https://www.arin.net/policy/proposals/2016_1.html
> >
> > Date of Assessment: 13 June 2016
> > ___
> > 1. Summary (Staff Understanding)
> >
> > This policy would make IPv4 addresses issued under NRPM 4.4 and 4.10
> > ineligible for transfer inside the NRPM 8.3 and 8.4 transfer policies.
> > ___
> > 2. Comments
> >
> > A. ARIN Staff Comments
> >
> > * If this policy is implemented, ARIN staff would not allow NRPM 8.3 and
> 8.4
> > transfers to include IPv4 addresses previously issued under NRPM 4.4 and
> > 4.10 policies.
> >
> > * ARIN staff would continue to allow IPv4 addresses previously issued
> under
> > NRPM 4.4 and 4.10 to be included in Merger and Acquisition (NRPM 8.2)
> > transfers.
> >
> > * This policy could be implemented as written.
> >
> > B. ARIN General Counsel ? Legal Assessment
> >
> > The policy does not create a material legal issue. It should be noted
> that
> > ARIN does permit transfers of IPV4 resources pursuant to 8.3 and 8.4.
> This
> > policy is an exception to that transferability and is consistent with the
> > intent and of the policy by which these allocations were made.
> > ___
> > 3. Resource Impact
> >
> > Implementation of this policy would have minimal resource impact. It is
> > estimated that implementation would occur within 3 months after
> ratification
> > by the ARIN Board of Trustees. The following would be needed in order to
> > implement:
> >
> > * Updated guidelines and internal procedures
> >
> > * Staff training
> > ___
> > 4. Proposal / Draft Policy Text Assessed
> >
> > Draft Policy ARIN-2016-1
> > Reserved Pool Transfer Policy
> >
> > Date: 22 March 2016
> >
> > Problem Statement:
> >
> > Section 8 of the current NRPM does not distinguish between the transfer
> of
> > blocks from addresses that have been reserved for specific uses and other
> > addresses that can be transferred. In sections 4.4 and 4.10 there are
> > specific address blocks set aside, based on the need for critical
> > infrastructure and IPv6 transitions. Two issues arise if transfers of
> > reserved address space occur under the current language of section 8.
> First,
> > if transfers of 4.4 or 4.10 space occur under the current policy
> > requirements set forth in sections 8.3 and 8.4, the recipients will be
> able
> > to acquire space that was originally reserved for a specific purpose
> without
> > ever providing evidence that they will be using the space for either
> > critical infrastructure or IPv6 transition. Second, if we allow an
> > allocation or assignment from the block reserved in section 4.10 to be
> > transferred out of the region, it would complicate the single aggregate
> from
> > which providers are being asked to allow in block sizes smaller than a
> /24.
> > This policy would limit the transfer of addresses from reserved pools.
> >
> > Policy statement:
> >
> > Add to Section 8.3 and Section 8.4 under the "Conditions on source of the
> > transfer:"
> >
> > Address resources from a reserved pool (including those designated in
> > Section 4.4 and 4.10) are not eligible for transfer.
> >
> > Timetable for implementation: Immediate
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160628/648e32e2/attachment.htm>