From owen at delong.com  Thu Jan  5 15:46:48 2017
From: owen at delong.com (Owen DeLong)
Date: Thu, 5 Jan 2017 12:46:48 -0800
Subject: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
 Validation Requirement
In-Reply-To: <585973ED.9090606@arin.net>
References: <585973ED.9090606@arin.net>
Message-ID: <B6C52ED2-1AC4-4B0F-8EDA-8ED31012A36E@delong.com>

I oppose the policy as written.

While I agree that the validation of indirect POCs by ARIN has become a problem, I believe that this is the exact opposite of a good solution.

Indeed, my organization has a significant problem with vendors creating indirect POC records pointing to individuals within my organization who are not good POCs for the space in question rather than using our existing POC handles which we have provided to those vendors.

The current POC validation process is one of the few checks and balances which allows us to catch and address these issues.

Ideally, we would like to have a way for ARIN to flag and validate new POCs pointed at our organization _BEFORE_ they are actually placed into the database or attached to resources.

Owen

> On Dec 20, 2016, at 10:09 , ARIN <info at arin.net> wrote:
> 
> On 15 December 2016, the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
> 
> ARIN-prop-233: Removal of Indirect POC Validation Requirement
> 
> This Draft Policy has been numbered and titled:
> 
> Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement
> 
> Draft Policy text is below and can be found at:
> https://www.arin.net/policy/proposals/2016_8.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,
> 
> Sean Hopkins
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
> 
> ##########
> 
> ARIN-2016-8: Removal of Indirect POC Validation Requirement
> 
> Problem Statement:
> 
> There are over 600,000 POCs registered in Whois that are only associated with indirect assignments (reassignments) and indirect allocations (reallocations). NRPM 3.6 requires ARIN to contact all 600,000+ of these every year to validate the POC information. This is problematic for a few reasons:
> 
> 1) ARIN does not have a business relationships with these POCs. By conducting POC validation via email, ARIN is sending Unsolicited Commercial Emails. Further, because of NRPM 3.6.1, ARIN cannot offer an opt-out mechanism. Finally, ARIN's resultant listing on anti-spam lists causes unacceptable damage to ARIN's ability to conduct ordinary business over email
> 
> 2) ARIN has previously reported that POC validation to reassignments causes tremendous work for the staff. It receives many angry phone calls and emails about the POC validation process. I believe the ARIN staff should be focused on POC validation efforts for directly issued resources, as that has more value to internet operations and law enforcement than end-user POC information.
> 
> Policy statement:
> 
> Replace the first sentence of 3.6.1:
> 
> "During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database."
> 
> with
> 
> "During ARIN's annual Whois POC validation, an email will be sent to every POC that is a contact for a direct assignment, direct allocation, reallocation, and AS number, and their associated OrgIDs."
> 
> 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 info at arin.net  Thu Jan  5 16:24:13 2017
From: info at arin.net (ARIN)
Date: Thu, 5 Jan 2017 16:24:13 -0500
Subject: [arin-ppml] ARIN Board Adopts New Policies
Message-ID: <586EB97D.8030207@arin.net>

On 19 December 2016, the Board of Trustees adopted the following 
Recommended Draft Policies:

ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
ARIN-2016-1: Reserved Pool Transfer Policy
ARIN-2016-2: Change timeframes for IPv4 requests to 24 months
ARIN-2016-4: Transfers for new entrants
ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
ARIN-2016-6: Eliminate HD-Ratio from NRPM

ARIN-2016-2 and ARIN-2016-4 will be implemented no later than 19 June 
2017, in accordance with their Staff and Legal Reviews, which rated the 
policies' resource impacts as moderate.

The remaining adopted policies will be implemented no later than 19 
March 2017, in accordance with their Staff and Legal Reviews, which 
rated the policies' resource impacts as minimal.

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,

Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)


From narten at us.ibm.com  Fri Jan  6 00:53:33 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 06 Jan 2017 00:53:33 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201701060553.v065rX5n014209@rotala.raleigh.ibm.com>

Total of 3 messages in the last 7 days.
 
script run at: Fri Jan  6 00:53:28 EST 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |    1 | 38.73% |     9376 | owen at delong.com
 33.33% |    1 | 34.94% |     8458 | narten at us.ibm.com
 33.33% |    1 | 26.33% |     6374 | info at arin.net
--------+------+--------+----------+------------------------
100.00% |    3 |100.00% |    24208 | Total



From ppml at rsuc.gweep.net  Fri Jan  6 09:38:13 2017
From: ppml at rsuc.gweep.net (Joe Provo)
Date: Fri, 6 Jan 2017 09:38:13 -0500
Subject: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
 Validation Requirement
In-Reply-To: <B6C52ED2-1AC4-4B0F-8EDA-8ED31012A36E@delong.com>
References: <585973ED.9090606@arin.net>
 <B6C52ED2-1AC4-4B0F-8EDA-8ED31012A36E@delong.com>
Message-ID: <20170106143813.GA53396@gweep.net>

On Thu, Jan 05, 2017 at 12:46:48PM -0800, Owen DeLong wrote:
> I oppose the policy as written.
> 
> While I agree that the validation of indirect POCs by ARIN has
> become a problem, I believe that this is the exact opposite of a
> good solution.
> 
> Indeed, my organization has a significant problem with vendors
> creating indirect POC records pointing to individuals within my
> organization who are not good POCs for the space in question rather
> than using our existing POC handles which we have provided to those
> vendors.

I've observed this same problem across multiple organizations. 
I agree with Owen that correcting the problem rather than punting 
on it is the correct direction.

Cheers,

Joe

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 


From chris at semihuman.com  Fri Jan  6 12:58:12 2017
From: chris at semihuman.com (Chris Woodfield)
Date: Fri, 6 Jan 2017 09:58:12 -0800
Subject: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
 Validation Requirement
In-Reply-To: <B6C52ED2-1AC4-4B0F-8EDA-8ED31012A36E@delong.com>
References: <585973ED.9090606@arin.net>
 <B6C52ED2-1AC4-4B0F-8EDA-8ED31012A36E@delong.com>
Message-ID: <44BCDCD7-5449-443B-9F97-C57B871161F2@semihuman.com>

Is the presence of the phrase ?will be sent? in the current policy intended to set a requirement for the POC (this email will be sent annually, you must reply to it in order to validate the record), or intended as a requirement for ARIN staff (ARIN is required to send the email annually)?

To the concept of the random audit approach mentioned earlier, It may be simple enough to change ?will be sent? to ?may be sent?. I?d argue that procedurally the sampling rate should be fairly high, however (i.e. no less than, say, 20% of records).

-C

> On Jan 5, 2017, at 12:46 PM, Owen DeLong <owen at delong.com> wrote:
> 
> I oppose the policy as written.
> 
> While I agree that the validation of indirect POCs by ARIN has become a problem, I believe that this is the exact opposite of a good solution.
> 
> Indeed, my organization has a significant problem with vendors creating indirect POC records pointing to individuals within my organization who are not good POCs for the space in question rather than using our existing POC handles which we have provided to those vendors.
> 
> The current POC validation process is one of the few checks and balances which allows us to catch and address these issues.
> 

P.S. Personally, I?d argue that a viable alternate strategy in the absence of that check/balance would be to make sure that the requirement to use your official POCs is written into your vendor contracts at next renewal, and operationally onto a service acceptance checklist backed up by said contract language.

> Ideally, we would like to have a way for ARIN to flag and validate new POCs pointed at our organization _BEFORE_ they are actually placed into the database or attached to resources.
> 
> Owen
> 
>> On Dec 20, 2016, at 10:09 , ARIN <info at arin.net> wrote:
>> 
>> On 15 December 2016, the ARIN Advisory Council (AC) advanced the following Proposal to Draft Policy status:
>> 
>> ARIN-prop-233: Removal of Indirect POC Validation Requirement
>> 
>> This Draft Policy has been numbered and titled:
>> 
>> Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement
>> 
>> Draft Policy text is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_8.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,
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> ##########
>> 
>> ARIN-2016-8: Removal of Indirect POC Validation Requirement
>> 
>> Problem Statement:
>> 
>> There are over 600,000 POCs registered in Whois that are only associated with indirect assignments (reassignments) and indirect allocations (reallocations). NRPM 3.6 requires ARIN to contact all 600,000+ of these every year to validate the POC information. This is problematic for a few reasons:
>> 
>> 1) ARIN does not have a business relationships with these POCs. By conducting POC validation via email, ARIN is sending Unsolicited Commercial Emails. Further, because of NRPM 3.6.1, ARIN cannot offer an opt-out mechanism. Finally, ARIN's resultant listing on anti-spam lists causes unacceptable damage to ARIN's ability to conduct ordinary business over email
>> 
>> 2) ARIN has previously reported that POC validation to reassignments causes tremendous work for the staff. It receives many angry phone calls and emails about the POC validation process. I believe the ARIN staff should be focused on POC validation efforts for directly issued resources, as that has more value to internet operations and law enforcement than end-user POC information.
>> 
>> Policy statement:
>> 
>> Replace the first sentence of 3.6.1:
>> 
>> "During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database."
>> 
>> with
>> 
>> "During ARIN's annual Whois POC validation, an email will be sent to every POC that is a contact for a direct assignment, direct allocation, reallocation, and AS number, and their associated OrgIDs."
>> 
>> Timetable for implementation: Immediate
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 



From info at arin.net  Thu Jan 12 14:17:18 2017
From: info at arin.net (ARIN)
Date: Thu, 12 Jan 2017 14:17:18 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
Message-ID: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>

To PPML -

As a result of policy discussions in the AFRINIC region, ARIN is
providing the following to information:

On 30 September 2016 ARIN received a query from AFRINIC requesting an
assessment on the compatibility of AFRINIC proposed
1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
responded with the following assessment:

Based on ARIN?s Number Resource Policy Manual, Version 2016.2 ? 13 July
2016, and referencing the following text from paragraph 8.4. Inter-RIR
Transfers to Specified Recipients, we have determined that the proposed
AFRINIC Inbound Transfer Policy is not reciprocal.

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

In this case reciprocal meaning that the policy provides both RIRs the
same ability to transfer: both in and out. This policy proposal as
written could not be implemented by ARIN. Note that ARIN?s Inter-RIR
transfer policy is based on other RIR's transfer policy and does not
consider any LIR or NIR policies.

Regards,

John Sweeting
Sr. Director, RSD
American Registry for Internet Numbers (ARIN)





From narten at us.ibm.com  Fri Jan 13 00:53:23 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 13 Jan 2017 00:53:23 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201701130553.v0D5rN8s018352@rotala.raleigh.ibm.com>

Total of 4 messages in the last 7 days.
 
script run at: Fri Jan 13 00:53:18 EST 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 25.00% |    1 | 33.84% |    11000 | chris at semihuman.com
 25.00% |    1 | 26.19% |     8514 | narten at us.ibm.com
 25.00% |    1 | 20.31% |     6603 | info at arin.net
 25.00% |    1 | 19.66% |     6391 | ppml at rsuc.gweep.net
--------+------+--------+----------+------------------------
100.00% |    4 |100.00% |    32508 | Total



From farmer at umn.edu  Tue Jan 17 14:42:11 2017
From: farmer at umn.edu (David Farmer)
Date: Tue, 17 Jan 2017 13:42:11 -0600
Subject: [arin-ppml] Draft Policy 2016-7 -- Integrate community networks
 into Existing ISP Policy
In-Reply-To: <5eeb6493-7fd6-5f55-e47a-4294bd739771@quark.net>
References: <E71D08A9-DAB5-49DF-B15C-B001EE02C857@delong.com>
 <7E7773B523E82C478734E793E58F69E78E422684@SBS2011.thewireinc.local>
 <5eeb6493-7fd6-5f55-e47a-4294bd739771@quark.net>
Message-ID: <CAN-Dau0kCCNxDvCTZgwudnzLN3Yt2o-xu6gMYcb0Dc5igWRU5Q@mail.gmail.com>

It concerns me that no one that operates a community network has commented
on this policy.  Further it concerns me that no one from the general ARIN
policy community commented either, only AC members and a former AC member
who is also the policy author have made any comments.

Is there interest from the ARIN policy community to work on this or are
their other priorities for the community's time?

It would be helpful to hear from others in regards to if this is something
we should be working on or not.

Thanks.

On Sun, Dec 18, 2016 at 2:58 PM, Andrew Dul <andrew.dul at quark.net> wrote:

> It would be especially helpful for the AC if those who operate community
> networks could review the proposed draft policy and see if the problem
> statement highlights an issue for operators and if the proposed text solves
> this problem.
>
> Thanks,
> Andrew
>
>
>
> On 12/15/2016 3:30 PM, Kevin Blumberg wrote:
>
> Owen,
>
> As the author of 2016-7 I disagree.
>
> The change in 2016-6 had no meaningful impact to the usefulness of Community
> Networks. T
>
> The purpose of 2016-7 was to significantly reduce the red tape requirements
> with Community Networks.
>
> I believe that without this kind of policy Community Network's will never
> get used given the onerous requirements.
>
> Thanks,
>
> Kevin Blumberg
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>] On Behalf Of Owen DeLong
> Sent: Thursday, December 15, 2016 4:19 PM
> To: ARIN-PPML List <arin-ppml at arin.net> <arin-ppml at arin.net>
> Subject: [arin-ppml] Draft Policy 2016-7 -- Integrate community networks
> into Existing ISP Policy
>
> I believe that this proposal no longer has relevance given the advancement
> of 2016-6 and its rewrite of the community networks policy to the board.
>
> If anyone feels that the AC should not abandon this proposal at their
> January meeting, please speak up.
>
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public
> Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170117/1d53d82b/attachment.htm>

From daveid at panix.com  Thu Jan 19 15:36:54 2017
From: daveid at panix.com (David R Huberman)
Date: Thu, 19 Jan 2017 15:36:54 -0500 (EST)
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
Message-ID: <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>


Last week, ARIN staff sent to this list a copy of their response to 
AFRINIC on inter-RIR transfer policy compatability.

The AFRINIC community is considering a one-way transfer policy as a 
bootstrap for the few years until they reach IPv4 runout, at which point 
it would aim to become two-way.

I feel like as a member of the internet community, that ARIN (we - us - 
the PPML participants) should be accepting that an RIR in a different 
region has different needs than we do. I think we should allow African 
internet operators to obtain blocks from sellers in the ARIN region, and 
transfer them to AFRINIC to meet their needs.

The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis, 
and the language looks very similar to 8.2 and 8.3 language we've had at 
ARIN for a very long time.

cf.

http://www.afrinic.net/en/community/policy-development/policy-proposals/1803-inbound-transfer-policy

That's my opinion.  What's yours?

Thanks,
David


On Thu, 12 Jan 2017, ARIN wrote:

> To PPML -
>
> As a result of policy discussions in the AFRINIC region, ARIN is
> providing the following to information:
>
> On 30 September 2016 ARIN received a query from AFRINIC requesting an
> assessment on the compatibility of AFRINIC proposed
> 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
> responded with the following assessment:
>
> Based on ARIN???s Number Resource Policy Manual, Version 2016.2 ??? 13 July
> 2016, and referencing the following text from paragraph 8.4. Inter-RIR
> Transfers to Specified Recipients, we have determined that the proposed
> AFRINIC Inbound Transfer Policy is not reciprocal.
>
> ???Inter-regional transfers may take place only via RIRs who agree to the
> transfer and share reciprocal, compatible, needs-based policies.???
>
> In this case reciprocal meaning that the policy provides both RIRs the
> same ability to transfer: both in and out. This policy proposal as
> written could not be implemented by ARIN. Note that ARIN???s Inter-RIR
> transfer policy is based on other RIR's transfer policy and does not
> consider any LIR or NIR policies.
>
> Regards,
>
> John Sweeting
> Sr. Director, RSD
> American Registry for Internet Numbers (ARIN)
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

From mike at iptrading.com  Thu Jan 19 16:02:23 2017
From: mike at iptrading.com (Mike Burns)
Date: Thu, 19 Jan 2017 16:02:23 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
Message-ID: <047401d27297$551a97c0$ff4fc740$@iptrading.com>

Hi David,

An inbound-only policy is also under development at LACNIC and will hit the
discussion list there next week.

RIPE has officially said they will accept the provisions of the AFRINIC
inbound policy and will send RIPE addresses to AFRINIC should the AFRINIC
policy be implemented as written.

RIPE has told me they will treat any pending LACNIC policy the same way, if
the operative language is similar.

LACNIC also has a relatively rigorous needs-test for transfers, AFAIK they
even require the use of NAT.

I think the ARIN community must take notice of the relative superabundance
of IPv4 space in the region and how less address-rich regions must feel in
this age of exhaust.

The recent IPv4 market analysis at RIPE indicates that the transfer market
is fueled to a large extent by legacy address acting as supply. These legacy
addresses are again much more abundant in ARIN than they are in AFRINIC or
LACNIC. 

My personal experience is that the LACNIC transfer market is suffering from
a lack of supply, and buyers are being asked to pay higher prices due to
scarcity. I believe that it is in the best interests of the Internet for
there to be a global market in IPv4 addresses. Unfortunately the
address-poor regions feel shortchanged, and they view any two-way policy as
a potential to lose some of their paltry amount to richer regions.

As a half-way step towards a truly global market, accepting that some
regions (and some NIRs) will not allow outbound transfers today, I believe
ARIN should join RIPE and remove the language about reciprocity, while
maintaining the requirement for compatible needs testing.

Regards,
Mike Burns





-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David R
Huberman
Sent: Thursday, January 19, 2017 3:37 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility


Last week, ARIN staff sent to this list a copy of their response to AFRINIC
on inter-RIR transfer policy compatability.

The AFRINIC community is considering a one-way transfer policy as a
bootstrap for the few years until they reach IPv4 runout, at which point it
would aim to become two-way.

I feel like as a member of the internet community, that ARIN (we - us - the
PPML participants) should be accepting that an RIR in a different region has
different needs than we do. I think we should allow African internet
operators to obtain blocks from sellers in the ARIN region, and transfer
them to AFRINIC to meet their needs.

The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis, and
the language looks very similar to 8.2 and 8.3 language we've had at ARIN
for a very long time.

cf.

http://www.afrinic.net/en/community/policy-development/policy-proposals/1803
-inbound-transfer-policy

That's my opinion.  What's yours?

Thanks,
David


On Thu, 12 Jan 2017, ARIN wrote:

> To PPML -
>
> As a result of policy discussions in the AFRINIC region, ARIN is 
> providing the following to information:
>
> On 30 September 2016 ARIN received a query from AFRINIC requesting an 
> assessment on the compatibility of AFRINIC proposed 
> 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN 
> responded with the following assessment:
>
> Based on ARINb



From scottleibrand at gmail.com  Thu Jan 19 16:13:59 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 19 Jan 2017 13:13:59 -0800
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <047401d27297$551a97c0$ff4fc740$@iptrading.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
Message-ID: <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>

I would agree with this, and would support a policy proposal to remove the
"reciprocal" requirement in ARIN inter-RIR transfer policy, leaving
the "compatible,
needs-based" requirement.

It looks like this would simply be a one-word change, removing
"reciprocal," from the first sentence of 8.4.

-Scott

On Thu, Jan 19, 2017 at 1:02 PM, Mike Burns <mike at iptrading.com> wrote:

> Hi David,
>
> An inbound-only policy is also under development at LACNIC and will hit the
> discussion list there next week.
>
> RIPE has officially said they will accept the provisions of the AFRINIC
> inbound policy and will send RIPE addresses to AFRINIC should the AFRINIC
> policy be implemented as written.
>
> RIPE has told me they will treat any pending LACNIC policy the same way, if
> the operative language is similar.
>
> LACNIC also has a relatively rigorous needs-test for transfers, AFAIK they
> even require the use of NAT.
>
> I think the ARIN community must take notice of the relative superabundance
> of IPv4 space in the region and how less address-rich regions must feel in
> this age of exhaust.
>
> The recent IPv4 market analysis at RIPE indicates that the transfer market
> is fueled to a large extent by legacy address acting as supply. These
> legacy
> addresses are again much more abundant in ARIN than they are in AFRINIC or
> LACNIC.
>
> My personal experience is that the LACNIC transfer market is suffering from
> a lack of supply, and buyers are being asked to pay higher prices due to
> scarcity. I believe that it is in the best interests of the Internet for
> there to be a global market in IPv4 addresses. Unfortunately the
> address-poor regions feel shortchanged, and they view any two-way policy as
> a potential to lose some of their paltry amount to richer regions.
>
> As a half-way step towards a truly global market, accepting that some
> regions (and some NIRs) will not allow outbound transfers today, I believe
> ARIN should join RIPE and remove the language about reciprocity, while
> maintaining the requirement for compatible needs testing.
>
> Regards,
> Mike Burns
>
>
>
>
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David R
> Huberman
> Sent: Thursday, January 19, 2017 3:37 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
>
>
> Last week, ARIN staff sent to this list a copy of their response to AFRINIC
> on inter-RIR transfer policy compatability.
>
> The AFRINIC community is considering a one-way transfer policy as a
> bootstrap for the few years until they reach IPv4 runout, at which point it
> would aim to become two-way.
>
> I feel like as a member of the internet community, that ARIN (we - us - the
> PPML participants) should be accepting that an RIR in a different region
> has
> different needs than we do. I think we should allow African internet
> operators to obtain blocks from sellers in the ARIN region, and transfer
> them to AFRINIC to meet their needs.
>
> The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis,
> and
> the language looks very similar to 8.2 and 8.3 language we've had at ARIN
> for a very long time.
>
> cf.
>
> http://www.afrinic.net/en/community/policy-development/
> policy-proposals/1803
> -inbound-transfer-policy
>
> That's my opinion.  What's yours?
>
> Thanks,
> David
>
>
> On Thu, 12 Jan 2017, ARIN wrote:
>
> > To PPML -
> >
> > As a result of policy discussions in the AFRINIC region, ARIN is
> > providing the following to information:
> >
> > On 30 September 2016 ARIN received a query from AFRINIC requesting an
> > assessment on the compatibility of AFRINIC proposed
> > 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
> > responded with the following assessment:
> >
> > Based on ARINb
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20170119/3ac65219/attachment.htm>

From matthew at matthew.at  Thu Jan 19 16:23:11 2017
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 19 Jan 2017 21:23:11 +0000
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
Message-ID: <CAPcE_Lf+NfE_bc+3JSUsKrt1c-XHRZkxfpd96-=C+H+tbGvzdw@mail.gmail.com>

I think North America should be fine with sending their outdated* IPv4
addresses to Africa. They'll go well with the secondhand CFC-containing
refrigerators, mountains of e-waste, and everything else that is no longer
useful here that we insist on sending them. For consistency, we should
probably transfer over at least some of the addresses against their wishes.

Matthew Kaufman

*IPv6 has been specified for around 18 years, give or take, so I presume
we've all switched over by now.

On Thu, Jan 19, 2017 at 12:38 PM David R Huberman <daveid at panix.com> wrote:

>
> Last week, ARIN staff sent to this list a copy of their response to
> AFRINIC on inter-RIR transfer policy compatability.
>
> The AFRINIC community is considering a one-way transfer policy as a
> bootstrap for the few years until they reach IPv4 runout, at which point
> it would aim to become two-way.
>
> I feel like as a member of the internet community, that ARIN (we - us -
> the PPML participants) should be accepting that an RIR in a different
> region has different needs than we do. I think we should allow African
> internet operators to obtain blocks from sellers in the ARIN region, and
> transfer them to AFRINIC to meet their needs.
>
> The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis,
> and the language looks very similar to 8.2 and 8.3 language we've had at
> ARIN for a very long time.
>
> cf.
>
>
> http://www.afrinic.net/en/community/policy-development/policy-proposals/1803-inbound-transfer-policy
>
> That's my opinion.  What's yours?
>
> Thanks,
> David
>
>
> On Thu, 12 Jan 2017, ARIN wrote:
>
> > To PPML -
> >
> > As a result of policy discussions in the AFRINIC region, ARIN is
> > providing the following to information:
> >
> > On 30 September 2016 ARIN received a query from AFRINIC requesting an
> > assessment on the compatibility of AFRINIC proposed
> > 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
> > responded with the following assessment:
> >
> > Based on ARIN?s Number Resource Policy Manual, Version 2016.2 ? 13 July
> > 2016, and referencing the following text from paragraph 8.4. Inter-RIR
> > Transfers to Specified Recipients, we have determined that the proposed
> > AFRINIC Inbound Transfer Policy is not reciprocal.
> >
> > ?Inter-regional transfers may take place only via RIRs who agree to the
> > transfer and share reciprocal, compatible, needs-based policies.?
> >
> > In this case reciprocal meaning that the policy provides both RIRs the
> > same ability to transfer: both in and out. This policy proposal as
> > written could not be implemented by ARIN. Note that ARIN?s Inter-RIR
> > transfer policy is based on other RIR's transfer policy and does not
> > consider any LIR or NIR policies.
> >
> > Regards,
> >
> > John Sweeting
> > Sr. Director, RSD
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20170119/8e101a2a/attachment.htm>

From bill at herrin.us  Thu Jan 19 18:24:13 2017
From: bill at herrin.us (William Herrin)
Date: Thu, 19 Jan 2017 18:24:13 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
Message-ID: <CAP-guGUE3c0oyt2Ejtx7CiH=A43xmDvCgvPFDNHhLgaT=C+79A@mail.gmail.com>

On Thu, Jan 19, 2017 at 3:36 PM, David R Huberman <daveid at panix.com> wrote:
> Last week, ARIN staff sent to this list a copy of their response to AFRINIC
> on inter-RIR transfer policy compatability.
>
> The AFRINIC community is considering a one-way transfer policy as a
> bootstrap for the few years until they reach IPv4 runout, at which point it
> would aim to become two-way.

Hi David,

If AFRINIC hasn't reached IPv4 runout, why do their registrants need
to buy addresses in the ARIN region?

I consider reciprocity far more important than needs testing. The LIR
loophole APNIC registrants continue to abuse bothers me.

Regards,
Bill Herrin



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


From cja at daydream.com  Thu Jan 19 18:24:59 2017
From: cja at daydream.com (Cj Aronson)
Date: Thu, 19 Jan 2017 16:24:59 -0700
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
Message-ID: <CAC6JZKSVd6qZ9qjiUv+qTL5DFcXBPiRSeZydU-UMM3OCD0YLUg@mail.gmail.com>

David

I agree that we should remove the word reciprocal or make a special
exception for AFRNIC and LACNIC.  We once had a separate minimum allocation
for the AFRINIC area before AFRINIC was formed.  I think this falls into
that same sort of policy category.

-----Cathy


{?,?}
  (( ))
  ?  ?

On Thu, Jan 19, 2017 at 1:36 PM, David R Huberman <daveid at panix.com> wrote:

>
> Last week, ARIN staff sent to this list a copy of their response to
> AFRINIC on inter-RIR transfer policy compatability.
>
> The AFRINIC community is considering a one-way transfer policy as a
> bootstrap for the few years until they reach IPv4 runout, at which point it
> would aim to become two-way.
>
> I feel like as a member of the internet community, that ARIN (we - us -
> the PPML participants) should be accepting that an RIR in a different
> region has different needs than we do. I think we should allow African
> internet operators to obtain blocks from sellers in the ARIN region, and
> transfer them to AFRINIC to meet their needs.
>
> The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis,
> and the language looks very similar to 8.2 and 8.3 language we've had at
> ARIN for a very long time.
>
> cf.
>
> http://www.afrinic.net/en/community/policy-development/polic
> y-proposals/1803-inbound-transfer-policy
>
> That's my opinion.  What's yours?
>
> Thanks,
> David
>
>
>
> On Thu, 12 Jan 2017, ARIN wrote:
>
> To PPML -
>>
>> As a result of policy discussions in the AFRINIC region, ARIN is
>> providing the following to information:
>>
>> On 30 September 2016 ARIN received a query from AFRINIC requesting an
>> assessment on the compatibility of AFRINIC proposed
>> 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
>> responded with the following assessment:
>>
>> Based on ARIN?s Number Resource Policy Manual, Version 2016.2 ? 13 July
>> 2016, and referencing the following text from paragraph 8.4. Inter-RIR
>> Transfers to Specified Recipients, we have determined that the proposed
>> AFRINIC Inbound Transfer Policy is not reciprocal.
>>
>> ?Inter-regional transfers may take place only via RIRs who agree to the
>> transfer and share reciprocal, compatible, needs-based policies.?
>>
>> In this case reciprocal meaning that the policy provides both RIRs the
>> same ability to transfer: both in and out. This policy proposal as
>> written could not be implemented by ARIN. Note that ARIN?s Inter-RIR
>> transfer policy is based on other RIR's transfer policy and does not
>> consider any LIR or NIR policies.
>>
>> Regards,
>>
>> John Sweeting
>> Sr. Director, RSD
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20170119/4a87d015/attachment.htm>

From farmer at umn.edu  Thu Jan 19 18:40:39 2017
From: farmer at umn.edu (David Farmer)
Date: Thu, 19 Jan 2017 17:40:39 -0600
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
Message-ID: <CAN-Dau2ijV7hsG+tbgjmQ4ytLW72sbcBaCvWiawyjJyAgcQFUw@mail.gmail.com>

The fundamental problem is our reciprocity requirement, are we willing to
change that?

I had argued against it originally, because I foresaw this very issue with
AFRINIC.  I don't think it we should require AFRINIC to allow transfers out
of their region to ours, for us to allow transfers out of our region to
theirs.  There were some in our community that were adamant that we had to
have reciprocity.  Since, AFRINIC wasn't anywhere near having a transfer
policy anyway, I didn't press the issue as it was more important to move
forward with out of region transfers than to argue the point at that time.

I'd support a proposal to remove the reciprocity requirement.

Thanks.

On Thu, Jan 19, 2017 at 2:36 PM, David R Huberman <daveid at panix.com> wrote:

>
> Last week, ARIN staff sent to this list a copy of their response to
> AFRINIC on inter-RIR transfer policy compatability.
>
> The AFRINIC community is considering a one-way transfer policy as a
> bootstrap for the few years until they reach IPv4 runout, at which point it
> would aim to become two-way.
>
> I feel like as a member of the internet community, that ARIN (we - us -
> the PPML participants) should be accepting that an RIR in a different
> region has different needs than we do. I think we should allow African
> internet operators to obtain blocks from sellers in the ARIN region, and
> transfer them to AFRINIC to meet their needs.
>
> The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis,
> and the language looks very similar to 8.2 and 8.3 language we've had at
> ARIN for a very long time.
>
> cf.
>
> http://www.afrinic.net/en/community/policy-development/polic
> y-proposals/1803-inbound-transfer-policy
>
> That's my opinion.  What's yours?
>
> Thanks,
> David
>
>
> On Thu, 12 Jan 2017, ARIN wrote:
>
> To PPML -
>>
>> As a result of policy discussions in the AFRINIC region, ARIN is
>> providing the following to information:
>>
>> On 30 September 2016 ARIN received a query from AFRINIC requesting an
>> assessment on the compatibility of AFRINIC proposed
>> 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
>> responded with the following assessment:
>>
>> Based on ARIN?s Number Resource Policy Manual, Version 2016.2 ? 13 July
>> 2016, and referencing the following text from paragraph 8.4. Inter-RIR
>> Transfers to Specified Recipients, we have determined that the proposed
>> AFRINIC Inbound Transfer Policy is not reciprocal.
>>
>> ?Inter-regional transfers may take place only via RIRs who agree to the
>> transfer and share reciprocal, compatible, needs-based policies.?
>>
>> In this case reciprocal meaning that the policy provides both RIRs the
>> same ability to transfer: both in and out. This policy proposal as
>> written could not be implemented by ARIN. Note that ARIN?s Inter-RIR
>> transfer policy is based on other RIR's transfer policy and does not
>> consider any LIR or NIR policies.
>>
>> Regards,
>>
>> John Sweeting
>> Sr. Director, RSD
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170119/e7281d4a/attachment.htm>

From kevinb at thewire.ca  Thu Jan 19 20:29:09 2017
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Fri, 20 Jan 2017 01:29:09 +0000
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
Message-ID: <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>

I would like to see it a little more nuanced than just the removal of reciprocity.

I took the following statistics from the NRO website (https://www.nro.net/wp-content/uploads/NRO_Q3_2016-2.pdf)

Number of /8 Assigned to Regions
ARIN 36
AFRINIC 5
LACNIC 9
RIPE NCC 35
APNIC 45

I would prefer a sentence, that allows for the relaxing of the reciprocal rule, in the event the gaining RIR is below the global average in IPv4 space.

Kevin Blumberg

From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
Sent: Thursday, January 19, 2017 4:14 PM
To: Mike Burns <mike at iptrading.com>
Cc: ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility

I would agree with this, and would support a policy proposal to remove the "reciprocal" requirement in ARIN inter-RIR transfer policy, leaving the "compatible, needs-based" requirement.

It looks like this would simply be a one-word change, removing "reciprocal," from the first sentence of 8.4.

-Scott

On Thu, Jan 19, 2017 at 1:02 PM, Mike Burns <mike at iptrading.com<mailto:mike at iptrading.com>> wrote:
Hi David,

An inbound-only policy is also under development at LACNIC and will hit the
discussion list there next week.

RIPE has officially said they will accept the provisions of the AFRINIC
inbound policy and will send RIPE addresses to AFRINIC should the AFRINIC
policy be implemented as written.

RIPE has told me they will treat any pending LACNIC policy the same way, if
the operative language is similar.

LACNIC also has a relatively rigorous needs-test for transfers, AFAIK they
even require the use of NAT.

I think the ARIN community must take notice of the relative superabundance
of IPv4 space in the region and how less address-rich regions must feel in
this age of exhaust.

The recent IPv4 market analysis at RIPE indicates that the transfer market
is fueled to a large extent by legacy address acting as supply. These legacy
addresses are again much more abundant in ARIN than they are in AFRINIC or
LACNIC.

My personal experience is that the LACNIC transfer market is suffering from
a lack of supply, and buyers are being asked to pay higher prices due to
scarcity. I believe that it is in the best interests of the Internet for
there to be a global market in IPv4 addresses. Unfortunately the
address-poor regions feel shortchanged, and they view any two-way policy as
a potential to lose some of their paltry amount to richer regions.

As a half-way step towards a truly global market, accepting that some
regions (and some NIRs) will not allow outbound transfers today, I believe
ARIN should join RIPE and remove the language about reciprocity, while
maintaining the requirement for compatible needs testing.

Regards,
Mike Burns





-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>] On Behalf Of David R
Huberman
Sent: Thursday, January 19, 2017 3:37 PM
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility


Last week, ARIN staff sent to this list a copy of their response to AFRINIC
on inter-RIR transfer policy compatability.

The AFRINIC community is considering a one-way transfer policy as a
bootstrap for the few years until they reach IPv4 runout, at which point it
would aim to become two-way.

I feel like as a member of the internet community, that ARIN (we - us - the
PPML participants) should be accepting that an RIR in a different region has
different needs than we do. I think we should allow African internet
operators to obtain blocks from sellers in the ARIN region, and transfer
them to AFRINIC to meet their needs.

The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis, and
the language looks very similar to 8.2 and 8.3 language we've had at ARIN
for a very long time.

cf.

http://www.afrinic.net/en/community/policy-development/policy-proposals/1803
-inbound-transfer-policy

That's my opinion.  What's yours?

Thanks,
David


On Thu, 12 Jan 2017, ARIN wrote:

> To PPML -
>
> As a result of policy discussions in the AFRINIC region, ARIN is
> providing the following to information:
>
> On 30 September 2016 ARIN received a query from AFRINIC requesting an
> assessment on the compatibility of AFRINIC proposed
> 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
> responded with the following assessment:
>
> Based on ARINb

_______________________________________________
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/20170120/ac5dc4f4/attachment.htm>

From scottleibrand at gmail.com  Thu Jan 19 20:40:55 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 19 Jan 2017 17:40:55 -0800
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
Message-ID: <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>

Why is average /8s per continent the right metric there?  Wouldn't IPv4
addresses per capita be more like what we're looking for?  I haven't run
the numbers, but I suspect the ARIN region is higher than all four of the
other RIRs in terms of IPv4 addresses per capita.  If so, then simply
removing "reciprocal," would have the same effect (of allowing transfers to
regions with more need for IPv4 addresses than the ARIN region) and be much
simpler.

-Scott

On Thu, Jan 19, 2017 at 5:29 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> I would like to see it a little more nuanced than just the removal of
> reciprocity.
>
>
>
> I took the following statistics from the NRO website (
> https://www.nro.net/wp-content/uploads/NRO_Q3_2016-2.pdf)
>
>
>
> Number of /8 Assigned to Regions
>
> ARIN 36
>
> AFRINIC 5
>
> LACNIC 9
>
> RIPE NCC 35
>
> APNIC 45
>
>
>
> I would prefer a sentence, that allows for the relaxing of the reciprocal
> rule, in the event the gaining RIR is below the global average in IPv4
> space.
>
>
>
> Kevin Blumberg
>
>
>
> *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Scott
> Leibrand
> *Sent:* Thursday, January 19, 2017 4:14 PM
> *To:* Mike Burns <mike at iptrading.com>
> *Cc:* ARIN-PPML List <arin-ppml at arin.net>
>
> *Subject:* Re: [arin-ppml] ARIN Response to AFRINIC on Policy
> compatibility
>
>
>
> I would agree with this, and would support a policy proposal to remove the
> "reciprocal" requirement in ARIN inter-RIR transfer policy, leaving the "compatible,
> needs-based" requirement.
>
>
>
> It looks like this would simply be a one-word change, removing
> "reciprocal," from the first sentence of 8.4.
>
>
>
> -Scott
>
>
>
> On Thu, Jan 19, 2017 at 1:02 PM, Mike Burns <mike at iptrading.com> wrote:
>
> Hi David,
>
> An inbound-only policy is also under development at LACNIC and will hit the
> discussion list there next week.
>
> RIPE has officially said they will accept the provisions of the AFRINIC
> inbound policy and will send RIPE addresses to AFRINIC should the AFRINIC
> policy be implemented as written.
>
> RIPE has told me they will treat any pending LACNIC policy the same way, if
> the operative language is similar.
>
> LACNIC also has a relatively rigorous needs-test for transfers, AFAIK they
> even require the use of NAT.
>
> I think the ARIN community must take notice of the relative superabundance
> of IPv4 space in the region and how less address-rich regions must feel in
> this age of exhaust.
>
> The recent IPv4 market analysis at RIPE indicates that the transfer market
> is fueled to a large extent by legacy address acting as supply. These
> legacy
> addresses are again much more abundant in ARIN than they are in AFRINIC or
> LACNIC.
>
> My personal experience is that the LACNIC transfer market is suffering from
> a lack of supply, and buyers are being asked to pay higher prices due to
> scarcity. I believe that it is in the best interests of the Internet for
> there to be a global market in IPv4 addresses. Unfortunately the
> address-poor regions feel shortchanged, and they view any two-way policy as
> a potential to lose some of their paltry amount to richer regions.
>
> As a half-way step towards a truly global market, accepting that some
> regions (and some NIRs) will not allow outbound transfers today, I believe
> ARIN should join RIPE and remove the language about reciprocity, while
> maintaining the requirement for compatible needs testing.
>
> Regards,
> Mike Burns
>
>
>
>
>
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David R
> Huberman
> Sent: Thursday, January 19, 2017 3:37 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
>
>
> Last week, ARIN staff sent to this list a copy of their response to AFRINIC
> on inter-RIR transfer policy compatability.
>
> The AFRINIC community is considering a one-way transfer policy as a
> bootstrap for the few years until they reach IPv4 runout, at which point it
> would aim to become two-way.
>
> I feel like as a member of the internet community, that ARIN (we - us - the
> PPML participants) should be accepting that an RIR in a different region
> has
> different needs than we do. I think we should allow African internet
> operators to obtain blocks from sellers in the ARIN region, and transfer
> them to AFRINIC to meet their needs.
>
> The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis,
> and
> the language looks very similar to 8.2 and 8.3 language we've had at ARIN
> for a very long time.
>
> cf.
>
> http://www.afrinic.net/en/community/policy-development/
> policy-proposals/1803
> -inbound-transfer-policy
> <http://www.afrinic.net/en/community/policy-development/policy-proposals/1803-inbound-transfer-policy>
>
> That's my opinion.  What's yours?
>
> Thanks,
> David
>
>
> On Thu, 12 Jan 2017, ARIN wrote:
>
> > To PPML -
> >
> > As a result of policy discussions in the AFRINIC region, ARIN is
> > providing the following to information:
> >
> > On 30 September 2016 ARIN received a query from AFRINIC requesting an
> > assessment on the compatibility of AFRINIC proposed
> > 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
> > responded with the following assessment:
> >
>
> > Based on ARINb
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20170119/250fffdf/attachment.htm>

From rudi.daniel at gmail.com  Thu Jan 19 20:45:40 2017
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Thu, 19 Jan 2017 21:45:40 -0400
Subject: [arin-ppml] ARIN 2016-8 Removal of indirect POC
In-Reply-To: <CA+uaoiX1iwgRjuLVOo1ia31P_=vN2ibqV9QfNOBg-nBhGceUtQ@mail.gmail.com>
References: <CA+uaoiX5dUXp-K2aEbpfDpQp4Z1Y3gRUnW1ArKSAsBgcsExtFg@mail.gmail.com>
 <CA+uaoiWfe=868gsJrYPqpdjq09zKs7cux08Z4DPWMa3E5farVw@mail.gmail.com>
 <CA+uaoiXz88mPHoZJcb7GJix==PnU5SKyeGOgXJYDCd-SfhsZ4w@mail.gmail.com>
 <CA+uaoiUW4_2tqPH=zTYT4TrvHdDcNU6fkFV-LEMSB9OK+yBj7g@mail.gmail.com>
 <CA+uaoiUkjQG-XgCJxL6bOV-b+q8wrNYe+81yEM5ebXGq=q07LA@mail.gmail.com>
 <CA+uaoiXe5yeTwMY0pt1R0bBW3kWTiZYG1j9uJgJ1Rt8OAReqUA@mail.gmail.com>
 <CA+uaoiUr6=3LZnuo-Q2BVNmMkPQR5AqsAFfRYBfxGm_qpZYtBA@mail.gmail.com>
 <CA+uaoiVdqaWMaqKN3OmP6wAz6FT0Siv4_yAVkf0Kc6ZQnLKzrA@mail.gmail.com>
 <CA+uaoiVs6dxmEcSrNn9nv8RofsD3PVkLVZdvfrTUTtPXhmeVZw@mail.gmail.com>
 <CA+uaoiWFg03XbRwHqrPAn8CpgZM2egJOf4MjJXnPXMKaO86DSA@mail.gmail.com>
 <CA+uaoiX1iwgRjuLVOo1ia31P_=vN2ibqV9QfNOBg-nBhGceUtQ@mail.gmail.com>
Message-ID: <CA+uaoiXAzCdeyxML6EaAPBJLH23gYc=HR47THyr+bN=tpR8hhw@mail.gmail.com>

I oppose the policy as written.

I have to agree with Owen on this one...In that it does not sound like
palatable solution to the problem aired.
Although, a change to 'may be sent'  is similar to 'will not be sent'.

Is there some other annual event which can be used to impose POC update at
the same time (??)
rd

On Jan 19, 2017 4:39 PM, <arin-ppml-request at arin.net> wrote:

Send ARIN-PPML mailing list submissions to
        arin-ppml at arin.net

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
        arin-ppml-request at arin.net

You can reach the person managing the list at
        arin-ppml-owner at arin.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."


Today's Topics:

   1. Re: Draft Policy ARIN-2016-8: Removal of Indirect POC
      Validation Requirement (Chris Woodfield)
   2. ARIN Response to AFRINIC on Policy compatibility (ARIN)
   3. Weekly posting summary for ppml at arin.net (narten at us.ibm.com)
   4. Re: Draft Policy 2016-7 -- Integrate community networks into
      Existing ISP Policy (David Farmer)
   5. Re: ARIN Response to AFRINIC on Policy compatibility
      (David R Huberman)


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

Message: 1
Date: Fri, 6 Jan 2017 09:58:12 -0800
From: Chris Woodfield <chris at semihuman.com>
To: ARIN <info at arin.net>, arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect
        POC Validation Requirement
Message-ID: <44BCDCD7-5449-443B-9F97-C57B871161F2 at semihuman.com>
Content-Type: text/plain; charset=utf-8

Is the presence of the phrase ?will be sent? in the current policy intended
to set a requirement for the POC (this email will be sent annually, you
must reply to it in order to validate the record), or intended as a
requirement for ARIN staff (ARIN is required to send the email annually)?

To the concept of the random audit approach mentioned earlier, It may be
simple enough to change ?will be sent? to ?may be sent?. I?d argue that
procedurally the sampling rate should be fairly high, however (i.e. no less
than, say, 20% of records).

-C

> On Jan 5, 2017, at 12:46 PM, Owen DeLong <owen at delong.com> wrote:
>
> I oppose the policy as written.
>
> While I agree that the validation of indirect POCs by ARIN has become a
problem, I believe that this is the exact opposite of a good solution.
>
> Indeed, my organization has a significant problem with vendors creating
indirect POC records pointing to individuals within my organization who are
not good POCs for the space in question rather than using our existing POC
handles which we have provided to those vendors.
>
> The current POC validation process is one of the few checks and balances
which allows us to catch and address these issues.
>

P.S. Personally, I?d argue that a viable alternate strategy in the absence
of that check/balance would be to make sure that the requirement to use
your official POCs is written into your vendor contracts at next renewal,
and operationally onto a service acceptance checklist backed up by said
contract language.

> Ideally, we would like to have a way for ARIN to flag and validate new
POCs pointed at our organization _BEFORE_ they are actually placed into the
database or attached to resources.
>
> Owen
>
>> On Dec 20, 2016, at 10:09 , ARIN <info at arin.net> wrote:
>>
>> On 15 December 2016, the ARIN Advisory Council (AC) advanced the
following Proposal to Draft Policy status:
>>
>> ARIN-prop-233: Removal of Indirect POC Validation Requirement
>>
>> This Draft Policy has been numbered and titled:
>>
>> Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement
>>
>> Draft Policy text is below and can be found at:
>> https://www.arin.net/policy/proposals/2016_8.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,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>> ##########
>>
>> ARIN-2016-8: Removal of Indirect POC Validation Requirement
>>
>> Problem Statement:
>>
>> There are over 600,000 POCs registered in Whois that are only associated
with indirect assignments (reassignments) and indirect allocations
(reallocations). NRPM 3.6 requires ARIN to contact all 600,000+ of these
every year to validate the POC information. This is problematic for a few
reasons:
>>
>> 1) ARIN does not have a business relationships with these POCs. By
conducting POC validation via email, ARIN is sending Unsolicited Commercial
Emails. Further, because of NRPM 3.6.1, ARIN cannot offer an opt-out
mechanism. Finally, ARIN's resultant listing on anti-spam lists causes
unacceptable damage to ARIN's ability to conduct ordinary business over
email
>>
>> 2) ARIN has previously reported that POC validation to reassignments
causes tremendous work for the staff. It receives many angry phone calls
and emails about the POC validation process. I believe the ARIN staff
should be focused on POC validation efforts for directly issued resources,
as that has more value to internet operations and law enforcement than
end-user POC information.
>>
>> Policy statement:
>>
>> Replace the first sentence of 3.6.1:
>>
>> "During ARIN's annual Whois POC validation, an email will be sent to
every POC in the Whois database."
>>
>> with
>>
>> "During ARIN's annual Whois POC validation, an email will be sent to
every POC that is a contact for a direct assignment, direct allocation,
reallocation, and AS number, and their associated OrgIDs."
>>
>> 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.
>



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

Message: 2
Date: Thu, 12 Jan 2017 14:17:18 -0500
From: ARIN <info at arin.net>
To: arin-ppml at arin.net
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
Message-ID: <ea90a56c-21f5-47d8-f6ad-9500a9f78248 at arin.net>
Content-Type: text/plain; charset=utf-8; format=flowed

To PPML -

As a result of policy discussions in the AFRINIC region, ARIN is
providing the following to information:

On 30 September 2016 ARIN received a query from AFRINIC requesting an
assessment on the compatibility of AFRINIC proposed
1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
responded with the following assessment:

Based on ARIN?s Number Resource Policy Manual, Version 2016.2 ? 13 July
2016, and referencing the following text from paragraph 8.4. Inter-RIR
Transfers to Specified Recipients, we have determined that the proposed
AFRINIC Inbound Transfer Policy is not reciprocal.

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

In this case reciprocal meaning that the policy provides both RIRs the
same ability to transfer: both in and out. This policy proposal as
written could not be implemented by ARIN. Note that ARIN?s Inter-RIR
transfer policy is based on other RIR's transfer policy and does not
consider any LIR or NIR policies.

Regards,

John Sweeting
Sr. Director, RSD
American Registry for Internet Numbers (ARIN)





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

Message: 3
Date: Fri, 13 Jan 2017 00:53:23 -0500
From: narten at us.ibm.com
To: arin-ppml at arin.net
Subject: [arin-ppml] Weekly posting summary for ppml at arin.net
Message-ID: <201701130553.v0D5rN8s018352 at rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii

Total of 4 messages in the last 7 days.

script run at: Fri Jan 13 00:53:18 EST 2017

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 25.00% |    1 | 33.84% |    11000 | chris at semihuman.com
 25.00% |    1 | 26.19% |     8514 | narten at us.ibm.com
 25.00% |    1 | 20.31% |     6603 | info at arin.net
 25.00% |    1 | 19.66% |     6391 | ppml at rsuc.gweep.net
--------+------+--------+----------+------------------------
100.00% |    4 |100.00% |    32508 | Total



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

Message: 4
Date: Tue, 17 Jan 2017 13:42:11 -0600
From: David Farmer <farmer at umn.edu>
To: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy 2016-7 -- Integrate community
        networks into Existing ISP Policy
Message-ID:
        <CAN-Dau0kCCNxDvCTZgwudnzLN3Yt2o-xu6gMYcb0Dc5igWRU5Q at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

It concerns me that no one that operates a community network has commented
on this policy.  Further it concerns me that no one from the general ARIN
policy community commented either, only AC members and a former AC member
who is also the policy author have made any comments.

Is there interest from the ARIN policy community to work on this or are
their other priorities for the community's time?

It would be helpful to hear from others in regards to if this is something
we should be working on or not.

Thanks.

On Sun, Dec 18, 2016 at 2:58 PM, Andrew Dul <andrew.dul at quark.net> wrote:

> It would be especially helpful for the AC if those who operate community
> networks could review the proposed draft policy and see if the problem
> statement highlights an issue for operators and if the proposed text
solves
> this problem.
>
> Thanks,
> Andrew
>
>
>
> On 12/15/2016 3:30 PM, Kevin Blumberg wrote:
>
> Owen,
>
> As the author of 2016-7 I disagree.
>
> The change in 2016-6 had no meaningful impact to the usefulness of
Community
> Networks. T
>
> The purpose of 2016-7 was to significantly reduce the red tape
requirements
> with Community Networks.
>
> I believe that without this kind of policy Community Network's will never
> get used given the onerous requirements.
>
> Thanks,
>
> Kevin Blumberg
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net <
arin-ppml-bounces at arin.net>] On Behalf Of Owen DeLong
> Sent: Thursday, December 15, 2016 4:19 PM
> To: ARIN-PPML List <arin-ppml at arin.net> <arin-ppml at arin.net>
> Subject: [arin-ppml] Draft Policy 2016-7 -- Integrate community networks
> into Existing ISP Policy
>
> I believe that this proposal no longer has relevance given the advancement
> of 2016-6 and its rewrite of the community networks policy to the board.
>
> If anyone feels that the AC should not abandon this proposal at their
> January meeting, please speak up.
>
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
Public
> Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



--
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/
attachments/20170117/1d53d82b/attachment-0001.html>

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

Message: 5
Date: Thu, 19 Jan 2017 15:36:54 -0500 (EST)
From: David R Huberman <daveid at panix.com>
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy
        compatibility
Message-ID: <Pine.NEB.4.64.1701191530420.25224 at panix1.panix.com>
Content-Type: text/plain; charset="x-unknown"; Format="flowed"


Last week, ARIN staff sent to this list a copy of their response to
AFRINIC on inter-RIR transfer policy compatability.

The AFRINIC community is considering a one-way transfer policy as a
bootstrap for the few years until they reach IPv4 runout, at which point
it would aim to become two-way.

I feel like as a member of the internet community, that ARIN (we - us -
the PPML participants) should be accepting that an RIR in a different
region has different needs than we do. I think we should allow African
internet operators to obtain blocks from sellers in the ARIN region, and
transfer them to AFRINIC to meet their needs.

The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis,
and the language looks very similar to 8.2 and 8.3 language we've had at
ARIN for a very long time.

cf.

http://www.afrinic.net/en/community/policy-development/
policy-proposals/1803-inbound-transfer-policy

That's my opinion.  What's yours?

Thanks,
David


On Thu, 12 Jan 2017, ARIN wrote:

> To PPML -
>
> As a result of policy discussions in the AFRINIC region, ARIN is
> providing the following to information:
>
> On 30 September 2016 ARIN received a query from AFRINIC requesting an
> assessment on the compatibility of AFRINIC proposed
> 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
> responded with the following assessment:
>
> Based on ARIN???s Number Resource Policy Manual, Version 2016.2 ??? 13
July
> 2016, and referencing the following text from paragraph 8.4. Inter-RIR
> Transfers to Specified Recipients, we have determined that the proposed
> AFRINIC Inbound Transfer Policy is not reciprocal.
>
> ???Inter-regional transfers may take place only via RIRs who agree to the
> transfer and share reciprocal, compatible, needs-based policies.???
>
> In this case reciprocal meaning that the policy provides both RIRs the
> same ability to transfer: both in and out. This policy proposal as
> written could not be implemented by ARIN. Note that ARIN???s Inter-RIR
> transfer policy is based on other RIR's transfer policy and does not
> consider any LIR or NIR policies.
>
> Regards,
>
> John Sweeting
> Sr. Director, RSD
> American Registry for Internet Numbers (ARIN)
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

Subject: Digest Footer

_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net
http://lists.arin.net/mailman/listinfo/arin-ppml

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

End of ARIN-PPML Digest, Vol 139, Issue 2
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170119/38439136/attachment.htm>

From narten at us.ibm.com  Fri Jan 20 00:53:18 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 20 Jan 2017 00:53:18 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201701200553.v0K5rIe0023325@rotala.raleigh.ibm.com>

Total of 12 messages in the last 7 days.
 
script run at: Fri Jan 20 00:53:13 EST 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 16.67% |    2 | 18.63% |    42107 | scottleibrand at gmail.com
 16.67% |    2 | 16.33% |    36922 | farmer at umn.edu
  8.33% |    1 | 21.74% |    49142 | rudi.daniel at gmail.com
  8.33% |    1 | 13.36% |    30208 | kevinb at thewire.ca
  8.33% |    1 |  7.89% |    17833 | matthew at matthew.at
  8.33% |    1 |  7.21% |    16291 | cja at daydream.com
  8.33% |    1 |  4.00% |     9041 | mike at iptrading.com
  8.33% |    1 |  3.92% |     8850 | daveid at panix.com
  8.33% |    1 |  3.78% |     8554 | narten at us.ibm.com
  8.33% |    1 |  3.14% |     7093 | bill at herrin.us
--------+------+--------+----------+------------------------
100.00% |   12 |100.00% |   226041 | Total



From job at ntt.net  Fri Jan 20 07:23:07 2017
From: job at ntt.net (Job Snijders)
Date: Fri, 20 Jan 2017 13:23:07 +0100
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
Message-ID: <20170120122307.GB4458@Vurt.local>

On Thu, Jan 19, 2017 at 05:40:55PM -0800, Scott Leibrand wrote:
> Why is average /8s per continent the right metric there?  Wouldn't
> IPv4 addresses per capita be more like what we're looking for?  I
> haven't run the numbers, but I suspect the ARIN region is higher than
> all four of the other RIRs in terms of IPv4 addresses per capita.  If
> so, then simply removing "reciprocal," would have the same effect (of
> allowing transfers to regions with more need for IPv4 addresses than
> the ARIN region) and be much simpler.

    Region  | /8 count  | population (mm) | ipv4 per capita (+/- avg)
    --------+-----------+-----------------+-------------------------
    ARIN    |    36     |            579  | 1.043 (+355%)
    AFRINIC |     5     |           1216  | 0.068 (-430%)
    LACNIC  |     9     |            442  | 0.357 (+120%)
    RIPE    |    35     |            738  | 0.794 (+270%)
    APNIC   |    45     |           4476  | 0.168 ( -57%)
    --------+-----------+-----------------+----------------
    total   |   130     |           7451  | 0.293

numbers taken from https://en.wikipedia.org/wiki/List_of_continents_by_population

Kind regards,

Job


From ingrid at ripe.net  Fri Jan 20 08:21:11 2017
From: ingrid at ripe.net (Ingrid Wijte)
Date: Fri, 20 Jan 2017 14:21:11 +0100
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <047401d27297$551a97c0$ff4fc740$@iptrading.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
Message-ID: <adfe6f11-3a49-a9cf-7b3f-b45005a65aeb@ripe.net>

Dear Mike and all,

On 19/01/2017 22:02, Mike Burns wrote:
> Hi David,
>
> An inbound-only policy is also under development at LACNIC and will hit the
> discussion list there next week.
>
> RIPE has officially said they will accept the provisions of the AFRINIC
> inbound policy and will send RIPE addresses to AFRINIC should the AFRINIC
> policy be implemented as written.
>
> RIPE has told me they will treat any pending LACNIC policy the same way, if
> the operative language is similar.
I would like to clarify that based on *current* RIPE policies, the 
current inbound policy proposal in the Afrinic region would indeed be 
compatible. However, there is ofcourse always the possibility that these 
policies will change in the future.

Best regards,

Ingrid Wijte
RIPE NCC

>
> LACNIC also has a relatively rigorous needs-test for transfers, AFAIK they
> even require the use of NAT.
>
> I think the ARIN community must take notice of the relative superabundance
> of IPv4 space in the region and how less address-rich regions must feel in
> this age of exhaust.
>
> The recent IPv4 market analysis at RIPE indicates that the transfer market
> is fueled to a large extent by legacy address acting as supply. These legacy
> addresses are again much more abundant in ARIN than they are in AFRINIC or
> LACNIC.
>
> My personal experience is that the LACNIC transfer market is suffering from
> a lack of supply, and buyers are being asked to pay higher prices due to
> scarcity. I believe that it is in the best interests of the Internet for
> there to be a global market in IPv4 addresses. Unfortunately the
> address-poor regions feel shortchanged, and they view any two-way policy as
> a potential to lose some of their paltry amount to richer regions.
>
> As a half-way step towards a truly global market, accepting that some
> regions (and some NIRs) will not allow outbound transfers today, I believe
> ARIN should join RIPE and remove the language about reciprocity, while
> maintaining the requirement for compatible needs testing.
>
> Regards,
> Mike Burns
>
>
>
>
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David R
> Huberman
> Sent: Thursday, January 19, 2017 3:37 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
>
>
> Last week, ARIN staff sent to this list a copy of their response to AFRINIC
> on inter-RIR transfer policy compatability.
>
> The AFRINIC community is considering a one-way transfer policy as a
> bootstrap for the few years until they reach IPv4 runout, at which point it
> would aim to become two-way.
>
> I feel like as a member of the internet community, that ARIN (we - us - the
> PPML participants) should be accepting that an RIR in a different region has
> different needs than we do. I think we should allow African internet
> operators to obtain blocks from sellers in the ARIN region, and transfer
> them to AFRINIC to meet their needs.
>
> The AFRINIC inbound transfer policy is very ARIN-like. It's needs-basis, and
> the language looks very similar to 8.2 and 8.3 language we've had at ARIN
> for a very long time.
>
> cf.
>
> http://www.afrinic.net/en/community/policy-development/policy-proposals/1803
> -inbound-transfer-policy
>
> That's my opinion.  What's yours?
>
> Thanks,
> David
>
>
> On Thu, 12 Jan 2017, ARIN wrote:
>
>> To PPML -
>>
>> As a result of policy discussions in the AFRINIC region, ARIN is
>> providing the following to information:
>>
>> On 30 September 2016 ARIN received a query from AFRINIC requesting an
>> assessment on the compatibility of AFRINIC proposed
>> 1803-inbound-transfer-policy with ARIN policy. On 6 October 2016 ARIN
>> responded with the following assessment:
>>
>> Based on ARINb
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20170120/2e05e7cd/attachment.htm>

From jrdelacruz at acm.org  Fri Jan 20 12:04:25 2017
From: jrdelacruz at acm.org (Jose R. de la Cruz III)
Date: Fri, 20 Jan 2017 13:04:25 -0400
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <CAP-guGUE3c0oyt2Ejtx7CiH=A43xmDvCgvPFDNHhLgaT=C+79A@mail.gmail.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <CAP-guGUE3c0oyt2Ejtx7CiH=A43xmDvCgvPFDNHhLgaT=C+79A@mail.gmail.com>
Message-ID: <CAKrxPqetCp3+vzCjCs_NkaoZGJrH1h+x0_vyJvYujYedr4NTyQ@mail.gmail.com>

I agree with Bill. If they are yet to reach runout, why are "external"
resources required?

Jos?

On Thu, Jan 19, 2017 at 7:24 PM, William Herrin <bill at herrin.us> wrote:

> On Thu, Jan 19, 2017 at 3:36 PM, David R Huberman <daveid at panix.com>
> wrote:
> > Last week, ARIN staff sent to this list a copy of their response to
> AFRINIC
> > on inter-RIR transfer policy compatability.
> >
> > The AFRINIC community is considering a one-way transfer policy as a
> > bootstrap for the few years until they reach IPv4 runout, at which point
> it
> > would aim to become two-way.
>
> Hi David,
>
> If AFRINIC hasn't reached IPv4 runout, why do their registrants need
> to buy addresses in the ARIN region?
>
> I consider reciprocity far more important than needs testing. The LIR
> loophole APNIC registrants continue to abuse bothers me.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170120/51e234c7/attachment.htm>

From daveid at panix.com  Fri Jan 20 12:09:43 2017
From: daveid at panix.com (David Huberman)
Date: Fri, 20 Jan 2017 12:09:43 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <CAKrxPqetCp3+vzCjCs_NkaoZGJrH1h+x0_vyJvYujYedr4NTyQ@mail.gmail.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <CAP-guGUE3c0oyt2Ejtx7CiH=A43xmDvCgvPFDNHhLgaT=C+79A@mail.gmail.com>
 <CAKrxPqetCp3+vzCjCs_NkaoZGJrH1h+x0_vyJvYujYedr4NTyQ@mail.gmail.com>
Message-ID: <582FAFC1-8194-440C-8B61-1CDC176FD465@panix.com>

Because they're approaching their last /8 and have maximum block limits in their policy that go into place for the last /8:

http://afrinic.net/en/library/news/1973-afrinic-is-approaching-ipv4-exhaustion-phase-1



> On Jan 20, 2017, at 12:04 PM, Jose R. de la Cruz III <jrdelacruz at acm.org> wrote:
> 
> I agree with Bill. If they are yet to reach runout, why are "external" resources required?
> 
> Jos?
> 
>> On Thu, Jan 19, 2017 at 7:24 PM, William Herrin <bill at herrin.us> wrote:
>> On Thu, Jan 19, 2017 at 3:36 PM, David R Huberman <daveid at panix.com> wrote:
>> > Last week, ARIN staff sent to this list a copy of their response to AFRINIC
>> > on inter-RIR transfer policy compatability.
>> >
>> > The AFRINIC community is considering a one-way transfer policy as a
>> > bootstrap for the few years until they reach IPv4 runout, at which point it
>> > would aim to become two-way.
>> 
>> Hi David,
>> 
>> If AFRINIC hasn't reached IPv4 runout, why do their registrants need
>> to buy addresses in the ARIN region?
>> 
>> I consider reciprocity far more important than needs testing. The LIR
>> loophole APNIC registrants continue to abuse bothers me.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> 
>> --
>> William Herrin ................ herrin at dirtside.com  bill at herrin.us
>> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20170120/2a73584c/attachment.htm>

From jrdelacruz at acm.org  Fri Jan 20 12:22:20 2017
From: jrdelacruz at acm.org (Jose R. de la Cruz III)
Date: Fri, 20 Jan 2017 13:22:20 -0400
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <582FAFC1-8194-440C-8B61-1CDC176FD465@panix.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <CAP-guGUE3c0oyt2Ejtx7CiH=A43xmDvCgvPFDNHhLgaT=C+79A@mail.gmail.com>
 <CAKrxPqetCp3+vzCjCs_NkaoZGJrH1h+x0_vyJvYujYedr4NTyQ@mail.gmail.com>
 <582FAFC1-8194-440C-8B61-1CDC176FD465@panix.com>
Message-ID: <CAKrxPqdFzvaiEu2xA9YniWzceRnyF5wjZcf_6ssCcZewmph70g@mail.gmail.com>

David:
Thanks for the link!
Jos?

On Fri, Jan 20, 2017 at 1:09 PM, David Huberman <daveid at panix.com> wrote:

> Because they're approaching their last /8 and have maximum block limits in
> their policy that go into place for the last /8:
>
> http://afrinic.net/en/library/news/1973-afrinic-is-
> approaching-ipv4-exhaustion-phase-1
>
>
>
> On Jan 20, 2017, at 12:04 PM, Jose R. de la Cruz III <jrdelacruz at acm.org>
> wrote:
>
> I agree with Bill. If they are yet to reach runout, why are "external"
> resources required?
>
> Jos?
>
> On Thu, Jan 19, 2017 at 7:24 PM, William Herrin <bill at herrin.us> wrote:
>
>> On Thu, Jan 19, 2017 at 3:36 PM, David R Huberman <daveid at panix.com>
>> wrote:
>> > Last week, ARIN staff sent to this list a copy of their response to
>> AFRINIC
>> > on inter-RIR transfer policy compatability.
>> >
>> > The AFRINIC community is considering a one-way transfer policy as a
>> > bootstrap for the few years until they reach IPv4 runout, at which
>> point it
>> > would aim to become two-way.
>>
>> Hi David,
>>
>> If AFRINIC hasn't reached IPv4 runout, why do their registrants need
>> to buy addresses in the ARIN region?
>>
>> I consider reciprocity far more important than needs testing. The LIR
>> loophole APNIC registrants continue to abuse bothers me.
>>
>> Regards,
>> Bill Herrin
>>
>>
>>
>> --
>> William Herrin ................ herrin at dirtside.com  bill at herrin.us
>> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20170120/7cfedc40/attachment.htm>

From rs-lists at seastrom.com  Fri Jan 20 12:24:32 2017
From: rs-lists at seastrom.com (Rob Seastrom)
Date: Fri, 20 Jan 2017 12:24:32 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <582FAFC1-8194-440C-8B61-1CDC176FD465@panix.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <CAP-guGUE3c0oyt2Ejtx7CiH=A43xmDvCgvPFDNHhLgaT=C+79A@mail.gmail.com>
 <CAKrxPqetCp3+vzCjCs_NkaoZGJrH1h+x0_vyJvYujYedr4NTyQ@mail.gmail.com>
 <582FAFC1-8194-440C-8B61-1CDC176FD465@panix.com>
Message-ID: <914C4B6C-8863-4CEA-A258-A274BF260150@seastrom.com>


Back when we were concerned that our regional free pool might precipitously empty (perhaps via some unforeseen loophole in our transfer regimen) I supported the reciprocity requirement, as a potential countermeasure against that outcome. 

Now that there is no longer a free pool to worry about, this clause has outlived its usefulness. 

I support removing the reciprocity requirement.

-r

Sent from my iPad

> On Jan 20, 2017, at 12:09, David Huberman <daveid at panix.com> wrote:
> 
> Because they're approaching their last /8 and have maximum block limits in their policy that go into place for the last /8:
> 
> http://afrinic.net/en/library/news/1973-afrinic-is-approaching-ipv4-exhaustion-phase-1
> 
> 
> 
>> On Jan 20, 2017, at 12:04 PM, Jose R. de la Cruz III <jrdelacruz at acm.org> wrote:
>> 
>> I agree with Bill. If they are yet to reach runout, why are "external" resources required?
>> 
>> Jos?
>> 
>>> On Thu, Jan 19, 2017 at 7:24 PM, William Herrin <bill at herrin.us> wrote:
>>> On Thu, Jan 19, 2017 at 3:36 PM, David R Huberman <daveid at panix.com> wrote:
>>> > Last week, ARIN staff sent to this list a copy of their response to AFRINIC
>>> > on inter-RIR transfer policy compatability.
>>> >
>>> > The AFRINIC community is considering a one-way transfer policy as a
>>> > bootstrap for the few years until they reach IPv4 runout, at which point it
>>> > would aim to become two-way.
>>> 
>>> Hi David,
>>> 
>>> If AFRINIC hasn't reached IPv4 runout, why do their registrants need
>>> to buy addresses in the ARIN region?
>>> 
>>> I consider reciprocity far more important than needs testing. The LIR
>>> loophole APNIC registrants continue to abuse bothers me.
>>> 
>>> Regards,
>>> Bill Herrin
>>> 
>>> 
>>> 
>>> --
>>> William Herrin ................ herrin at dirtside.com  bill at herrin.us
>>> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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/20170120/1de55324/attachment.htm>

From mike at iptrading.com  Fri Jan 20 12:48:30 2017
From: mike at iptrading.com (Mike Burns)
Date: Fri, 20 Jan 2017 12:48:30 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <20170120122307.GB4458@Vurt.local>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
Message-ID: <01d401d27345$69c5e400$3d51ac00$@iptrading.com>

I forget where the original numbers came from, but with a total of 130,
obviously many /8s are missing.
Probably this count is not considering legacy space, most of which is North
American.
Including those legacy addresses, the supply for much of the transfer
market, the ratios are much more in ARIN's favor.

Regards,
Mike



-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Job
Snijders
Sent: Friday, January 20, 2017 7:23 AM
To: Scott Leibrand <scottleibrand at gmail.com>
Cc: ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility

On Thu, Jan 19, 2017 at 05:40:55PM -0800, Scott Leibrand wrote:
> Why is average /8s per continent the right metric there?  Wouldn't
> IPv4 addresses per capita be more like what we're looking for?  I 
> haven't run the numbers, but I suspect the ARIN region is higher than 
> all four of the other RIRs in terms of IPv4 addresses per capita.  If 
> so, then simply removing "reciprocal," would have the same effect (of 
> allowing transfers to regions with more need for IPv4 addresses than 
> the ARIN region) and be much simpler.

    Region  | /8 count  | population (mm) | ipv4 per capita (+/- avg)
    --------+-----------+-----------------+-------------------------
    ARIN    |    36     |            579  | 1.043 (+355%)
    AFRINIC |     5     |           1216  | 0.068 (-430%)
    LACNIC  |     9     |            442  | 0.357 (+120%)
    RIPE    |    35     |            738  | 0.794 (+270%)
    APNIC   |    45     |           4476  | 0.168 ( -57%)
    --------+-----------+-----------------+----------------
    total   |   130     |           7451  | 0.293

numbers taken from
https://en.wikipedia.org/wiki/List_of_continents_by_population

Kind regards,

Job
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public
Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage 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 bjones at vt.edu  Fri Jan 20 13:37:11 2017
From: bjones at vt.edu (Brian Jones)
Date: Fri, 20 Jan 2017 13:37:11 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <914C4B6C-8863-4CEA-A258-A274BF260150@seastrom.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <CAP-guGUE3c0oyt2Ejtx7CiH=A43xmDvCgvPFDNHhLgaT=C+79A@mail.gmail.com>
 <CAKrxPqetCp3+vzCjCs_NkaoZGJrH1h+x0_vyJvYujYedr4NTyQ@mail.gmail.com>
 <582FAFC1-8194-440C-8B61-1CDC176FD465@panix.com>
 <914C4B6C-8863-4CEA-A258-A274BF260150@seastrom.com>
Message-ID: <DFCC2749-5EBE-4296-8D48-5E5B63274F01@vt.edu>

It?s legacy space, I support removing the reciprocity requirement.
--
Brian E Jones, CSM, CSPO
NI&S Virginia Tech
bjones at vt.edu

> On Jan 20, 2017, at 12:24 PM, Rob Seastrom <rs-lists at seastrom.com> wrote:
> 
> 
> Back when we were concerned that our regional free pool might precipitously empty (perhaps via some unforeseen loophole in our transfer regimen) I supported the reciprocity requirement, as a potential countermeasure against that outcome.
> 
> Now that there is no longer a free pool to worry about, this clause has outlived its usefulness.

+1

> 
> I support removing the reciprocity requirement.
> 
> -r
> 
> Sent from my iPad
> 
> On Jan 20, 2017, at 12:09, David Huberman <daveid at panix.com <mailto:daveid at panix.com>> wrote:
> 
>> Because they're approaching their last /8 and have maximum block limits in their policy that go into place for the last /8:
>> 
>> http://afrinic.net/en/library/news/1973-afrinic-is-approaching-ipv4-exhaustion-phase-1 <http://afrinic.net/en/library/news/1973-afrinic-is-approaching-ipv4-exhaustion-phase-1>
>> 
>> 
>> On Jan 20, 2017, at 12:04 PM, Jose R. de la Cruz III <jrdelacruz at acm.org <mailto:jrdelacruz at acm.org>> wrote:
>> 
>>> I agree with Bill. If they are yet to reach runout, why are "external" resources required?
>>> 
>>> Jos?
>>> 
>>> On Thu, Jan 19, 2017 at 7:24 PM, William Herrin <bill at herrin.us <mailto:bill at herrin.us>> wrote:
>>> On Thu, Jan 19, 2017 at 3:36 PM, David R Huberman <daveid at panix.com <mailto:daveid at panix.com>> wrote:
>>> > Last week, ARIN staff sent to this list a copy of their response to AFRINIC
>>> > on inter-RIR transfer policy compatability.
>>> >
>>> > The AFRINIC community is considering a one-way transfer policy as a
>>> > bootstrap for the few years until they reach IPv4 runout, at which point it
>>> > would aim to become two-way.
>>> 
>>> Hi David,
>>> 
>>> If AFRINIC hasn't reached IPv4 runout, why do their registrants need
>>> to buy addresses in the ARIN region?
>>> 
>>> I consider reciprocity far more important than needs testing. The LIR
>>> loophole APNIC registrants continue to abuse bothers me.
>>> 
>>> Regards,
>>> Bill Herrin
>>> 
>>> 
>>> 
>>> --
>>> William Herrin ................ herrin at dirtside.com <mailto:herrin at dirtside.com>  bill at herrin.us <mailto:bill at herrin.us>
>>> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/ <http://www.dirtside.com/>>
>>> _______________________________________________
>>> 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/20170120/af72febd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170120/af72febd/attachment.sig>

From leo.vegoda at icann.org  Fri Jan 20 13:55:21 2017
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Fri, 20 Jan 2017 18:55:21 +0000
Subject: [arin-ppml] [Ext] Re: ARIN Response to AFRINIC on Policy
 compatibility
In-Reply-To: <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
Message-ID: <3d8ccc0502e240739c5a2edaec1a62e9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG>

Mike Burns wrote:

[...]

> I forget where the original numbers came from, but with a total of 130, 
> obviously many /8s are missing.

If I remember correctly, the legacy blocks are all listed as "Administered
by..." 
here: https://www.iana.org/assignments/ipv4-address-space/

Kind regards,

Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4968 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170120/8a8ba683/attachment.p7s>

From owen at delong.com  Fri Jan 20 20:29:29 2017
From: owen at delong.com (Owen DeLong)
Date: Fri, 20 Jan 2017 17:29:29 -0800
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
Message-ID: <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>

The reciprocity requirement merely requires that the policies ALLOW transfers in both directions.

I do not believe that allowing transfers to an RIR which will not allow transfers out is reasonable or prudent and this belief has nothing to do with maintenance or protection of a free pool. If we will allow transfers between RIRs, then the policies by which they are allowed should be fair, balanced, and symmetrical. This does not mean that I expect the ratio of actual transfers to be balanced or symmetrical, merely that the policies under which they are conducted should be.

Owen

> On Jan 20, 2017, at 09:48 , Mike Burns <mike at iptrading.com> wrote:
> 
> I forget where the original numbers came from, but with a total of 130,
> obviously many /8s are missing.
> Probably this count is not considering legacy space, most of which is North
> American.
> Including those legacy addresses, the supply for much of the transfer
> market, the ratios are much more in ARIN's favor.
> 
> Regards,
> Mike
> 
> 
> 
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Job
> Snijders
> Sent: Friday, January 20, 2017 7:23 AM
> To: Scott Leibrand <scottleibrand at gmail.com>
> Cc: ARIN-PPML List <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
> 
> On Thu, Jan 19, 2017 at 05:40:55PM -0800, Scott Leibrand wrote:
>> Why is average /8s per continent the right metric there?  Wouldn't
>> IPv4 addresses per capita be more like what we're looking for?  I 
>> haven't run the numbers, but I suspect the ARIN region is higher than 
>> all four of the other RIRs in terms of IPv4 addresses per capita.  If 
>> so, then simply removing "reciprocal," would have the same effect (of 
>> allowing transfers to regions with more need for IPv4 addresses than 
>> the ARIN region) and be much simpler.
> 
>    Region  | /8 count  | population (mm) | ipv4 per capita (+/- avg)
>    --------+-----------+-----------------+-------------------------
>    ARIN    |    36     |            579  | 1.043 (+355%)
>    AFRINIC |     5     |           1216  | 0.068 (-430%)
>    LACNIC  |     9     |            442  | 0.357 (+120%)
>    RIPE    |    35     |            738  | 0.794 (+270%)
>    APNIC   |    45     |           4476  | 0.168 ( -57%)
>    --------+-----------+-----------------+----------------
>    total   |   130     |           7451  | 0.293
> 
> numbers taken from
> https://en.wikipedia.org/wiki/List_of_continents_by_population
> 
> Kind regards,
> 
> Job
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public
> Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 ppml at rsuc.gweep.net  Sun Jan 22 12:29:27 2017
From: ppml at rsuc.gweep.net (Joe Provo)
Date: Sun, 22 Jan 2017 12:29:27 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
 <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
Message-ID: <20170122172927.GA45073@gweep.net>

On Fri, Jan 20, 2017 at 05:29:29PM -0800, Owen DeLong wrote:
> The reciprocity requirement merely requires that the policies
> ALLOW transfers in both directions.
> 
> I do not believe that allowing transfers to an RIR which will not
> allow transfers out is reasonable or prudent and this belief has
> nothing to do with maintenance or protection of a free pool. If we
> will allow transfers between RIRs, then the policies by which they
> are allowed should be fair, balanced, and symmetrical. This does
> not mean that I expect the ratio of actual transfers to be balanced
> or symmetrical, merely that the policies under which they are
> conducted should be.

I'm with Owen on this. 

For folks who think asymmetric transfers in this context 
(co-operating RIRs) is OK, how do they feel regarding such 
transfers in other contexts?  I'm specifically thinking of
asymmetric lock-in transfers to certain NIRs who require 
resources used within their legislative boundary be in 
their registry. I'm concerned that even a conditional 
door open here sets a precedent for enabling such reduced 
resource fluidity. 

IMNSHO, that way leads to enabling Balkanization.

Cheers!

Joe

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 


From mike at iptrading.com  Mon Jan 23 11:41:38 2017
From: mike at iptrading.com (Mike Burns)
Date: Mon, 23 Jan 2017 11:41:38 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
 <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
Message-ID: <002c01d27597$9131b0b0$b3951210$@iptrading.com>

Hi Owen,

May I point out that despite reciprocity with APNIC, almost no addresses
have flowed from APNIC to ARIN?  I think less than a /17 in aggregate since
the first interregional transfer in 2012.

You are correct in your expectation that actual transfers aren't
symmetrical, because they respond to market forces.

So we are saying to the address-poor regions of the globe that we refuse to
send our addresses to them because we are standing on principal, even if
that principal has little real effect.

The communities in these regions can regard the history of allocations and
reasonably come to the conclusion that they have been shortchanged.  Thus
they might feel less inclined to stand on that principal of reciprocal
trade, which I agree is the best policy.

I talked to some LACNIC members who expressed an unusual fear to me, a fear
based on the difference in economic realities in the Southern versus the
Northern Hemisphere in the Americas. The fear was that poorer LACNIC members
would decide to re-engineer their networks to take maximum advantage of
CGNAT for the purposes of selling their addresses, and the fear is that
these sales will be to the richer regions of the world, resulting in outflow
and degraded local Internet.  Thus a potential danger is present in some
minds which a unidirectional policy would obviate.

This reminds me of when ARIN also required reciprocity in needs-testing. In
my opinion, the ARIN community used its historical imbalance of address
allocations to cudgel the APNIC community into changing their policies to
meet ARIN's demands, for a likewise minimal effect, in order to stand on the
principal of needs-testing.  At least needs-testing had historical
antecedent in the free-pool allocation policies. However there never was any
history of reciprocity in inter-regional transfer policy, that seems to be a
new principal and not one worth engendering conflict with LACNIC and
AFRINIC.

As far as this policy opening the door or setting a dangerous precedent, may
I point out that this one-way policy has been operational for years
regarding certain Asian NIRs, and the precedent has not proved dangerous.

Regards,
Mike




 


-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Friday, January 20, 2017 8:29 PM
To: Mike Burns <mike at iptrading.com>
Cc: Job Snijders <job at ntt.net>; Scott Leibrand <scottleibrand at gmail.com>;
ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility

The reciprocity requirement merely requires that the policies ALLOW
transfers in both directions.

I do not believe that allowing transfers to an RIR which will not allow
transfers out is reasonable or prudent and this belief has nothing to do
with maintenance or protection of a free pool. If we will allow transfers
between RIRs, then the policies by which they are allowed should be fair,
balanced, and symmetrical. This does not mean that I expect the ratio of
actual transfers to be balanced or symmetrical, merely that the policies
under which they are conducted should be.

Owen

> On Jan 20, 2017, at 09:48 , Mike Burns <mike at iptrading.com> wrote:
> 
> I forget where the original numbers came from, but with a total of 
> 130, obviously many /8s are missing.
> Probably this count is not considering legacy space, most of which is 
> North American.
> Including those legacy addresses, the supply for much of the transfer 
> market, the ratios are much more in ARIN's favor.
> 
> Regards,
> Mike
> 
> 
> 
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Job 
> Snijders
> Sent: Friday, January 20, 2017 7:23 AM
> To: Scott Leibrand <scottleibrand at gmail.com>
> Cc: ARIN-PPML List <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy 
> compatibility
> 
> On Thu, Jan 19, 2017 at 05:40:55PM -0800, Scott Leibrand wrote:
>> Why is average /8s per continent the right metric there?  Wouldn't
>> IPv4 addresses per capita be more like what we're looking for?  I 
>> haven't run the numbers, but I suspect the ARIN region is higher than 
>> all four of the other RIRs in terms of IPv4 addresses per capita.  If 
>> so, then simply removing "reciprocal," would have the same effect (of 
>> allowing transfers to regions with more need for IPv4 addresses than 
>> the ARIN region) and be much simpler.
> 
>    Region  | /8 count  | population (mm) | ipv4 per capita (+/- avg)
>    --------+-----------+-----------------+-------------------------
>    ARIN    |    36     |            579  | 1.043 (+355%)
>    AFRINIC |     5     |           1216  | 0.068 (-430%)
>    LACNIC  |     9     |            442  | 0.357 (+120%)
>    RIPE    |    35     |            738  | 0.794 (+270%)
>    APNIC   |    45     |           4476  | 0.168 ( -57%)
>    --------+-----------+-----------------+----------------
>    total   |   130     |           7451  | 0.293
> 
> numbers taken from
> https://en.wikipedia.org/wiki/List_of_continents_by_population
> 
> Kind regards,
> 
> Job
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From bill at herrin.us  Mon Jan 23 12:02:14 2017
From: bill at herrin.us (William Herrin)
Date: Mon, 23 Jan 2017 12:02:14 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <002c01d27597$9131b0b0$b3951210$@iptrading.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
 <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
 <002c01d27597$9131b0b0$b3951210$@iptrading.com>
Message-ID: <CAP-guGWmZJOYYWRK5tw97LM6XbHqvEnonUW2ZAVws_khfRDirQ@mail.gmail.com>

On Mon, Jan 23, 2017 at 11:41 AM, Mike Burns <mike at iptrading.com> wrote:
> May I point out that despite reciprocity with APNIC, almost no addresses
> have flowed from APNIC to ARIN?  I think less than a /17 in aggregate since
> the first interregional transfer in 2012.
>
> You are correct in your expectation that actual transfers aren't
> symmetrical, because they respond to market forces.
>
> As far as this policy opening the door or setting a dangerous precedent, may
> I point out that this one-way policy has been operational for years
> regarding certain Asian NIRs, and the precedent has not proved dangerous.

Yeah. Market forces. The APNIC NIR non-reciprocity scam has nothing to
do with the imbalance.


> I talked to some LACNIC members who expressed an unusual fear to me, a fear
> based on the difference in economic realities in the Southern versus the
> Northern Hemisphere in the Americas. The fear was that poorer LACNIC members
> would decide to re-engineer their networks to take maximum advantage of
> CGNAT for the purposes of selling their addresses, and the fear is that
> these sales will be to the richer regions of the world, resulting in outflow
> and degraded local Internet.  Thus a potential danger is present in some
> minds which a unidirectional policy would obviate.

LACNIC need not participate in cross-region transfers. Every free
trade agreement between has been to our southern neighbors' benefit.
If they don't want another, why should that be our problem?

Regards,
Bill Herrin


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


From mike at iptrading.com  Mon Jan 23 12:06:22 2017
From: mike at iptrading.com (Mike Burns)
Date: Mon, 23 Jan 2017 12:06:22 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <CAP-guGWmZJOYYWRK5tw97LM6XbHqvEnonUW2ZAVws_khfRDirQ@mail.gmail.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
 <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
 <002c01d27597$9131b0b0$b3951210$@iptrading.com>
 <CAP-guGWmZJOYYWRK5tw97LM6XbHqvEnonUW2ZAVws_khfRDirQ@mail.gmail.com>
Message-ID: <004001d2759b$05c23500$11469f00$@iptrading.com>

Hi Bill,

There are very few transfers into one-way recipient NIRs, nothing substantial that I can find.
Also this type of setup is the opposite of those free trade agreements, it means American exports and dollars flowing into our region.
I agree the best situation would be for every RIR to allow addresses to flow like packets, across borders.
I hope that will eventually be the case in the world and I will try to make it so.
This is a step towards that.

Regards,
Mike



-----Original Message-----
From: William Herrin [mailto:bill at herrin.us] 
Sent: Monday, January 23, 2017 12:02 PM
To: Mike Burns <mike at iptrading.com>
Cc: Owen DeLong <owen at delong.com>; ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility

On Mon, Jan 23, 2017 at 11:41 AM, Mike Burns <mike at iptrading.com> wrote:
> May I point out that despite reciprocity with APNIC, almost no 
> addresses have flowed from APNIC to ARIN?  I think less than a /17 in 
> aggregate since the first interregional transfer in 2012.
>
> You are correct in your expectation that actual transfers aren't 
> symmetrical, because they respond to market forces.
>
> As far as this policy opening the door or setting a dangerous 
> precedent, may I point out that this one-way policy has been 
> operational for years regarding certain Asian NIRs, and the precedent has not proved dangerous.

Yeah. Market forces. The APNIC NIR non-reciprocity scam has nothing to do with the imbalance.


> I talked to some LACNIC members who expressed an unusual fear to me, a 
> fear based on the difference in economic realities in the Southern 
> versus the Northern Hemisphere in the Americas. The fear was that 
> poorer LACNIC members would decide to re-engineer their networks to 
> take maximum advantage of CGNAT for the purposes of selling their 
> addresses, and the fear is that these sales will be to the richer 
> regions of the world, resulting in outflow and degraded local 
> Internet.  Thus a potential danger is present in some minds which a unidirectional policy would obviate.

LACNIC need not participate in cross-region transfers. Every free trade agreement between has been to our southern neighbors' benefit.
If they don't want another, why should that be our problem?

Regards,
Bill Herrin


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



From mje at posix.co.za  Mon Jan 23 12:34:25 2017
From: mje at posix.co.za (Mark Elkins)
Date: Mon, 23 Jan 2017 19:34:25 +0200
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <004001d2759b$05c23500$11469f00$@iptrading.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
 <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
 <002c01d27597$9131b0b0$b3951210$@iptrading.com>
 <CAP-guGWmZJOYYWRK5tw97LM6XbHqvEnonUW2ZAVws_khfRDirQ@mail.gmail.com>
 <004001d2759b$05c23500$11469f00$@iptrading.com>
Message-ID: <e14ff113-93ac-160e-3031-0c7561b825e4@posix.co.za>

Thanks Bill for what looks like support to the one-sided AFRINIC policy.
I agree largely with your observations. Of course, I'd prefer to see a
balanced, reciprocal policy.  I did actually have one in but withdrew it
as I'm too busy with my own troubles and didn't have the time to
properly devote. Getting a one-sided policy into place is the first step
to getting a proper reciprocating policy in. We only recently had a
"local" transfer policy completed. I doubt the one sided policy will do
any damage and like I said, we'll introduce the appropriate amendments
soon, though getting it past may take a while. Africans still live with
the memory of the rape of natural resources.


On 23/01/2017 19:06, Mike Burns wrote:
> Hi Bill,
>
> There are very few transfers into one-way recipient NIRs, nothing substantial that I can find.
> Also this type of setup is the opposite of those free trade agreements, it means American exports and dollars flowing into our region.
> I agree the best situation would be for every RIR to allow addresses to flow like packets, across borders.
> I hope that will eventually be the case in the world and I will try to make it so.
> This is a step towards that.
>
> Regards,
> Mike
>
>
>
> -----Original Message-----
> From: William Herrin [mailto:bill at herrin.us] 
> Sent: Monday, January 23, 2017 12:02 PM
> To: Mike Burns <mike at iptrading.com>
> Cc: Owen DeLong <owen at delong.com>; ARIN-PPML List <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
>
> On Mon, Jan 23, 2017 at 11:41 AM, Mike Burns <mike at iptrading.com> wrote:
>> May I point out that despite reciprocity with APNIC, almost no 
>> addresses have flowed from APNIC to ARIN?  I think less than a /17 in 
>> aggregate since the first interregional transfer in 2012.
>>
>> You are correct in your expectation that actual transfers aren't 
>> symmetrical, because they respond to market forces.
>>
>> As far as this policy opening the door or setting a dangerous 
>> precedent, may I point out that this one-way policy has been 
>> operational for years regarding certain Asian NIRs, and the precedent has not proved dangerous.
> Yeah. Market forces. The APNIC NIR non-reciprocity scam has nothing to do with the imbalance.
>
>
>> I talked to some LACNIC members who expressed an unusual fear to me, a 
>> fear based on the difference in economic realities in the Southern 
>> versus the Northern Hemisphere in the Americas. The fear was that 
>> poorer LACNIC members would decide to re-engineer their networks to 
>> take maximum advantage of CGNAT for the purposes of selling their 
>> addresses, and the fear is that these sales will be to the richer 
>> regions of the world, resulting in outflow and degraded local 
>> Internet.  Thus a potential danger is present in some minds which a unidirectional policy would obviate.
> LACNIC need not participate in cross-region transfers. Every free trade agreement between has been to our southern neighbors' benefit.
> If they don't want another, why should that be our problem?
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin ................ herrin at dirtside.com  bill at herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za



From owen at delong.com  Mon Jan 23 18:55:15 2017
From: owen at delong.com (Owen DeLong)
Date: Mon, 23 Jan 2017 15:55:15 -0800
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <002c01d27597$9131b0b0$b3951210$@iptrading.com>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
 <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
 <002c01d27597$9131b0b0$b3951210$@iptrading.com>
Message-ID: <C2AAEBCC-4B85-495C-B9F0-C3037B96CCB6@delong.com>


> On Jan 23, 2017, at 08:41 , Mike Burns <mike at iptrading.com> wrote:
> 
> Hi Owen,
> 
> May I point out that despite reciprocity with APNIC, almost no addresses
> have flowed from APNIC to ARIN?  I think less than a /17 in aggregate since
> the first interregional transfer in 2012.

I?m well aware of this. What I don?t know is why you would consider that a relevant point.

My reasons for wanting to preserve the requirement of reciprocity are much more a matter of
principle and along the lines of Joe?s concerns about balkanization with NIRs such as CNNIC?s
abhorrent policy of ?addresses check in but they don?t check out and all addresses used in CN
must be in CNNIC?.

> You are correct in your expectation that actual transfers aren't
> symmetrical, because they respond to market forces.

Right, so I see no need to abandon the requirement of reciprocity, nor do I see a reason for
the other RIRs to avoid providing a reciprocal policy if they want to play on the worldwide
transfer stage.

> So we are saying to the address-poor regions of the globe that we refuse to
> send our addresses to them because we are standing on principal, even if
> that principal has little real effect.

I suppose if you want to put it that way, modulo the misuse of principal vs. principle,
yes, that?s similar to what I am saying. What I would say is that rather, we are not
buckling to pressure to create harmful asymmetric policies simply because the regions that
want us to do so happen to be some of the most address-poor regions in existence.

Frankly, I?m personally tempted at this point to throw my hands up and let IPv4 become an even
more obvious cesspool of disaggregation and watch the melting of the IPv4 routing table
become the driving force for urgent IPv6 adoption. However, that?s not in line with the
responsibilities I have to the community in my elected position of trust or the principals
of good stewardship.

So, for now, I will continue to make the principled argument against asymmetric transfer
policies because I believe the precedent they create is harmful. We already have two rather
awful examples of where such policies are causing real problems (CNNIC and VNNIC) and I
do not want to do anything to encourage expansion of this precedent.

> The communities in these regions can regard the history of allocations and
> reasonably come to the conclusion that they have been shortchanged.  Thus
> they might feel less inclined to stand on that principal of reciprocal
> trade, which I agree is the best policy.

They can have all the IPv6 they want, so the other way they could look at this is that they?ve
been allowed to avoid the whole overhead of additional IPv4 deployment in favor of leapfrogging
the technology to IPv6.

However, neither of these perspectives is completely accurate or useful in the discussion at hand.

> I talked to some LACNIC members who expressed an unusual fear to me, a fear
> based on the difference in economic realities in the Southern versus the
> Northern Hemisphere in the Americas. The fear was that poorer LACNIC members
> would decide to re-engineer their networks to take maximum advantage of
> CGNAT for the purposes of selling their addresses, and the fear is that
> these sales will be to the richer regions of the world, resulting in outflow
> and degraded local Internet.  Thus a potential danger is present in some
> minds which a unidirectional policy would obviate.

Except that it won?t really do anything to change that. All it will do is limit the
sales of those addresses to the northern companies that have operations (or create the
appearance of operations) in those southern regions.

> This reminds me of when ARIN also required reciprocity in needs-testing. In
> my opinion, the ARIN community used its historical imbalance of address
> allocations to cudgel the APNIC community into changing their policies to
> meet ARIN's demands, for a likewise minimal effect, in order to stand on the
> principal of needs-testing.  At least needs-testing had historical
> antecedent in the free-pool allocation policies. However there never was any
> history of reciprocity in inter-regional transfer policy, that seems to be a
> new principal and not one worth engendering conflict with LACNIC and
> AFRINIC.

To the best of my knowledge the compatible needs-basis requirement has not been
amended since it was put in place as you describe. Yes, APNIC chose to modify
their transfer policy in support of being able to work with ARIN on inter-RIR
transfers. If you want to call that a cudgel, then that is your right. I call it
a great example of how making a principled argument and good policy can actually
create positive change.

> As far as this policy opening the door or setting a dangerous precedent, may
> I point out that this one-way policy has been operational for years
> regarding certain Asian NIRs, and the precedent has not proved dangerous.

Actually, it has proved quite harmful IMHO. I?m not at liberty to disclose the
specifics of any of them, but I know of several situations where organizations
wanting to do business within those jurisdictions have been forced to obtain and
transfer addresses out of their control at their expense with no hope of ever
regaining control of those addresses even if they shut down their operations in
the jurisdictions in question as a result.

I suggest you discuss the matter with a few multinational organizations that have
any sort of significant operational footprint within the jurisdictions in question
before you declare such policies harmless.

Owen

> 
> Regards,
> Mike
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Friday, January 20, 2017 8:29 PM
> To: Mike Burns <mike at iptrading.com>
> Cc: Job Snijders <job at ntt.net>; Scott Leibrand <scottleibrand at gmail.com>;
> ARIN-PPML List <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
> 
> The reciprocity requirement merely requires that the policies ALLOW
> transfers in both directions.
> 
> I do not believe that allowing transfers to an RIR which will not allow
> transfers out is reasonable or prudent and this belief has nothing to do
> with maintenance or protection of a free pool. If we will allow transfers
> between RIRs, then the policies by which they are allowed should be fair,
> balanced, and symmetrical. This does not mean that I expect the ratio of
> actual transfers to be balanced or symmetrical, merely that the policies
> under which they are conducted should be.
> 
> Owen
> 
>> On Jan 20, 2017, at 09:48 , Mike Burns <mike at iptrading.com> wrote:
>> 
>> I forget where the original numbers came from, but with a total of 
>> 130, obviously many /8s are missing.
>> Probably this count is not considering legacy space, most of which is 
>> North American.
>> Including those legacy addresses, the supply for much of the transfer 
>> market, the ratios are much more in ARIN's favor.
>> 
>> Regards,
>> Mike
>> 
>> 
>> 
>> -----Original Message-----
>> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Job 
>> Snijders
>> Sent: Friday, January 20, 2017 7:23 AM
>> To: Scott Leibrand <scottleibrand at gmail.com>
>> Cc: ARIN-PPML List <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy 
>> compatibility
>> 
>> On Thu, Jan 19, 2017 at 05:40:55PM -0800, Scott Leibrand wrote:
>>> Why is average /8s per continent the right metric there?  Wouldn't
>>> IPv4 addresses per capita be more like what we're looking for?  I 
>>> haven't run the numbers, but I suspect the ARIN region is higher than 
>>> all four of the other RIRs in terms of IPv4 addresses per capita.  If 
>>> so, then simply removing "reciprocal," would have the same effect (of 
>>> allowing transfers to regions with more need for IPv4 addresses than 
>>> the ARIN region) and be much simpler.
>> 
>>   Region  | /8 count  | population (mm) | ipv4 per capita (+/- avg)
>>   --------+-----------+-----------------+-------------------------
>>   ARIN    |    36     |            579  | 1.043 (+355%)
>>   AFRINIC |     5     |           1216  | 0.068 (-430%)
>>   LACNIC  |     9     |            442  | 0.357 (+120%)
>>   RIPE    |    35     |            738  | 0.794 (+270%)
>>   APNIC   |    45     |           4476  | 0.168 ( -57%)
>>   --------+-----------+-----------------+----------------
>>   total   |   130     |           7451  | 0.293
>> 
>> numbers taken from
>> https://en.wikipedia.org/wiki/List_of_continents_by_population
>> 
>> Kind regards,
>> 
>> Job
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN 
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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 kevinb at thewire.ca  Mon Jan 23 20:23:16 2017
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Tue, 24 Jan 2017 01:23:16 +0000
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <20170122172927.GA45073@gweep.net>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
 <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
 <20170122172927.GA45073@gweep.net>
Message-ID: <7E7773B523E82C478734E793E58F69E78E4DC8F4@SBS2011.thewireinc.local>

Joe,

The asymmetric transfers you mention below are allowed from my understanding.

RIR<->RIR->NIR

I remember this being discussed at the last ARIN meeting. If staff could confirm my basic diagram that would be appreciated.

I believe at least for LACNIC and AFRNIC there should be a waiver if requested, not a removal of reciprocity from the entire section.

Kevin Blumberg










-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Provo
Sent: Sunday, January 22, 2017 12:29 PM
To: ARIN-PPML List <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility

On Fri, Jan 20, 2017 at 05:29:29PM -0800, Owen DeLong wrote:
> The reciprocity requirement merely requires that the policies ALLOW 
> transfers in both directions.
> 
> I do not believe that allowing transfers to an RIR which will not 
> allow transfers out is reasonable or prudent and this belief has 
> nothing to do with maintenance or protection of a free pool. If we 
> will allow transfers between RIRs, then the policies by which they are 
> allowed should be fair, balanced, and symmetrical. This does not mean 
> that I expect the ratio of actual transfers to be balanced or 
> symmetrical, merely that the policies under which they are conducted 
> should be.

I'm with Owen on this. 

For folks who think asymmetric transfers in this context (co-operating RIRs) is OK, how do they feel regarding such transfers in other contexts?  I'm specifically thinking of asymmetric lock-in transfers to certain NIRs who require resources used within their legislative boundary be in their registry. I'm concerned that even a conditional door open here sets a precedent for enabling such reduced resource fluidity. 

IMNSHO, that way leads to enabling Balkanization.

Cheers!

Joe

--
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From farmer at umn.edu  Tue Jan 24 10:04:08 2017
From: farmer at umn.edu (David Farmer)
Date: Tue, 24 Jan 2017 09:04:08 -0600
Subject: [arin-ppml] Draft Policy 2016-7 -- Integrate community networks
 into Existing ISP Policy
In-Reply-To: <CAN-Dau0kCCNxDvCTZgwudnzLN3Yt2o-xu6gMYcb0Dc5igWRU5Q@mail.gmail.com>
References: <E71D08A9-DAB5-49DF-B15C-B001EE02C857@delong.com>
 <7E7773B523E82C478734E793E58F69E78E422684@SBS2011.thewireinc.local>
 <5eeb6493-7fd6-5f55-e47a-4294bd739771@quark.net>
 <CAN-Dau0kCCNxDvCTZgwudnzLN3Yt2o-xu6gMYcb0Dc5igWRU5Q@mail.gmail.com>
Message-ID: <CAN-Dau1mC56j6SYTJvdpsjcAPjkbqLxCwkrezfbFP0O=cMRZWw@mail.gmail.com>

I have not seen evidence that there is sufficient interest by the ARIN
policy community to justify continued work on this policy, and therefore
I'm forced to conclude it should be abandoned.

However, If you are interested in seeing this policy worked on, please
respond to this thread on PPML before the end of business Thursday.

Thanks.

On Tue, Jan 17, 2017 at 1:42 PM, David Farmer <farmer at umn.edu> wrote:

> It concerns me that no one that operates a community network has commented
> on this policy.  Further it concerns me that no one from the general ARIN
> policy community commented either, only AC members and a former AC member
> who is also the policy author have made any comments.
>
> Is there interest from the ARIN policy community to work on this or are
> their other priorities for the community's time?
>
> It would be helpful to hear from others in regards to if this is something
> we should be working on or not.
>
> Thanks.
>
> On Sun, Dec 18, 2016 at 2:58 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>
>> It would be especially helpful for the AC if those who operate community
>> networks could review the proposed draft policy and see if the problem
>> statement highlights an issue for operators and if the proposed text solves
>> this problem.
>>
>> Thanks,
>> Andrew
>>
>>
>>
>> On 12/15/2016 3:30 PM, Kevin Blumberg wrote:
>>
>> Owen,
>>
>> As the author of 2016-7 I disagree.
>>
>> The change in 2016-6 had no meaningful impact to the usefulness of Community
>> Networks. T
>>
>> The purpose of 2016-7 was to significantly reduce the red tape requirements
>> with Community Networks.
>>
>> I believe that without this kind of policy Community Network's will never
>> get used given the onerous requirements.
>>
>> Thanks,
>>
>> Kevin Blumberg
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>] On Behalf Of Owen DeLong
>> Sent: Thursday, December 15, 2016 4:19 PM
>> To: ARIN-PPML List <arin-ppml at arin.net> <arin-ppml at arin.net>
>> Subject: [arin-ppml] Draft Policy 2016-7 -- Integrate community networks
>> into Existing ISP Policy
>>
>> I believe that this proposal no longer has relevance given the advancement
>> of 2016-6 and its rewrite of the community networks policy to the board.
>>
>> If anyone feels that the AC should not abandon this proposal at their
>> January meeting, please speak up.
>>
>> Owen
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN Public
>> Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>



-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170124/d8d43d37/attachment.htm>

From 3johnl at gmail.com  Tue Jan 24 15:32:48 2017
From: 3johnl at gmail.com (John Springer)
Date: Tue, 24 Jan 2017 12:32:48 -0800
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text
 modifications
Message-ID: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>

Greetings PPML,

After discussions between the author, shepherds and the AC, the text of
ARIN Draft Policy 2016-9, Streamline Merger & Acquisition Transfers has
been modified for clarity.

Please reply with thoughts and feedback. They will be very welcome.
Thank you in advance.

New text:

Problem Statement:
In the case of a merger or acquisition, current policy encourages not
updating registration data, thus leaving the number resource in the name of
a now defunct entity.
It is not uncommon for an entity which has bought another entity (with
existing number resources) to leave Organizational data (Whois) in the name
of the acquired company. The requirements in Section 8.2 put a
justification burden on the acquiring organization, which was a legitimate
protection while free pool assignments were available. It is worth
revisiting Section 8.2 and looking for opportunities to simplify the policy
in the interest of improving the registry data.
Consider the following:
1. In the case where both organizations (acquirer, acquired) have justified
their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN)
under the policies that were in force at the time of issuance, the number
resources have already been justified once.
2. ARIN does not customarily require organizations holding address space to
document utilization except when they are asking ARIN to issue more space.
3. Section 8.2 M&A is not asking ARIN to issue more space or provide
authorization to acquire space in an 8.3 transfer. It is simply updating
ARIN's database to reflect the current reality, that being that control of
a company has changed.
Language that speaks of required return or transfer of space is of
questionable enforceability in the context of the current RSA (section 6,
"ARIN has no right to revoke any Included Number Resources under this
Agreement due to lack of utilization by Holder").
Clauses that serve to scare organizations away from updating their
information are counter to the goal of good data in whois.
Policy should allow ARIN staff to concentrate finite resources on
ascertaining corporate chain of custody so as to minimize the chance of
fraudulent transfers rather than auditing space already issued.
Policy statement:
Delete the bullet point that reads:
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.
Add this conditional to the bottom of 8.2 for linguistic clarity:
"AND one or more of the following:
The recipient must provide independently verifiable evidence that they have
acquired the assets that use the resources to be transferred from the
current registrant.
OR
The recipient must show that they have acquired the entire corporate entity
which is the current registrant."
Remove the following paragraph from Section 8.2 of the NRPM:
ARIN will proceed with processing transfer requests even if the number
resources of the combined organizations exceed what can be justified under
current ARIN policy. 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.
These two changes will leave Section 8.2 looking like this:
8.2. Mergers and Acquisitions
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.
AND one or more of the following:
The recipient must provide independently verifiable evidence that they have
acquired the assets that use the resources to be transferred from the
current registrant.
OR
The recipient must show that they have acquired the entire corporate entity
which is the current registrant.
Timetable for implementation: Immediate

Old text:

Problem Statement:
It is not uncommon for an entity which has bought another entity (with
existing number resources) to leave Organizational data (Whois) in the name
of the acquired company. The requirements in Section 8.2 put a
justification burden on the acquiring organization, which was a legitimate
protection while free pool assignments were available. It is worth
revisiting Section 8.2 and looking for opportunities to simplify the policy
in the interest of improving the registry data.
Consider the following:
1. Both organizations (acquirer, acquired) have justified their existing
number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the
policies that were in force at the time of issuance. In short, the number
resources have already been justified once.
2. ARIN does not customarily require organizations holding address space to
document utilization except when they are asking ARIN to issue more space.
3. Section 8.2 M&A is not asking ARIN to issue more space or provide
authorization to acquire space in an 8.3 transfer. It is simply updating
ARIN's database to reflect the current reality, that being that control of
a company has changed.
Language that speaks of required return or transfer of space is of
questionable enforceability in the context of the current RSA (section 6,
"ARIN has no right to revoke any Included Number Resources under this
Agreement due to lack of utilization by Holder").
Clauses that serve to scare organizations away from updating their
information are counter to the goal of good data in whois.
Policy should allow ARIN staff to concentrate finite resources on
ascertaining corporate chain of custody so as to minimize the chance of
fraudulent transfers rather than auditing space already issued.
This proposal suggests two changes: a paragraph change to better reflect
current practice, harmonize nomenclature with 8.3 ("new entity" vs
"recipient") and remove an operationally-focused sentence, and a paragraph
removal as it is the author's opinion that this paragraph has outlived its
usefulness.
Policy statement:
Replace the following paragraph:
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.
with this conditional, moving it to the bottom of 8.2 for linguistic
clarity:
AND one or more of the following:
The recipient must provide independently verifiable evidence that they have
acquired the assets that use the resources to be transferred from the
current registrant.
OR
The recipient must show that they have acquired the entire corporate entity
which is the current registrant.
Remove the following paragraph from Section 8.2 of the NRPM:
In the event that number resources of the combined organizations are no
longer justified under ARIN policy at the time ARIN becomes aware of the
transaction, through a transfer request or otherwise, ARIN will work with
the resource holder(s) to return or transfer resources as needed to restore
compliance via the processes outlined in current ARIN policy.
These two changes will leave Section 8.2 looking like this:
8.2. Mergers and Acquisitions
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.
AND one or more of the following:
The recipient must provide independently verifiable evidence that they have
acquired the assets that use the resources to be transferred from the
current registrant.
OR
The recipient must show that they have acquired the entire corporate entity
which is the current registrant.
Timetable for implementation: Immediate

regards

John Springer
ARIN AC member and shepherd of 2016-9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170124/a10dcde0/attachment.htm>

From mike at iptrading.com  Tue Jan 24 15:58:59 2017
From: mike at iptrading.com (Mike Burns)
Date: Tue, 24 Jan 2017 15:58:59 -0500
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
Message-ID: <01d201d27684$afbaa0d0$0f2fe270$@iptrading.com>

Hi John,

 

Support. 

Let?s not let policy artifacts from the free-pool era contribute to Whois inaccuracy.

 

Mike Burns

 

 

 

From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Springer
Sent: Tuesday, January 24, 2017 3:33 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

 

Greetings PPML,

 

After discussions between the author, shepherds and the AC, the text of ARIN Draft Policy 2016-9, Streamline Merger & Acquisition Transfers has been modified for clarity.

 

Please reply with thoughts and feedback. They will be very welcome.

Thank you in advance.

 

New text:

 

Problem Statement:

In the case of a merger or acquisition, current policy encourages not updating registration data, thus leaving the number resource in the name of a now defunct entity.

It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data.

Consider the following:

1. In the case where both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance, the number resources have already been justified once.

2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space.

3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that being that control of a company has changed.

Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder").

Clauses that serve to scare organizations away from updating their information are counter to the goal of good data in whois.

Policy should allow ARIN staff to concentrate finite resources on ascertaining corporate chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued.

Policy statement:

Delete the bullet point that reads:

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.

Add this conditional to the bottom of 8.2 for linguistic clarity:

"AND one or more of the following:

The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.

OR

The recipient must show that they have acquired the entire corporate entity which is the current registrant."

Remove the following paragraph from Section 8.2 of the NRPM:

ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN policy. 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.

These two changes will leave Section 8.2 looking like this:

8.2. Mergers and Acquisitions

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.

AND one or more of the following:

The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.

OR

The recipient must show that they have acquired the entire corporate entity which is the current registrant.

Timetable for implementation: Immediate

 

Old text:

 

Problem Statement:

It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data.

Consider the following:

1. Both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance. In short, the number resources have already been justified once.

2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space.

3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that being that control of a company has changed.

Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder").

Clauses that serve to scare organizations away from updating their information are counter to the goal of good data in whois.

Policy should allow ARIN staff to concentrate finite resources on ascertaining corporate chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued.

This proposal suggests two changes: a paragraph change to better reflect current practice, harmonize nomenclature with 8.3 ("new entity" vs "recipient") and remove an operationally-focused sentence, and a paragraph removal as it is the author's opinion that this paragraph has outlived its usefulness.

Policy statement:

Replace the following paragraph:

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.

with this conditional, moving it to the bottom of 8.2 for linguistic clarity:

AND one or more of the following:

The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.

OR

The recipient must show that they have acquired the entire corporate entity which is the current registrant.

Remove the following paragraph from Section 8.2 of the NRPM:

In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy.

These two changes will leave Section 8.2 looking like this:

8.2. Mergers and Acquisitions

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.

AND one or more of the following:

The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.

OR

The recipient must show that they have acquired the entire corporate entity which is the current registrant.

Timetable for implementation: Immediate

 

regards

 

John Springer

ARIN AC member and shepherd of 2016-9

 

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

From daveid at panix.com  Tue Jan 24 16:34:01 2017
From: daveid at panix.com (David Huberman)
Date: Tue, 24 Jan 2017 16:34:01 -0500
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
Message-ID: <8D102BBA-4B4D-45E7-BA7D-2800D53B6333@panix.com>

Strongly support.  A good direction for the users of Whois, and for proponents of common sense.


Sent from my iPhone

> On Jan 24, 2017, at 3:32 PM, John Springer <3johnl at gmail.com> wrote:
> 
> Greetings PPML,
> 
> After discussions between the author, shepherds and the AC, the text of ARIN Draft Policy 2016-9, Streamline Merger & Acquisition Transfers has been modified for clarity.
> 
> Please reply with thoughts and feedback. They will be very welcome.
> Thank you in advance.
> 
> New text:
> 
> Problem Statement:
> In the case of a merger or acquisition, current policy encourages not updating registration data, thus leaving the number resource in the name of a now defunct entity.
> It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data.
> Consider the following:
> 1. In the case where both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance, the number resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that being that control of a company has changed.
> Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on ascertaining corporate chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued.
> Policy statement:
> Delete the bullet point that reads:
> 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.
> Add this conditional to the bottom of 8.2 for linguistic clarity:
> "AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant."
> Remove the following paragraph from Section 8.2 of the NRPM:
> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN policy. 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.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> Timetable for implementation: Immediate
> 
> Old text:
> 
> Problem Statement:
> It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data.
> Consider the following:
> 1. Both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance. In short, the number resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that being that control of a company has changed.
> Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on ascertaining corporate chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued.
> This proposal suggests two changes: a paragraph change to better reflect current practice, harmonize nomenclature with 8.3 ("new entity" vs "recipient") and remove an operationally-focused sentence, and a paragraph removal as it is the author's opinion that this paragraph has outlived its usefulness.
> Policy statement:
> Replace the following paragraph:
> 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.
> with this conditional, moving it to the bottom of 8.2 for linguistic clarity:
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> Remove the following paragraph from Section 8.2 of the NRPM:
> In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> Timetable for implementation: Immediate
> 
> regards
> 
> John Springer
> ARIN AC member and shepherd of 2016-9
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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  Tue Jan 24 16:49:08 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 24 Jan 2017 13:49:08 -0800
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <8D102BBA-4B4D-45E7-BA7D-2800D53B6333@panix.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
 <8D102BBA-4B4D-45E7-BA7D-2800D53B6333@panix.com>
Message-ID: <CAGkMwz6SGOiLfuS1L3EfBm6UvQgYFJtp6zEYzATtB_0eo2f0Aw@mail.gmail.com>

Support.

This proposal would make it easier to get currently-unused and/or
inaccurately-registered addresses into productive use on the Internet,
and/or update their registration to match the entity that is actually and
legitimately using them.

-Scott

On Tue, Jan 24, 2017 at 1:34 PM, David Huberman <daveid at panix.com> wrote:

> Strongly support.  A good direction for the users of Whois, and for
> proponents of common sense.
>
>
> Sent from my iPhone
>
> > On Jan 24, 2017, at 3:32 PM, John Springer <3johnl at gmail.com> wrote:
> >
> > Greetings PPML,
> >
> > After discussions between the author, shepherds and the AC, the text of
> ARIN Draft Policy 2016-9, Streamline Merger & Acquisition Transfers has
> been modified for clarity.
> >
> > Please reply with thoughts and feedback. They will be very welcome.
> > Thank you in advance.
> >
> > New text:
> >
> > Problem Statement:
> > In the case of a merger or acquisition, current policy encourages not
> updating registration data, thus leaving the number resource in the name of
> a now defunct entity.
> > It is not uncommon for an entity which has bought another entity (with
> existing number resources) to leave Organizational data (Whois) in the name
> of the acquired company. The requirements in Section 8.2 put a
> justification burden on the acquiring organization, which was a legitimate
> protection while free pool assignments were available. It is worth
> revisiting Section 8.2 and looking for opportunities to simplify the policy
> in the interest of improving the registry data.
> > Consider the following:
> > 1. In the case where both organizations (acquirer, acquired) have
> justified their existing number resources from an issuer (e.g. SRI-NIC,
> GSI, ARIN) under the policies that were in force at the time of issuance,
> the number resources have already been justified once.
> > 2. ARIN does not customarily require organizations holding address space
> to document utilization except when they are asking ARIN to issue more
> space.
> > 3. Section 8.2 M&A is not asking ARIN to issue more space or provide
> authorization to acquire space in an 8.3 transfer. It is simply updating
> ARIN's database to reflect the current reality, that being that control of
> a company has changed.
> > Language that speaks of required return or transfer of space is of
> questionable enforceability in the context of the current RSA (section 6,
> "ARIN has no right to revoke any Included Number Resources under this
> Agreement due to lack of utilization by Holder").
> > Clauses that serve to scare organizations away from updating their
> information are counter to the goal of good data in whois.
> > Policy should allow ARIN staff to concentrate finite resources on
> ascertaining corporate chain of custody so as to minimize the chance of
> fraudulent transfers rather than auditing space already issued.
> > Policy statement:
> > Delete the bullet point that reads:
> > 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.
> > Add this conditional to the bottom of 8.2 for linguistic clarity:
> > "AND one or more of the following:
> > The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> > OR
> > The recipient must show that they have acquired the entire corporate
> entity which is the current registrant."
> > Remove the following paragraph from Section 8.2 of the NRPM:
> > ARIN will proceed with processing transfer requests even if the number
> resources of the combined organizations exceed what can be justified under
> current ARIN policy. 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.
> > These two changes will leave Section 8.2 looking like this:
> > 8.2. Mergers and Acquisitions
> > 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.
> > AND one or more of the following:
> > The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> > OR
> > The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
> > Timetable for implementation: Immediate
> >
> > Old text:
> >
> > Problem Statement:
> > It is not uncommon for an entity which has bought another entity (with
> existing number resources) to leave Organizational data (Whois) in the name
> of the acquired company. The requirements in Section 8.2 put a
> justification burden on the acquiring organization, which was a legitimate
> protection while free pool assignments were available. It is worth
> revisiting Section 8.2 and looking for opportunities to simplify the policy
> in the interest of improving the registry data.
> > Consider the following:
> > 1. Both organizations (acquirer, acquired) have justified their existing
> number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the
> policies that were in force at the time of issuance. In short, the number
> resources have already been justified once.
> > 2. ARIN does not customarily require organizations holding address space
> to document utilization except when they are asking ARIN to issue more
> space.
> > 3. Section 8.2 M&A is not asking ARIN to issue more space or provide
> authorization to acquire space in an 8.3 transfer. It is simply updating
> ARIN's database to reflect the current reality, that being that control of
> a company has changed.
> > Language that speaks of required return or transfer of space is of
> questionable enforceability in the context of the current RSA (section 6,
> "ARIN has no right to revoke any Included Number Resources under this
> Agreement due to lack of utilization by Holder").
> > Clauses that serve to scare organizations away from updating their
> information are counter to the goal of good data in whois.
> > Policy should allow ARIN staff to concentrate finite resources on
> ascertaining corporate chain of custody so as to minimize the chance of
> fraudulent transfers rather than auditing space already issued.
> > This proposal suggests two changes: a paragraph change to better reflect
> current practice, harmonize nomenclature with 8.3 ("new entity" vs
> "recipient") and remove an operationally-focused sentence, and a paragraph
> removal as it is the author's opinion that this paragraph has outlived its
> usefulness.
> > Policy statement:
> > Replace the following paragraph:
> > 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.
> > with this conditional, moving it to the bottom of 8.2 for linguistic
> clarity:
> > AND one or more of the following:
> > The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> > OR
> > The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
> > Remove the following paragraph from Section 8.2 of the NRPM:
> > In the event that number resources of the combined organizations are no
> longer justified under ARIN policy at the time ARIN becomes aware of the
> transaction, through a transfer request or otherwise, ARIN will work with
> the resource holder(s) to return or transfer resources as needed to restore
> compliance via the processes outlined in current ARIN policy.
> > These two changes will leave Section 8.2 looking like this:
> > 8.2. Mergers and Acquisitions
> > 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.
> > AND one or more of the following:
> > The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> > OR
> > The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
> > Timetable for implementation: Immediate
> >
> > regards
> >
> > John Springer
> > ARIN AC member and shepherd of 2016-9
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage 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/20170124/0790e9be/attachment.htm>

From chris at semihuman.com  Tue Jan 24 17:52:39 2017
From: chris at semihuman.com (Chris Woodfield)
Date: Tue, 24 Jan 2017 17:52:39 -0500
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
Message-ID: <1C0371F2-409D-48EE-9798-AF4F8C3600F6@semihuman.com>

Strongly support. This is a big win for enhancing whois accuracy with no substantial downsides that I can see.

-C

> On Jan 24, 2017, at 3:32 PM, John Springer <3johnl at gmail.com> wrote:
> 
> Greetings PPML,
> 
> After discussions between the author, shepherds and the AC, the text of ARIN Draft Policy 2016-9, Streamline Merger & Acquisition Transfers has been modified for clarity.
> 
> Please reply with thoughts and feedback. They will be very welcome.
> Thank you in advance.
> 
> New text:
> 
> Problem Statement:
> In the case of a merger or acquisition, current policy encourages not updating registration data, thus leaving the number resource in the name of a now defunct entity.
> It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data.
> Consider the following:
> 1. In the case where both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance, the number resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that being that control of a company has changed.
> Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on ascertaining corporate chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued.
> Policy statement:
> Delete the bullet point that reads:
> 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.
> Add this conditional to the bottom of 8.2 for linguistic clarity:
> "AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant."
> Remove the following paragraph from Section 8.2 of the NRPM:
> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN policy. 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.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> Timetable for implementation: Immediate
> 
> Old text:
> 
> Problem Statement:
> It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data.
> Consider the following:
> 1. Both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance. In short, the number resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that being that control of a company has changed.
> Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on ascertaining corporate chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued.
> This proposal suggests two changes: a paragraph change to better reflect current practice, harmonize nomenclature with 8.3 ("new entity" vs "recipient") and remove an operationally-focused sentence, and a paragraph removal as it is the author's opinion that this paragraph has outlived its usefulness.
> Policy statement:
> Replace the following paragraph:
> 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.
> with this conditional, moving it to the bottom of 8.2 for linguistic clarity:
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> Remove the following paragraph from Section 8.2 of the NRPM:
> In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> Timetable for implementation: Immediate
> 
> regards
> 
> John Springer
> ARIN AC member and shepherd of 2016-9
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 oroberts at bell.ca  Tue Jan 24 18:16:14 2017
From: oroberts at bell.ca (Roberts, Orin)
Date: Tue, 24 Jan 2017 23:16:14 +0000
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <1C0371F2-409D-48EE-9798-AF4F8C3600F6@semihuman.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
 <1C0371F2-409D-48EE-9798-AF4F8C3600F6@semihuman.com>
Message-ID: <3af310f182e0403b8b03340f2c66149a@DG2MBX04-DOR.bell.corp.bce.ca>

Agreed it's a step in the right direction. 

Specific to ISP's; I've noted Letters of Authorizations (LOA's) being common, where one organization uses the resources of another - no change to ARIN databases.


Orin Roberts - CCNA,ITILv3

-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Woodfield
Sent: January-24-17 5:53 PM
To: John Springer
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

Strongly support. This is a big win for enhancing whois accuracy with no substantial downsides that I can see.

-C

> On Jan 24, 2017, at 3:32 PM, John Springer <3johnl at gmail.com> wrote:
> 
> Greetings PPML,
> 
> After discussions between the author, shepherds and the AC, the text of ARIN Draft Policy 2016-9, Streamline Merger & Acquisition Transfers has been modified for clarity.
> 
> Please reply with thoughts and feedback. They will be very welcome.
> Thank you in advance.
> 
> New text:
> 
> Problem Statement:
> In the case of a merger or acquisition, current policy encourages not updating registration data, thus leaving the number resource in the name of a now defunct entity.
> It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data.
> Consider the following:
> 1. In the case where both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance, the number resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that being that control of a company has changed.
> Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on ascertaining corporate chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued.
> Policy statement:
> Delete the bullet point that reads:
> 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.
> Add this conditional to the bottom of 8.2 for linguistic clarity:
> "AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant."
> Remove the following paragraph from Section 8.2 of the NRPM:
> ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN policy. 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.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> Timetable for implementation: Immediate
> 
> Old text:
> 
> Problem Statement:
> It is not uncommon for an entity which has bought another entity (with existing number resources) to leave Organizational data (Whois) in the name of the acquired company. The requirements in Section 8.2 put a justification burden on the acquiring organization, which was a legitimate protection while free pool assignments were available. It is worth revisiting Section 8.2 and looking for opportunities to simplify the policy in the interest of improving the registry data.
> Consider the following:
> 1. Both organizations (acquirer, acquired) have justified their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the policies that were in force at the time of issuance. In short, the number resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space to document utilization except when they are asking ARIN to issue more space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide authorization to acquire space in an 8.3 transfer. It is simply updating ARIN's database to reflect the current reality, that being that control of a company has changed.
> Language that speaks of required return or transfer of space is of questionable enforceability in the context of the current RSA (section 6, "ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on ascertaining corporate chain of custody so as to minimize the chance of fraudulent transfers rather than auditing space already issued.
> This proposal suggests two changes: a paragraph change to better reflect current practice, harmonize nomenclature with 8.3 ("new entity" vs "recipient") and remove an operationally-focused sentence, and a paragraph removal as it is the author's opinion that this paragraph has outlived its usefulness.
> Policy statement:
> Replace the following paragraph:
> 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.
> with this conditional, moving it to the bottom of 8.2 for linguistic clarity:
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> Remove the following paragraph from Section 8.2 of the NRPM:
> In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return or transfer resources as needed to restore compliance via the processes outlined in current ARIN policy.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> Timetable for implementation: Immediate
> 
> regards
> 
> John Springer
> ARIN AC member and shepherd of 2016-9
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 alyssa.moore at cybera.ca  Tue Jan 24 18:23:22 2017
From: alyssa.moore at cybera.ca (Alyssa Moore)
Date: Tue, 24 Jan 2017 23:23:22 +0000
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <3af310f182e0403b8b03340f2c66149a@DG2MBX04-DOR.bell.corp.bce.ca>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
 <1C0371F2-409D-48EE-9798-AF4F8C3600F6@semihuman.com>
 <3af310f182e0403b8b03340f2c66149a@DG2MBX04-DOR.bell.corp.bce.ca>
Message-ID: <CALdayyE83P5JL1XhNbXYJb95EDVQb2=z1DKmtgLy=B0_KB5zHA@mail.gmail.com>

Tossing my support onto the pile for this one.

On Tue, Jan 24, 2017 at 4:16 PM Roberts, Orin <oroberts at bell.ca> wrote:

> Agreed it's a step in the right direction.
>
> Specific to ISP's; I've noted Letters of Authorizations (LOA's) being
> common, where one organization uses the resources of another - no change to
> ARIN databases.
>
>
> Orin Roberts - CCNA,ITILv3
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris
> Woodfield
> Sent: January-24-17 5:53 PM
> To: John Springer
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers
> - Text modifications
>
> Strongly support. This is a big win for enhancing whois accuracy with no
> substantial downsides that I can see.
>
> -C
>
> > On Jan 24, 2017, at 3:32 PM, John Springer <3johnl at gmail.com> wrote:
> >
> > Greetings PPML,
> >
> > After discussions between the author, shepherds and the AC, the text of
> ARIN Draft Policy 2016-9, Streamline Merger & Acquisition Transfers has
> been modified for clarity.
> >
> > Please reply with thoughts and feedback. They will be very welcome.
> > Thank you in advance.
> >
> > New text:
> >
> > Problem Statement:
> > In the case of a merger or acquisition, current policy encourages not
> updating registration data, thus leaving the number resource in the name of
> a now defunct entity.
> > It is not uncommon for an entity which has bought another entity (with
> existing number resources) to leave Organizational data (Whois) in the name
> of the acquired company. The requirements in Section 8.2 put a
> justification burden on the acquiring organization, which was a legitimate
> protection while free pool assignments were available. It is worth
> revisiting Section 8.2 and looking for opportunities to simplify the policy
> in the interest of improving the registry data.
> > Consider the following:
> > 1. In the case where both organizations (acquirer, acquired) have
> justified their existing number resources from an issuer (e.g. SRI-NIC,
> GSI, ARIN) under the policies that were in force at the time of issuance,
> the number resources have already been justified once.
> > 2. ARIN does not customarily require organizations holding address space
> to document utilization except when they are asking ARIN to issue more
> space.
> > 3. Section 8.2 M&A is not asking ARIN to issue more space or provide
> authorization to acquire space in an 8.3 transfer. It is simply updating
> ARIN's database to reflect the current reality, that being that control of
> a company has changed.
> > Language that speaks of required return or transfer of space is of
> questionable enforceability in the context of the current RSA (section 6,
> "ARIN has no right to revoke any Included Number Resources under this
> Agreement due to lack of utilization by Holder").
> > Clauses that serve to scare organizations away from updating their
> information are counter to the goal of good data in whois.
> > Policy should allow ARIN staff to concentrate finite resources on
> ascertaining corporate chain of custody so as to minimize the chance of
> fraudulent transfers rather than auditing space already issued.
> > Policy statement:
> > Delete the bullet point that reads:
> > 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.
> > Add this conditional to the bottom of 8.2 for linguistic clarity:
> > "AND one or more of the following:
> > The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> > OR
> > The recipient must show that they have acquired the entire corporate
> entity which is the current registrant."
> > Remove the following paragraph from Section 8.2 of the NRPM:
> > ARIN will proceed with processing transfer requests even if the number
> resources of the combined organizations exceed what can be justified under
> current ARIN policy. 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.
> > These two changes will leave Section 8.2 looking like this:
> > 8.2. Mergers and Acquisitions
> > 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.
> > AND one or more of the following:
> > The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> > OR
> > The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
> > Timetable for implementation: Immediate
> >
> > Old text:
> >
> > Problem Statement:
> > It is not uncommon for an entity which has bought another entity (with
> existing number resources) to leave Organizational data (Whois) in the name
> of the acquired company. The requirements in Section 8.2 put a
> justification burden on the acquiring organization, which was a legitimate
> protection while free pool assignments were available. It is worth
> revisiting Section 8.2 and looking for opportunities to simplify the policy
> in the interest of improving the registry data.
> > Consider the following:
> > 1. Both organizations (acquirer, acquired) have justified their existing
> number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the
> policies that were in force at the time of issuance. In short, the number
> resources have already been justified once.
> > 2. ARIN does not customarily require organizations holding address space
> to document utilization except when they are asking ARIN to issue more
> space.
> > 3. Section 8.2 M&A is not asking ARIN to issue more space or provide
> authorization to acquire space in an 8.3 transfer. It is simply updating
> ARIN's database to reflect the current reality, that being that control of
> a company has changed.
> > Language that speaks of required return or transfer of space is of
> questionable enforceability in the context of the current RSA (section 6,
> "ARIN has no right to revoke any Included Number Resources under this
> Agreement due to lack of utilization by Holder").
> > Clauses that serve to scare organizations away from updating their
> information are counter to the goal of good data in whois.
> > Policy should allow ARIN staff to concentrate finite resources on
> ascertaining corporate chain of custody so as to minimize the chance of
> fraudulent transfers rather than auditing space already issued.
> > This proposal suggests two changes: a paragraph change to better reflect
> current practice, harmonize nomenclature with 8.3 ("new entity" vs
> "recipient") and remove an operationally-focused sentence, and a paragraph
> removal as it is the author's opinion that this paragraph has outlived its
> usefulness.
> > Policy statement:
> > Replace the following paragraph:
> > 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.
> > with this conditional, moving it to the bottom of 8.2 for linguistic
> clarity:
> > AND one or more of the following:
> > The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> > OR
> > The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
> > Remove the following paragraph from Section 8.2 of the NRPM:
> > In the event that number resources of the combined organizations are no
> longer justified under ARIN policy at the time ARIN becomes aware of the
> transaction, through a transfer request or otherwise, ARIN will work with
> the resource holder(s) to return or transfer resources as needed to restore
> compliance via the processes outlined in current ARIN policy.
> > These two changes will leave Section 8.2 looking like this:
> > 8.2. Mergers and Acquisitions
> > 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.
> > AND one or more of the following:
> > The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> > OR
> > The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
> > Timetable for implementation: Immediate
> >
> > regards
> >
> > John Springer
> > ARIN AC member and shepherd of 2016-9
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage 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.
>
-- 
Alyssa Moore
Policy & Strategy Analyst
Cybera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170124/7cc82a78/attachment.htm>

From lar at mwtcorp.net  Tue Jan 24 18:35:59 2017
From: lar at mwtcorp.net (Larry Ash)
Date: Tue, 24 Jan 2017 16:35:59 -0700
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
Message-ID: <web-2676230@be1.mail.trib.com>

I also support.

  John Springer <3johnl at gmail.com> wrote:
> Greetings PPML,
> 
> After discussions between the author, shepherds and the AC, the text of
> ARIN Draft Policy 2016-9, Streamline Merger & Acquisition Transfers has
> been modified for clarity.
> 
> Please reply with thoughts and feedback. They will be very welcome.
> Thank you in advance.
> 
> New text:
> 
> Problem Statement:
> In the case of a merger or acquisition, current policy encourages not
> updating registration data, thus leaving the number resource in the name of
> a now defunct entity.
> It is not uncommon for an entity which has bought another entity (with
> existing number resources) to leave Organizational data (Whois) in the name
> of the acquired company. The requirements in Section 8.2 put a
> justification burden on the acquiring organization, which was a legitimate
> protection while free pool assignments were available. It is worth
> revisiting Section 8.2 and looking for opportunities to simplify the policy
> in the interest of improving the registry data.
> Consider the following:
> 1. In the case where both organizations (acquirer, acquired) have justified
> their existing number resources from an issuer (e.g. SRI-NIC, GSI, ARIN)
> under the policies that were in force at the time of issuance, the number
> resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space to
> document utilization except when they are asking ARIN to issue more space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide
> authorization to acquire space in an 8.3 transfer. It is simply updating
> ARIN's database to reflect the current reality, that being that control of
> a company has changed.
> Language that speaks of required return or transfer of space is of
> questionable enforceability in the context of the current RSA (section 6,
> "ARIN has no right to revoke any Included Number Resources under this
> Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their
> information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on
> ascertaining corporate chain of custody so as to minimize the chance of
> fraudulent transfers rather than auditing space already issued.
> Policy statement:
> Delete the bullet point that reads:
>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.
> Add this conditional to the bottom of 8.2 for linguistic clarity:
> "AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have
> acquired the assets that use the resources to be transferred from the
> current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity
> which is the current registrant."
> Remove the following paragraph from Section 8.2 of the NRPM:
> ARIN will proceed with processing transfer requests even if the number
> resources of the combined organizations exceed what can be justified under
> current ARIN policy. 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.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have
> acquired the assets that use the resources to be transferred from the
> current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity
> which is the current registrant.
> Timetable for implementation: Immediate
> 
> Old text:
> 
> Problem Statement:
> It is not uncommon for an entity which has bought another entity (with
> existing number resources) to leave Organizational data (Whois) in the name
> of the acquired company. The requirements in Section 8.2 put a
> justification burden on the acquiring organization, which was a legitimate
> protection while free pool assignments were available. It is worth
> revisiting Section 8.2 and looking for opportunities to simplify the policy
> in the interest of improving the registry data.
> Consider the following:
> 1. Both organizations (acquirer, acquired) have justified their existing
> number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the
> policies that were in force at the time of issuance. In short, the number
> resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space to
> document utilization except when they are asking ARIN to issue more space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide
> authorization to acquire space in an 8.3 transfer. It is simply updating
> ARIN's database to reflect the current reality, that being that control of
> a company has changed.
> Language that speaks of required return or transfer of space is of
> questionable enforceability in the context of the current RSA (section 6,
> "ARIN has no right to revoke any Included Number Resources under this
> Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their
> information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on
> ascertaining corporate chain of custody so as to minimize the chance of
> fraudulent transfers rather than auditing space already issued.
> This proposal suggests two changes: a paragraph change to better reflect
> current practice, harmonize nomenclature with 8.3 ("new entity" vs
> "recipient") and remove an operationally-focused sentence, and a paragraph
> removal as it is the author's opinion that this paragraph has outlived its
> usefulness.
> Policy statement:
> Replace the following paragraph:
>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.
> with this conditional, moving it to the bottom of 8.2 for linguistic
> clarity:
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have
> acquired the assets that use the resources to be transferred from the
> current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity
> which is the current registrant.
> Remove the following paragraph from Section 8.2 of the NRPM:
> In the event that number resources of the combined organizations are no
> longer justified under ARIN policy at the time ARIN becomes aware of the
> transaction, through a transfer request or otherwise, ARIN will work with
> the resource holder(s) to return or transfer resources as needed to restore
> compliance via the processes outlined in current ARIN policy.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they have
> acquired the assets that use the resources to be transferred from the
> current registrant.
> OR
> The recipient must show that they have acquired the entire corporate entity
> which is the current registrant.
> Timetable for implementation: Immediate
> 
> regards
> 
> John Springer
> ARIN AC member and shepherd of 2016-9

Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387


From rjletts at uw.edu  Tue Jan 24 18:59:45 2017
From: rjletts at uw.edu (Richard J. Letts)
Date: Tue, 24 Jan 2017 23:59:45 +0000
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
Message-ID: <810F5D35-C34A-4957-9333-6E83CBF65618@uw.edu>

This assumes that only corporate entities merge, acquire, or re-organize. How would state agencies or an inter-institution research group produce the required documentation to facilitate the movement of resources given the lack of independently verifiable information?

Similarly, a function might be transferred between state agencies, but we might not be acquiring an entire corporate entity (as we?re a state agency).

Richard

From: ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of John Springer <3johnl at gmail.com>
Date: Tuesday, January 24, 2017 at 12:32 PM
To: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

These two changes will leave Section 8.2 looking like this:
8.2. Mergers and Acquisitions
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.
AND one or more of the following:
The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
OR
The recipient must show that they have acquired the entire corporate entity which is the current registrant.

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

From scottleibrand at gmail.com  Tue Jan 24 19:13:11 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 24 Jan 2017 16:13:11 -0800
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <810F5D35-C34A-4957-9333-6E83CBF65618@uw.edu>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
 <810F5D35-C34A-4957-9333-6E83CBF65618@uw.edu>
Message-ID: <CAGkMwz5KbcDfGxMNcd=mDUSFyVmvwX1pnUz0Jb4QSrKYex6EMw@mail.gmail.com>

Wouldn't the existing language ("The recipient must provide independently
verifiable evidence that they have acquired the assets that use the
resources to be transferred from the current registrant.") be good enough
for those scenarios?  The additional OR clause seems mostly meant to deal
with defunct entities where the assets that use the resources are long
gone, and all that's left is the original corporate entity.  Are there any
cases in the government realm where that is a problem as well, and M&A
transfers can't be completed under the existing rules?

-Scott

On Tue, Jan 24, 2017 at 3:59 PM, Richard J. Letts <rjletts at uw.edu> wrote:

> This assumes that only corporate entities merge, acquire, or re-organize.
> How would state agencies or an inter-institution research group produce the
> required documentation to facilitate the movement of resources given the
> lack of independently verifiable information?
>
>
>
> Similarly, a function might be transferred between state agencies, but we
> might not be acquiring an entire corporate entity (as we?re a state agency).
>
>
>
> Richard
>
>
>
> *From: *ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of John Springer
> <3johnl at gmail.com>
> *Date: *Tuesday, January 24, 2017 at 12:32 PM
> *To: *"arin-ppml at arin.net" <arin-ppml at arin.net>
> *Subject: *[arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
> Text modifications
>
>
>
> These two changes will leave Section 8.2 looking like this:
>
> 8.2. Mergers and Acquisitions
>
> 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.
>
> AND one or more of the following:
>
> The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
>
> OR
>
> The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20170124/00cdfeb2/attachment.htm>

From rjletts at uw.edu  Tue Jan 24 20:11:41 2017
From: rjletts at uw.edu (Richard J. Letts)
Date: Wed, 25 Jan 2017 01:11:41 +0000
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <CAGkMwz5KbcDfGxMNcd=mDUSFyVmvwX1pnUz0Jb4QSrKYex6EMw@mail.gmail.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
 <810F5D35-C34A-4957-9333-6E83CBF65618@uw.edu>
 <CAGkMwz5KbcDfGxMNcd=mDUSFyVmvwX1pnUz0Jb4QSrKYex6EMw@mail.gmail.com>
Message-ID: <DM5PR08MB2633E6399ADAA256D589D5ACC0740@DM5PR08MB2633.namprd08.prod.outlook.com>

That is a question for ARIN staff to weigh in on.
What ?independently verifiable evidence? would be acceptable if no assets (I assume this means servers or routers rather than human beings) using the resources are being moved?

Richard

From: Scott Leibrand [mailto:scottleibrand at gmail.com]
Sent: Tuesday, January 24, 2017 4:13 PM
To: Richard J. Letts <rjletts at uw.edu>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

Wouldn't the existing language ("The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.") be good enough for those scenarios?  The additional OR clause seems mostly meant to deal with defunct entities where the assets that use the resources are long gone, and all that's left is the original corporate entity.  Are there any cases in the government realm where that is a problem as well, and M&A transfers can't be completed under the existing rules?

-Scott

On Tue, Jan 24, 2017 at 3:59 PM, Richard J. Letts <rjletts at uw.edu<mailto:rjletts at uw.edu>> wrote:
This assumes that only corporate entities merge, acquire, or re-organize. How would state agencies or an inter-institution research group produce the required documentation to facilitate the movement of resources given the lack of independently verifiable information?

Similarly, a function might be transferred between state agencies, but we might not be acquiring an entire corporate entity (as we?re a state agency).

Richard

From: ARIN-PPML <arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>> on behalf of John Springer <3johnl at gmail.com<mailto:3johnl at gmail.com>>
Date: Tuesday, January 24, 2017 at 12:32 PM
To: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications

These two changes will leave Section 8.2 looking like this:
8.2. Mergers and Acquisitions
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.
AND one or more of the following:
The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
OR
The recipient must show that they have acquired the entire corporate entity which is the current registrant.


_______________________________________________
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/20170125/843e1563/attachment.htm>

From farmer at umn.edu  Tue Jan 24 23:23:04 2017
From: farmer at umn.edu (David Farmer)
Date: Tue, 24 Jan 2017 22:23:04 -0600
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <810F5D35-C34A-4957-9333-6E83CBF65618@uw.edu>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
 <810F5D35-C34A-4957-9333-6E83CBF65618@uw.edu>
Message-ID: <CAN-Dau3uqGKZ=zY5=mTeNDAVc5MLH4x-6=SEju7qUUmTYVaC_g@mail.gmail.com>

In the most general sense a state is a corporation. See;
https://en.wikipedia.org/wiki/Corporation#History  Further, in most cases
the agencies of a state are not independent but sub-parts of the whole.
Therefore, moving resources between agencies should more properly be
considered a reorganization of a single entity, in most situations, and not
a transfer between separate entities.  Also, I'd expect ARIN would provide
some level of deference to sovereign government entities like states,
especially in an interagency type situation.

However, to protect itself, I would expect ARIN would want to ensure they
are dealing with someone with the proper authority to act on the state's
behalf.  So, I could imagine ARIN asking a state (or agency) to provide
evidence (such as a quote of applicable statute) of who has authority over
the agencies and/or resources in question.  I expect this would be
especially be true, if resources were being transferred out of a State's
control.

Thanks.

On Tue, Jan 24, 2017 at 5:59 PM, Richard J. Letts <rjletts at uw.edu> wrote:

> This assumes that only corporate entities merge, acquire, or re-organize.
> How would state agencies or an inter-institution research group produce the
> required documentation to facilitate the movement of resources given the
> lack of independently verifiable information?
>
>
>
> Similarly, a function might be transferred between state agencies, but we
> might not be acquiring an entire corporate entity (as we?re a state agency).
>
>
>
> Richard
>
>
>
> *From: *ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of John Springer
> <3johnl at gmail.com>
> *Date: *Tuesday, January 24, 2017 at 12:32 PM
> *To: *"arin-ppml at arin.net" <arin-ppml at arin.net>
> *Subject: *[arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
> Text modifications
>
>
>
> These two changes will leave Section 8.2 looking like this:
>
> 8.2. Mergers and Acquisitions
>
> 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.
>
> AND one or more of the following:
>
> The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
>
> OR
>
> The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170124/0aab1b5e/attachment.htm>

From 3johnl at gmail.com  Tue Jan 24 23:40:30 2017
From: 3johnl at gmail.com (John Springer)
Date: Tue, 24 Jan 2017 20:40:30 -0800
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <CAN-Dau3uqGKZ=zY5=mTeNDAVc5MLH4x-6=SEju7qUUmTYVaC_g@mail.gmail.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
 <810F5D35-C34A-4957-9333-6E83CBF65618@uw.edu>
 <CAN-Dau3uqGKZ=zY5=mTeNDAVc5MLH4x-6=SEju7qUUmTYVaC_g@mail.gmail.com>
Message-ID: <CAJb_OSL0x0dkaq8xUWFG3hLF_pPXjiWuzsvHWJCzavNm+9CBbw@mail.gmail.com>

Well said, David.

Thank you.

John Springer

On Tue, Jan 24, 2017 at 8:23 PM, David Farmer <farmer at umn.edu> wrote:

> In the most general sense a state is a corporation. See;
> https://en.wikipedia.org/wiki/Corporation#History  Further, in most cases
> the agencies of a state are not independent but sub-parts of the whole.
> Therefore, moving resources between agencies should more properly be
> considered a reorganization of a single entity, in most situations, and not
> a transfer between separate entities.  Also, I'd expect ARIN would provide
> some level of deference to sovereign government entities like states,
> especially in an interagency type situation.
>
> However, to protect itself, I would expect ARIN would want to ensure they
> are dealing with someone with the proper authority to act on the state's
> behalf.  So, I could imagine ARIN asking a state (or agency) to provide
> evidence (such as a quote of applicable statute) of who has authority over
> the agencies and/or resources in question.  I expect this would be
> especially be true, if resources were being transferred out of a State's
> control.
>
> Thanks.
>
> On Tue, Jan 24, 2017 at 5:59 PM, Richard J. Letts <rjletts at uw.edu> wrote:
>
>> This assumes that only corporate entities merge, acquire, or re-organize.
>> How would state agencies or an inter-institution research group produce the
>> required documentation to facilitate the movement of resources given the
>> lack of independently verifiable information?
>>
>>
>>
>> Similarly, a function might be transferred between state agencies, but we
>> might not be acquiring an entire corporate entity (as we?re a state agency).
>>
>>
>>
>> Richard
>>
>>
>>
>> *From: *ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of John
>> Springer <3johnl at gmail.com>
>> *Date: *Tuesday, January 24, 2017 at 12:32 PM
>> *To: *"arin-ppml at arin.net" <arin-ppml at arin.net>
>> *Subject: *[arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers
>> - Text modifications
>>
>>
>>
>> These two changes will leave Section 8.2 looking like this:
>>
>> 8.2. Mergers and Acquisitions
>>
>> 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.
>>
>> AND one or more of the following:
>>
>> The recipient must provide independently verifiable evidence that they
>> have acquired the assets that use the resources to be transferred from the
>> current registrant.
>>
>> OR
>>
>> The recipient must show that they have acquired the entire corporate
>> entity which is the current registrant.
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170124/ae1a9955/attachment.htm>

From jrdelacruz at acm.org  Thu Jan 26 08:27:47 2017
From: jrdelacruz at acm.org (Jose R. de la Cruz III)
Date: Thu, 26 Jan 2017 09:27:47 -0400
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
Message-ID: <CAKrxPqd3ozqS07V_zktO-NatCEp-oqxfqdwTW31BSCdb9+f8KA@mail.gmail.com>

I support this draft.
Jos?

On Tue, Jan 24, 2017 at 4:32 PM, John Springer <3johnl at gmail.com> wrote:

> Greetings PPML,
>
> After discussions between the author, shepherds and the AC, the text of
> ARIN Draft Policy 2016-9, Streamline Merger & Acquisition Transfers has
> been modified for clarity.
>
> Please reply with thoughts and feedback. They will be very welcome.
> Thank you in advance.
>
> New text:
>
> Problem Statement:
> In the case of a merger or acquisition, current policy encourages not
> updating registration data, thus leaving the number resource in the name of
> a now defunct entity.
> It is not uncommon for an entity which has bought another entity (with
> existing number resources) to leave Organizational data (Whois) in the name
> of the acquired company. The requirements in Section 8.2 put a
> justification burden on the acquiring organization, which was a legitimate
> protection while free pool assignments were available. It is worth
> revisiting Section 8.2 and looking for opportunities to simplify the policy
> in the interest of improving the registry data.
> Consider the following:
> 1. In the case where both organizations (acquirer, acquired) have
> justified their existing number resources from an issuer (e.g. SRI-NIC,
> GSI, ARIN) under the policies that were in force at the time of issuance,
> the number resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space
> to document utilization except when they are asking ARIN to issue more
> space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide
> authorization to acquire space in an 8.3 transfer. It is simply updating
> ARIN's database to reflect the current reality, that being that control of
> a company has changed.
> Language that speaks of required return or transfer of space is of
> questionable enforceability in the context of the current RSA (section 6,
> "ARIN has no right to revoke any Included Number Resources under this
> Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their
> information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on
> ascertaining corporate chain of custody so as to minimize the chance of
> fraudulent transfers rather than auditing space already issued.
> Policy statement:
> Delete the bullet point that reads:
> 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.
> Add this conditional to the bottom of 8.2 for linguistic clarity:
> "AND one or more of the following:
> The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> OR
> The recipient must show that they have acquired the entire corporate
> entity which is the current registrant."
> Remove the following paragraph from Section 8.2 of the NRPM:
> ARIN will proceed with processing transfer requests even if the number
> resources of the combined organizations exceed what can be justified under
> current ARIN policy. 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.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> OR
> The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
> Timetable for implementation: Immediate
>
> Old text:
>
> Problem Statement:
> It is not uncommon for an entity which has bought another entity (with
> existing number resources) to leave Organizational data (Whois) in the name
> of the acquired company. The requirements in Section 8.2 put a
> justification burden on the acquiring organization, which was a legitimate
> protection while free pool assignments were available. It is worth
> revisiting Section 8.2 and looking for opportunities to simplify the policy
> in the interest of improving the registry data.
> Consider the following:
> 1. Both organizations (acquirer, acquired) have justified their existing
> number resources from an issuer (e.g. SRI-NIC, GSI, ARIN) under the
> policies that were in force at the time of issuance. In short, the number
> resources have already been justified once.
> 2. ARIN does not customarily require organizations holding address space
> to document utilization except when they are asking ARIN to issue more
> space.
> 3. Section 8.2 M&A is not asking ARIN to issue more space or provide
> authorization to acquire space in an 8.3 transfer. It is simply updating
> ARIN's database to reflect the current reality, that being that control of
> a company has changed.
> Language that speaks of required return or transfer of space is of
> questionable enforceability in the context of the current RSA (section 6,
> "ARIN has no right to revoke any Included Number Resources under this
> Agreement due to lack of utilization by Holder").
> Clauses that serve to scare organizations away from updating their
> information are counter to the goal of good data in whois.
> Policy should allow ARIN staff to concentrate finite resources on
> ascertaining corporate chain of custody so as to minimize the chance of
> fraudulent transfers rather than auditing space already issued.
> This proposal suggests two changes: a paragraph change to better reflect
> current practice, harmonize nomenclature with 8.3 ("new entity" vs
> "recipient") and remove an operationally-focused sentence, and a paragraph
> removal as it is the author's opinion that this paragraph has outlived its
> usefulness.
> Policy statement:
> Replace the following paragraph:
> 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.
> with this conditional, moving it to the bottom of 8.2 for linguistic
> clarity:
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> OR
> The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
> Remove the following paragraph from Section 8.2 of the NRPM:
> In the event that number resources of the combined organizations are no
> longer justified under ARIN policy at the time ARIN becomes aware of the
> transaction, through a transfer request or otherwise, ARIN will work with
> the resource holder(s) to return or transfer resources as needed to restore
> compliance via the processes outlined in current ARIN policy.
> These two changes will leave Section 8.2 looking like this:
> 8.2. Mergers and Acquisitions
> 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.
> AND one or more of the following:
> The recipient must provide independently verifiable evidence that they
> have acquired the assets that use the resources to be transferred from the
> current registrant.
> OR
> The recipient must show that they have acquired the entire corporate
> entity which is the current registrant.
> Timetable for implementation: Immediate
>
> regards
>
> John Springer
> ARIN AC member and shepherd of 2016-9
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20170126/09d4a2ab/attachment.htm>

From bjones at vt.edu  Thu Jan 26 09:16:02 2017
From: bjones at vt.edu (Brian Jones)
Date: Thu, 26 Jan 2017 09:16:02 -0500
Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers -
 Text modifications
In-Reply-To: <CAN-Dau3uqGKZ=zY5=mTeNDAVc5MLH4x-6=SEju7qUUmTYVaC_g@mail.gmail.com>
References: <CAJb_OSLRwTnREihpG4vdrT8+z5y3qzp5YwuZHVEBzQvaXq7Vig@mail.gmail.com>
 <810F5D35-C34A-4957-9333-6E83CBF65618@uw.edu>
 <CAN-Dau3uqGKZ=zY5=mTeNDAVc5MLH4x-6=SEju7qUUmTYVaC_g@mail.gmail.com>
Message-ID: <C404C394-8457-4289-A866-E505065CA12C@vt.edu>

+1 Dave?s comments.

I support 2016-9. It should hopefully strengthen the accuracy of the whois data.

--
Brian E Jones, CSM, CSPO
NI&S Virginia Tech
bjones at vt.edu

> On Jan 24, 2017, at 11:23 PM, David Farmer <farmer at umn.edu> wrote:
> 
> In the most general sense a state is a corporation. See; https://en.wikipedia.org/wiki/Corporation#History <https://en.wikipedia.org/wiki/Corporation#History>  Further, in most cases the agencies of a state are not independent but sub-parts of the whole. Therefore, moving resources between agencies should more properly be considered a reorganization of a single entity, in most situations, and not a transfer between separate entities.  Also, I'd expect ARIN would provide some level of deference to sovereign government entities like states, especially in an interagency type situation.
> 
> However, to protect itself, I would expect ARIN would want to ensure they are dealing with someone with the proper authority to act on the state's behalf.  So, I could imagine ARIN asking a state (or agency) to provide evidence (such as a quote of applicable statute) of who has authority over the agencies and/or resources in question.  I expect this would be especially be true, if resources were being transferred out of a State's control.
> 
> Thanks.
> 
> On Tue, Jan 24, 2017 at 5:59 PM, Richard J. Letts <rjletts at uw.edu <mailto:rjletts at uw.edu>> wrote:
> This assumes that only corporate entities merge, acquire, or re-organize. How would state agencies or an inter-institution research group produce the required documentation to facilitate the movement of resources given the lack of independently verifiable information?
> 
> 
> 
> Similarly, a function might be transferred between state agencies, but we might not be acquiring an entire corporate entity (as we?re a state agency).
> 
> 
> 
> Richard
> 
> 
> 
> From: ARIN-PPML <arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>> on behalf of John Springer <3johnl at gmail.com <mailto:3johnl at gmail.com>>
> Date: Tuesday, January 24, 2017 at 12:32 PM
> To: "arin-ppml at arin.net <mailto:arin-ppml at arin.net>" <arin-ppml at arin.net <mailto:arin-ppml at arin.net>>
> Subject: [arin-ppml] 2016-9 Streamline Merger & Acquisition Transfers - Text modifications
> 
> 
> 
> These two changes will leave Section 8.2 looking like this:
> 
> 8.2. Mergers and Acquisitions
> 
> 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.
> 
> AND one or more of the following:
> 
> The recipient must provide independently verifiable evidence that they have acquired the assets that use the resources to be transferred from the current registrant.
> 
> OR
> 
> The recipient must show that they have acquired the entire corporate entity which is the current registrant.
> 
> 
> 
> 
> _______________________________________________
> 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.
> 
> 
> 
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu <mailto:Email%3Afarmer at umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170126/ca0ca731/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170126/ca0ca731/attachment.sig>

From narten at us.ibm.com  Fri Jan 27 00:53:13 2017
From: narten at us.ibm.com (narten at us.ibm.com)
Date: Fri, 27 Jan 2017 00:53:13 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201701270553.v0R5rDDM027909@rotala.raleigh.ibm.com>

Total of 34 messages in the last 7 days.
 
script run at: Fri Jan 27 00:53:13 EST 2017
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 11.76% |    4 | 10.63% |    61291 | mike at iptrading.com
  8.82% |    3 |  9.40% |    54155 | jrdelacruz at acm.org
  5.88% |    2 |  8.85% |    50984 | rjletts at uw.edu
  5.88% |    2 |  8.04% |    46365 | bjones at vt.edu
  5.88% |    2 |  8.00% |    46129 | 3johnl at gmail.com
  5.88% |    2 |  7.95% |    45797 | scottleibrand at gmail.com
  5.88% |    2 |  6.95% |    40087 | farmer at umn.edu
  5.88% |    2 |  4.74% |    27311 | daveid at panix.com
  5.88% |    2 |  4.28% |    24659 | owen at delong.com
  2.94% |    1 |  5.98% |    34452 | alyssa.moore at cybera.ca
  2.94% |    1 |  3.21% |    18516 | oroberts at bell.ca
  2.94% |    1 |  2.89% |    16631 | ingrid at ripe.net
  2.94% |    1 |  2.65% |    15303 | lar at mwtcorp.net
  2.94% |    1 |  2.64% |    15223 | rs-lists at seastrom.com
  2.94% |    1 |  2.59% |    14957 | chris at semihuman.com
  2.94% |    1 |  2.48% |    14298 | leo.vegoda at icann.org
  2.94% |    1 |  1.74% |    10031 | mje at posix.co.za
  2.94% |    1 |  1.54% |     8867 | narten at us.ibm.com
  2.94% |    1 |  1.48% |     8548 | kevinb at thewire.ca
  2.94% |    1 |  1.46% |     8400 | bill at herrin.us
  2.94% |    1 |  1.25% |     7230 | ppml at rsuc.gweep.net
  2.94% |    1 |  1.24% |     7152 | job at ntt.net
--------+------+--------+----------+------------------------
100.00% |   34 |100.00% |   576386 | Total



From owen at delong.com  Fri Jan 27 13:39:33 2017
From: owen at delong.com (Owen DeLong)
Date: Fri, 27 Jan 2017 13:39:33 -0500
Subject: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
In-Reply-To: <7E7773B523E82C478734E793E58F69E78E4DC8F4@SBS2011.thewireinc.local>
References: <ea90a56c-21f5-47d8-f6ad-9500a9f78248@arin.net>
 <Pine.NEB.4.64.1701191530420.25224@panix1.panix.com>
 <047401d27297$551a97c0$ff4fc740$@iptrading.com>
 <CAGkMwz6KO=sa4n4OYS6+yG8ExRtg3ow3_8jheg9CpqgLgs6dtA@mail.gmail.com>
 <7E7773B523E82C478734E793E58F69E78E4D3271@SBS2011.thewireinc.local>
 <CAGkMwz4Bu082c7fVarVnmix6uXWBCXAvKHpQ_=Cg_3h0XBVW+Q@mail.gmail.com>
 <20170120122307.GB4458@Vurt.local>
 <01d401d27345$69c5e400$3d51ac00$@iptrading.com>
 <BA3E763C-C54D-4D2B-B462-81AAD5EC98ED@delong.com>
 <20170122172927.GA45073@gweep.net>
 <7E7773B523E82C478734E793E58F69E78E4DC8F4@SBS2011.thewireinc.local>
Message-ID: <92F1CDBD-375D-43D6-9184-F40A9E54545E@delong.com>


> On Jan 23, 2017, at 8:23 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
> 
> Joe,
> 
> The asymmetric transfers you mention below are allowed from my understanding.
> 
> RIR<->RIR->NIR

It is my understanding that APNIC policy allows these transfers where it is RIR<->APNIC->NIR.

I do not know of any other circumstances where such asymmetric policies are allowed.

To the best of my knowledge, the current only NIRs implementing such asymmetric policy are CNNIC and VNNIC.

> 
> I remember this being discussed at the last ARIN meeting. If staff could confirm my basic diagram that would be appreciated.
> 
> I believe at least for LACNIC and AFRNIC there should be a waiver if requested, not a removal of reciprocity from the entire section.

I would not oppose (though, neither would I support) a temporary waiver, but I would want to see either hard criteria or a hard deadline when the waiver expires.

I strongly oppose removing the reciprocity from policy for the reasons previously stated.

Owen

> 
> Kevin Blumberg
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Joe Provo
> Sent: Sunday, January 22, 2017 12:29 PM
> To: ARIN-PPML List <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN Response to AFRINIC on Policy compatibility
> 
> On Fri, Jan 20, 2017 at 05:29:29PM -0800, Owen DeLong wrote:
>> The reciprocity requirement merely requires that the policies ALLOW 
>> transfers in both directions.
>> 
>> I do not believe that allowing transfers to an RIR which will not 
>> allow transfers out is reasonable or prudent and this belief has 
>> nothing to do with maintenance or protection of a free pool. If we 
>> will allow transfers between RIRs, then the policies by which they are 
>> allowed should be fair, balanced, and symmetrical. This does not mean 
>> that I expect the ratio of actual transfers to be balanced or 
>> symmetrical, merely that the policies under which they are conducted 
>> should be.
> 
> I'm with Owen on this. 
> 
> For folks who think asymmetric transfers in this context (co-operating RIRs) is OK, how do they feel regarding such transfers in other contexts?  I'm specifically thinking of asymmetric lock-in transfers to certain NIRs who require resources used within their legislative boundary be in their registry. I'm concerned that even a conditional door open here sets a precedent for enabling such reduced resource fluidity. 
> 
> IMNSHO, that way leads to enabling Balkanization.
> 
> Cheers!
> 
> Joe
> 
> --
> Posted from my personal account - see X-Disclaimer header.
> Joe Provo / Gweep / Earthling
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 job at ntt.net  Mon Jan 30 03:42:22 2017
From: job at ntt.net (Job Snijders)
Date: Mon, 30 Jan 2017 09:42:22 +0100
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
Message-ID: <20170130084222.GA1111@hanna.meerval.net>

Dear all,

For many years now, the publication of ARIN's cryptographic RPKI
materials has been a point of contention. See [1], [2], [3], and [4] as
examples of the ongoing discussion.

Third parties who wish to validate BGP route announcements to protect
their ARIN-region-based customers and partners, or to use RPKI data in
provisioning processes (such as prefix-filters generation), must
(implicitly) agree to the "Relying Party Agreement".

>From https://www.arin.net/resources/rpki/tal.html:

    "ARIN publishes all Certificates, Certificate Revocation Lists
    (CRLs), and RPKI-signed objects in its Resource Public Key
    Infrastructure (RPKI) Repository. The ARIN Repository is available
    to anyone under the terms and conditions in the Relying Party
    Agreement."

These materials are intended to be used by both ARIN members as well as
non-ARIN affiliated organisations (who might not even have a presence in
the ARIN region).

What stands out to me is that (as example) the RIPE NCC RPKI Validator
ships with materials from all the RIRs, except ARIN. The RPKI Validator
is a commonly used software package to interact with the RPKI.

    https://github.com/RIPE-NCC/rpki-validator/tree/master/rpki-validator-app/conf/tal
    (notice that LACNIC, AfriNIC, APNIC, RIPE NCC are all there)

As such, the RPKI Validator (out of the box) is not complete. I
attribute this to ARIN's RPA. This phenomenon puts a burden on every
organisation wishing to use RPKI.

I view this as a shortcoming of the ecosystem and detrimental to our
efforts maintain a secure routing system.

Of course any party can read the RPA and (if they agree) download the
ARIN TAL and add it to their RPKI Validator installation, but I strongly
prefer an ecosystem which out-of-the-box is operating in a secure mode.
I'd argue that ARIN has an obligation to its members to make these
materials unencumbered by legal constraints and freely available to
anyone.

A comparison can be drawn with DNSSEC: ICANN (through the IANA) go above
and beyond to publish the DNSSEC materials required for validation, and
ensure distribution as widely as possible: https://www.iana.org/dnssec/files
The strategy is described here:
http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html
Note that there is no mention of "Agreement" or "Indemnification".
Imagine DNSSEC without trivial availability of public keys: it wouldn't
work.

I'd like to request that we revisit the topic of the RPKI TAL Relying
Party Agreement, with the goal to make these cryptographic materials
freely available in such a way that they can be bundled with software
distributions. When ARIN's TAL can be bundled freely, I anticipate more
innovation in the secure routing problem space. RPKI can play a
significant role in not only as a defense mechanism, but also as part of
provisioning processes. Unlimited distribution of the RPKI TALs is key.

I consider the limited availability of the ARIN TAL a showstopper for
global RPKI deployment.

Kind regards,

Job Snijders

[1]: http://seclists.org/nanog/2016/Feb/84
[2]: http://seclists.org/nanog/2014/Dec/77
[3]: http://packetpushers.net/rpki-bgp-security-hammpered-legal-agreement/
[4]: http://markmail.org/message/ycbijxzgw24je5zn


From jcurran at arin.net  Mon Jan 30 14:49:57 2017
From: jcurran at arin.net (John Curran)
Date: Mon, 30 Jan 2017 19:49:57 +0000
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <20170130084222.GA1111@hanna.meerval.net>
References: <20170130084222.GA1111@hanna.meerval.net>
Message-ID: <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>

On 30 Jan 2017, at 3:42 AM, Job Snijders <job at ntt.net<mailto:job at ntt.net>> wrote:

What stands out to me is that (as example) the RIPE NCC RPKI Validator
ships with materials from all the RIRs, except ARIN. The RPKI Validator
is a commonly used software package to interact with the RPKI.

   https://github.com/RIPE-NCC/rpki-validator/tree/master/rpki-validator-app/conf/tal
   (notice that LACNIC, AfriNIC, APNIC, RIPE NCC are all there)

As such, the RPKI Validator (out of the box) is not complete. I
attribute this to ARIN's RPA. This phenomenon puts a burden on every
organisation wishing to use RPKI.

I view this as a shortcoming of the ecosystem and detrimental to our
efforts maintain a secure routing system.

Of course any party can read the RPA and (if they agree) download the
ARIN TAL and add it to their RPKI Validator installation, but I strongly
prefer an ecosystem which out-of-the-box is operating in a secure mode.
I'd argue that ARIN has an obligation to its members to make these
materials unencumbered by legal constraints and freely available to
anyone.

Job -

   In order to better understand your request regarding the differences between
   ARIN and the other RIR?s re how the TAL is made available, I need to inquire
   about your assertion that ARIN should "make these materials unencumbered
   by legal constraints and freely available to anyone?

   Is it your belief that other RIRs presently make these materials available without
   legal constraints?   A quick review would show that is not the case; for example,
   access RIPE?s RPKI CA repository data binds one to RIPE?s RPKI repository Terms
   and Conditions <https://www.ripe.net/manage-ips-and-asns/resource-management/certification/legal/ripe-ncc-certification-repository-terms-and-conditions>

   Is it the presence of legal constraints that it is the concern, or the fact that ARIN
   requires explicit downloading (and thus awareness of this fact) that is the issue?

   Note that wee did streamline access to the TAL recently (by making it a simple
   download from the web rather than requiring explicitly agreement acceptance
   and download via email link); in this manner, getting ARIN?s TAL should not
   be much more difficult then obtaining the typical software library.

Thanks for any insight you can provide,
/John

John Curran
President and CEO
ARIN





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

From job at ntt.net  Mon Jan 30 15:14:00 2017
From: job at ntt.net (Job Snijders)
Date: Mon, 30 Jan 2017 21:14:00 +0100
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
Message-ID: <20170130201400.GD35120@Vurt.local>

Dear John,

On Mon, Jan 30, 2017 at 07:49:57PM +0000, John Curran wrote:
> > On 30 Jan 2017, at 3:42 AM, Job Snijders <job at ntt.net<mailto:job at ntt.net>> wrote:
> > 
> > What stands out to me is that (as example) the RIPE NCC RPKI Validator
> > ships with materials from all the RIRs, except ARIN. The RPKI Validator
> > is a commonly used software package to interact with the RPKI.
> > 
> >    https://github.com/RIPE-NCC/rpki-validator/tree/master/rpki-validator-app/conf/tal
> >    (notice that LACNIC, AfriNIC, APNIC, RIPE NCC are all there)
> > 
> > As such, the RPKI Validator (out of the box) is not complete. I
> > attribute this to ARIN's RPA. This phenomenon puts a burden on every
> > organisation wishing to use RPKI.
> > 
> > I view this as a shortcoming of the ecosystem and detrimental to our
> > efforts maintain a secure routing system.
> > 
> > Of course any party can read the RPA and (if they agree) download the
> > ARIN TAL and add it to their RPKI Validator installation, but I strongly
> > prefer an ecosystem which out-of-the-box is operating in a secure mode.
> > I'd argue that ARIN has an obligation to its members to make these
> > materials unencumbered by legal constraints and freely available to
> > anyone.
> > 
> Job -
> 
> In order to better understand your request regarding the differences
> between ARIN and the other RIR?s re how the TAL is made available, I
> need to inquire about your assertion that ARIN should "make these
> materials unencumbered by legal constraints and freely available to
> anyone?
> 
> Is it your belief that other RIRs presently make these materials
> available without legal constraints?

No. Though I see room for improvement outside the ARIN region,
discussing that would perhaps seem out of scope for this mailing list.

> Is it the presence of legal constraints that it is the concern, or the
> fact that ARIN requires explicit downloading (and thus awareness of
> this fact) that is the issue?

Both are a concern. Please note that I am not advocating that all legal
constraints should be lifted, for me its the results that matter: at
this point in time it appears that ARIN's TAL is not bundled with common
RPKI tools, and that to me is a problem.

Having said that, the ICANN/IANA approach of making the relevant public
key materials freely available, without agreements or other barriers,
has my preference.

> Note that wee did streamline access to the TAL recently (by making it
> a simple download from the web rather than requiring explicitly
> agreement acceptance and download via email link); in this manner,
> getting ARIN?s TAL should not be much more difficult then obtaining
> the typical software library.

The typical software library can be downloaded from thousands of
mirrors, or obtained by ordering a DVD containing a full software
distribution. Also, the typical software package is not subject to
ARIN's RPA. It is my desire to be able to treat any of the RPKI TAL's as
a "typical software library".

We seek to reduce friction down to the point of:
    `sudo apt-get install -y arin-rpki-magic`,
or that the RIPE NCC RPKI Validator can add the TAL directly to its
source code repository.

Is this something you can commit to helping transpire?

Kind regards,

Job


From bill at herrin.us  Mon Jan 30 17:30:49 2017
From: bill at herrin.us (William Herrin)
Date: Mon, 30 Jan 2017 17:30:49 -0500
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
Message-ID: <CAP-guGVnn-56Nud+vJmDGCA+yvO=2ongnhTYF1xGz5Zdk9n=Sw@mail.gmail.com>

On Mon, Jan 30, 2017 at 2:49 PM, John Curran <jcurran at arin.net> wrote:
>    Is it your belief that other RIRs presently make these materials
> available without
>    legal constraints?   A quick review would show that is not the case; for
> example,
>    access RIPE?s RPKI CA repository data binds one to RIPE?s RPKI repository
> Terms
>    and Conditions
> <https://www.ripe.net/manage-ips-and-asns/resource-management/certification/legal/ripe-ncc-certification-repository-terms-and-conditions>
>
>    Is it the presence of legal constraints that it is the concern, or the
> fact that ARIN
>    requires explicit downloading (and thus awareness of this fact) that is
> the issue?

Hi John,

Such "shrink wrap" licenses are largely unenforceable. They exist
primarily to discourage the data's users from suing the data's
provider. ARIN takes additional steps to legally bind users to the
agreement. If ARIN's only objective is to avoid losing a lawsuit,
these extra steps are unnecessary and obstructive. You could safely
and effectively provide anonymous access the same way you provide
anonymous access the same way you provide anonymous whois access.

Unless I misunderstand and you already do provide fully anonymous
access to the RPKI respository?

Alternately, you could shorten the agreement to something which does
not generally require legal review. Three single-spaced pages is
excessive for a document which need only say, "AS IS. No warranties
including no warranty of merchantability or fitness for a particular
purpose. Void where prohibited."

Regards,
Bill Herrin




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


From daveid at panix.com  Tue Jan 31 08:18:31 2017
From: daveid at panix.com (David R Huberman)
Date: Tue, 31 Jan 2017 08:18:31 -0500 (EST)
Subject: [arin-ppml] 2016-3 Revisited
Message-ID: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>

Hello,

TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an 
abuse vector.  We kept the original text and just incorporated it in the 
new section 8.5 so it works, and time limited it to once every 6 months.

Background:

At the ARIN meeting in Dallas, there was a discussion about 2016-3, a 
policy which seeks to remove Needs Testing for smaller 8.3 and 8.4 
transfers (with a cap of /16).  Some more work needed to be done on it, 
and a vote at the Dallas meeting had 27 people ask the AC to continue 
working on it, with 1 person against.

We've done some work, and the new text is ready for your review and 
comment.


New NRPM Coming Out Affects 2016-3:

Policy 2016-5 was ratified by the board, and will be entering the NRPM 
shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are 
the qualifying criteria for transfers.  It looks like this:

8.5. Specified Transfer Recipient Requirements

8.5.1. Registration Services Agreement
The receiving entity must sign an RSA covering all resources to be 
transferred unless that entity has a current (within the last two 
versions) RSA on file.

8.5.2. Operational Use
ARIN allocates or assigns number resources to organizations via transfer 
solely for the purpose of use on an operational network.

8.5.3. Minimum transfer size
ARINs minimum IPv4 transfer size is a /24.

8.5.4. Initial block
Organizations without direct assignments or allocations from ARIN qualify 
for transfer of an initial IPv4 block of ARINs 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 IPv4 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 their cumulative IPv4 address blocks 
in order to receive additional space. This includes all space reassigned 
to their customers.


To this, 2016-3 now adds a new paragraph:

8.5.7 Alternative Additional IPv4 Address Block Criteria
In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 
address blocks by demonstrating 80% utilization of their currently 
allocated space. If they do so, they qualify to receive one or more 
transfers up to the total size of their current ARIN IPv4 address 
holdings, with a maximum size of /16.

An organization may only qualify under 8.5.7 once every 6 months.


Conclusion:

This text is pretty much the same text that was originally proposed in 
2016-3, simply incorporated into the new NRPM language that's coming out.

It also puts in a mechanism to avoid abuse -- people trying to get around 
the /16 cap -- by limiting it to once every 6 months.

The AC welcomes your feedback.

Thank you,
David


From SRyerse at eclipse-networks.com  Tue Jan 31 11:02:45 2017
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 31 Jan 2017 16:02:45 +0000
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
Message-ID: <0bd1269777b54b0f99487bbf2af840ee@eclipse-networks.com>

+1


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

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?

-----Original Message-----
From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David R Huberman
Sent: Tuesday, January 31, 2017 8:19 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] 2016-3 Revisited

Hello,

TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an abuse vector.  We kept the original text and just incorporated it in the new section 8.5 so it works, and time limited it to once every 6 months.

Background:

At the ARIN meeting in Dallas, there was a discussion about 2016-3, a policy which seeks to remove Needs Testing for smaller 8.3 and 8.4 transfers (with a cap of /16).  Some more work needed to be done on it, and a vote at the Dallas meeting had 27 people ask the AC to continue working on it, with 1 person against.

We've done some work, and the new text is ready for your review and comment.


New NRPM Coming Out Affects 2016-3:

Policy 2016-5 was ratified by the board, and will be entering the NRPM 
shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are 
the qualifying criteria for transfers.  It looks like this:

8.5. Specified Transfer Recipient Requirements

8.5.1. Registration Services Agreement
The receiving entity must sign an RSA covering all resources to be 
transferred unless that entity has a current (within the last two 
versions) RSA on file.

8.5.2. Operational Use
ARIN allocates or assigns number resources to organizations via transfer 
solely for the purpose of use on an operational network.

8.5.3. Minimum transfer size
ARINs minimum IPv4 transfer size is a /24.

8.5.4. Initial block
Organizations without direct assignments or allocations from ARIN qualify 
for transfer of an initial IPv4 block of ARINs 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 IPv4 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 their cumulative IPv4 address blocks 
in order to receive additional space. This includes all space reassigned 
to their customers.


To this, 2016-3 now adds a new paragraph:

8.5.7 Alternative Additional IPv4 Address Block Criteria
In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 
address blocks by demonstrating 80% utilization of their currently 
allocated space. If they do so, they qualify to receive one or more 
transfers up to the total size of their current ARIN IPv4 address 
holdings, with a maximum size of /16.

An organization may only qualify under 8.5.7 once every 6 months.


Conclusion:

This text is pretty much the same text that was originally proposed in 
2016-3, simply incorporated into the new NRPM language that's coming out.

It also puts in a mechanism to avoid abuse -- people trying to get around 
the /16 cap -- by limiting it to once every 6 months.

The AC welcomes your feedback.

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

From jschiller at google.com  Tue Jan 31 11:04:13 2017
From: jschiller at google.com (Jason Schiller)
Date: Tue, 31 Jan 2017 11:04:13 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
Message-ID: <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>

As one of the originators of this policy change I welcome the rewrite,
with the exception the mechanism to avoid abuse.

Can someone explain the "abuse" concerns if I have not correctly captured
it?


Abuse concern:
---------------------
As far as I can tell, the combination of 2016-5 and this proposal (2016-3)
is where the issue comes from.
One of the goals of 2016-5 was to separate section 4 from transfers.

As a result, NRPM 4.2.4.1 & 4.3.6.1 which specifies that organizations must
show efficient utilization of 80% in aggregate, and 50% for each
allocation/assignment is no longer a restriction to transfers.

Without applying 4.2.4.1 & 4.3.6.1 an organization that is holding a /8
that is 90% utilized, could then use 8.5.7 to justify a specified transfer
of a /16.

Once completed, the total holding of a /16 and a /8 would be 89.65%
utilized and could immediately use 8.5.7 to justify another specified
transfer of a /16.

This process could be used 33 times and could result in drawing down a /11
and a /16 without putting a single new address into service.


Basic idea of 2016-3 and 2016-4:
---------------------------------------------

1. Make an easy to use process with an easily predictable outcome for
    "simplified" transfers
2. Modify slow start and make it applicable to transfers for end-sites and
ISPs
3. Give blanket approval for a "first", "small" starter block
4. Show that you have used what you got and then double what you have
5. Can always get more than double following the non-simplified process


Intended Cap implementation:
----------------------------------------

Doubling more than a /16 could provide way too much IP space
(consider an efficiently used org than is not growing)
Instead the doubling policy is limited at a /16.
However if an organization is growing and has legitimate need for more
than a /16, then it can get a /16 put it into service and then come back
and get another dip.


Suggested Anti-abuse text:
-------------------------------------

To this, 2016-3 now adds a new paragraph:

8.5.7 Alternative Additional IPv4 Address Block Criteria
In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
address blocks by demonstrating both
- 80% utilization of their currently allocated space
- at least 50% utilization of each allocation and assignment
If they do so, they qualify to receive one or more transfers up to the
total size of their current ARIN IPv4 address holdings, with a maximum size
of /16.

Taking the abuse example above of an organization with a /8 that is is 90%
utilized,
the organization would need to transfer in a /16.
Then the organization would need to put 32,768 of the new IPs into service,
or renumber the use of 32,768 of IPs from the older IP space to the new
space.

I argue that need to show growth or the renumbering of usage into the new
IP space
is of sufficient pain to avoid abuse by organizations that don't actually
need the IP space.

__Jason




On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <daveid at panix.com> wrote:

> Hello,
>
> TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an
> abuse vector.  We kept the original text and just incorporated it in the
> new section 8.5 so it works, and time limited it to once every 6 months.
>
> Background:
>
> At the ARIN meeting in Dallas, there was a discussion about 2016-3, a
> policy which seeks to remove Needs Testing for smaller 8.3 and 8.4
> transfers (with a cap of /16).  Some more work needed to be done on it, and
> a vote at the Dallas meeting had 27 people ask the AC to continue working
> on it, with 1 person against.
>
> We've done some work, and the new text is ready for your review and
> comment.
>
>
> New NRPM Coming Out Affects 2016-3:
>
> Policy 2016-5 was ratified by the board, and will be entering the NRPM
> shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are
> the qualifying criteria for transfers.  It looks like this:
>
> 8.5. Specified Transfer Recipient Requirements
>
> 8.5.1. Registration Services Agreement
> The receiving entity must sign an RSA covering all resources to be
> transferred unless that entity has a current (within the last two versions)
> RSA on file.
>
> 8.5.2. Operational Use
> ARIN allocates or assigns number resources to organizations via transfer
> solely for the purpose of use on an operational network.
>
> 8.5.3. Minimum transfer size
> ARINs minimum IPv4 transfer size is a /24.
>
> 8.5.4. Initial block
> Organizations without direct assignments or allocations from ARIN qualify
> for transfer of an initial IPv4 block of ARINs 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 IPv4 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 their cumulative IPv4 address blocks
> in order to receive additional space. This includes all space reassigned to
> their customers.
>
>
> To this, 2016-3 now adds a new paragraph:
>
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
> address blocks by demonstrating 80% utilization of their currently
> allocated space. If they do so, they qualify to receive one or more
> transfers up to the total size of their current ARIN IPv4 address holdings,
> with a maximum size of /16.
>
> An organization may only qualify under 8.5.7 once every 6 months.
>
>
> Conclusion:
>
> This text is pretty much the same text that was originally proposed in
> 2016-3, simply incorporated into the new NRPM language that's coming out.
>
> It also puts in a mechanism to avoid abuse -- people trying to get around
> the /16 cap -- by limiting it to once every 6 months.
>
> The AC welcomes your feedback.
>
> Thank you,
> David
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
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/20170131/5b0e77c9/attachment.htm>

From mike at iptrading.com  Tue Jan 31 11:27:32 2017
From: mike at iptrading.com (Mike Burns)
Date: Tue, 31 Jan 2017 11:27:32 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
Message-ID: <011801d27bde$ec7bacd0$c5730670$@iptrading.com>

Taking the abuse example above of an organization with a /8 that is is 90% utilized, 

the organization would need to transfer in a /16.  

Then the organization would need to put 32,768 of the new IPs into service, 

or renumber the use of 32,768 of IPs from the older IP space to the new space.

 

I argue that need to show growth or the renumbering of usage into the new IP space 

is of sufficient pain to avoid abuse by organizations that don't actually need the IP space.

 

__Jason

 

 

 

Hi Jason,

 

I argue that the need to pay money for IP space is sufficient pain to avoid abuse by organizations that don?t actually need IP space.  Also any /8 owners have deep pockets and could easily utilize the various policy workarounds which are available, like leases and options. And anybody interested in receiving IP space they don?t need is free to open a RIPE account and do just that. Except nobody does.

 

I support the policy (the re-write and the inclusion of 2016-3) but bemoan the unnecessary complexity required to keep an anachronistic needs test in place in the face of clear evidence from RIPE that it is only there to assuage unsubstantiated fears of hoarding and speculation.  

 

APNIC is considering ending needs tests now, but retaining the RIPE-type language only to ensure ARIN sourced addresses are ?needs-tested?, ahem.

 

Regards,

Mike Burns

 

 

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

From jschiller at google.com  Tue Jan 31 11:47:51 2017
From: jschiller at google.com (Jason Schiller)
Date: Tue, 31 Jan 2017 11:47:51 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <011801d27bde$ec7bacd0$c5730670$@iptrading.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <011801d27bde$ec7bacd0$c5730670$@iptrading.com>
Message-ID: <CAC4yj2Xgf5yt2nYrADZuGimmPaYZfuLOhAv1f4E_tgRj8kPiWA@mail.gmail.com>

Mike,

I am confused by your email.

You say "I argue that the need to pay money for IP space is sufficient pain
to avoid abuse by organizations that don?t actually need IP space."

Does than mean you would support the policy as written without the once
every six month cap limitation?


Sounds like you would also support it with the once every six month cap
limitation, but would prefer the more simpler version without the cap?
 (You will support the cap if that is what is needed to move policy in the
right direction)

Sounds like you would also support it with the demonstration of 50%
utilization of each allocation/assignment, but prefer the more simpler 6
month cap, and very much prefer the even simpler no cap? (You will support
demonstration of utilization of greater than 50% if that is what is needed
to move the policy in the right direction)

You would also support the change if it made no mention of 80% and/or 50%
utilization.


8.5.7 Alternative Additional IPv4 Address Block Criteria
In lieu of 8.5.5 and 8.5.6, organizations may qualify for a specified
transfer of IPv4 address blocks up to the smaller of either a /16 or double
their current IPv4 address holdings once every 6 months.

Is that correct?

__Jason

On Tue, Jan 31, 2017 at 11:27 AM, Mike Burns <mike at iptrading.com> wrote:

> Taking the abuse example above of an organization with a /8 that is is 90%
> utilized,
>
> the organization would need to transfer in a /16.
>
> Then the organization would need to put 32,768 of the new IPs into
> service,
>
> or renumber the use of 32,768 of IPs from the older IP space to the new
> space.
>
>
>
> I argue that need to show growth or the renumbering of usage into the new
> IP space
>
> is of sufficient pain to avoid abuse by organizations that don't actually
> need the IP space.
>
>
>
> __Jason
>
>
>
>
>
>
>
> Hi Jason,
>
>
>
> I argue that the need to pay money for IP space is sufficient pain to
> avoid abuse by organizations that don?t actually need IP space.  Also any
> /8 owners have deep pockets and could easily utilize the various policy
> workarounds which are available, like leases and options. And anybody
> interested in receiving IP space they don?t need is free to open a RIPE
> account and do just that. Except nobody does.
>
>
>
> I support the policy (the re-write and the inclusion of 2016-3) but bemoan
> the unnecessary complexity required to keep an anachronistic needs test in
> place in the face of clear evidence from RIPE that it is only there to
> assuage unsubstantiated fears of hoarding and speculation.
>
>
>
> APNIC is considering ending needs tests now, but retaining the RIPE-type
> language only to ensure ARIN sourced addresses are ?needs-tested?, ahem.
>
>
>
> Regards,
>
> Mike Burns
>
>
>
>
>



-- 
_______________________________________________________
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/20170131/8501eaad/attachment.htm>

From mike at iptrading.com  Tue Jan 31 11:58:04 2017
From: mike at iptrading.com (Mike Burns)
Date: Tue, 31 Jan 2017 11:58:04 -0500
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2Xgf5yt2nYrADZuGimmPaYZfuLOhAv1f4E_tgRj8kPiWA@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
 <011801d27bde$ec7bacd0$c5730670$@iptrading.com>
 <CAC4yj2Xgf5yt2nYrADZuGimmPaYZfuLOhAv1f4E_tgRj8kPiWA@mail.gmail.com>
Message-ID: <014801d27be3$30701490$91503db0$@iptrading.com>

Hi Jason,

 

Yes, I would support it without the cap, I don?t think any needs test at all is required for IPv4 transfers and any policy change which makes it simpler and easier to effect transfers will garner my support.

 

In this case the reduction from 80% to 50% is big, and the automatic qualification for newcomer minimums is helpful, and the alternative mechanism for requesting an additional like-sized block as one that is 80% used is helpful.

 

So I support his policy change with or without the cap, as a step towards less uncertainty in transfers, but I would prefer to remove needs testing altogether until and unless some problems arise from that removal.  

 

Regards,
Mike

 

 

From: Jason Schiller [mailto:jschiller at google.com] 
Sent: Tuesday, January 31, 2017 11:48 AM
To: Mike Burns <mike at iptrading.com>
Cc: David R Huberman <daveid at panix.com>; arin-ppml at arin.net
Subject: Re: [arin-ppml] 2016-3 Revisited

 

Mike,

 

I am confused by your email.  

 

You say "I argue that the need to pay money for IP space is sufficient pain to avoid abuse by organizations that don?t actually need IP space."

 

Does than mean you would support the policy as written without the once every six month cap limitation?

 

 

Sounds like you would also support it with the once every six month cap limitation, but would prefer the more simpler version without the cap?  (You will support the cap if that is what is needed to move policy in the right direction)

 

Sounds like you would also support it with the demonstration of 50% utilization of each allocation/assignment, but prefer the more simpler 6 month cap, and very much prefer the even simpler no cap? (You will support demonstration of utilization of greater than 50% if that is what is needed to move the policy in the right direction)

 

You would also support the change if it made no mention of 80% and/or 50% utilization.

 

 

8.5.7 Alternative Additional IPv4 Address Block Criteria

In lieu of 8.5.5 and 8.5.6, organizations may qualify for a specified transfer of IPv4 address blocks up to the smaller of either a /16 or double their current IPv4 address holdings once every 6 months.

 

Is that correct?

 

__Jason

 

On Tue, Jan 31, 2017 at 11:27 AM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

Taking the abuse example above of an organization with a /8 that is is 90% utilized, 

the organization would need to transfer in a /16.  

Then the organization would need to put 32,768 of the new IPs into service, 

or renumber the use of 32,768 of IPs from the older IP space to the new space.

 

I argue that need to show growth or the renumbering of usage into the new IP space 

is of sufficient pain to avoid abuse by organizations that don't actually need the IP space.

 

__Jason

 

 

 

Hi Jason,

 

I argue that the need to pay money for IP space is sufficient pain to avoid abuse by organizations that don?t actually need IP space.  Also any /8 owners have deep pockets and could easily utilize the various policy workarounds which are available, like leases and options. And anybody interested in receiving IP space they don?t need is free to open a RIPE account and do just that. Except nobody does.

 

I support the policy (the re-write and the inclusion of 2016-3) but bemoan the unnecessary complexity required to keep an anachronistic needs test in place in the face of clear evidence from RIPE that it is only there to assuage unsubstantiated fears of hoarding and speculation.  

 

APNIC is considering ending needs tests now, but retaining the RIPE-type language only to ensure ARIN sourced addresses are ?needs-tested?, ahem.

 

Regards,

Mike Burns

 

 





 

-- 

_______________________________________________________

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/20170131/6254c650/attachment.htm>

From scottleibrand at gmail.com  Tue Jan 31 16:16:04 2017
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 31 Jan 2017 13:16:04 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
Message-ID: <CAGkMwz7h6xBZFSQPXbYsUO5m42GJVNAa9wDjHAcU+0sX19x7mw@mail.gmail.com>

I support this proposal, either as amended thus far by David and the AC, or
(preferentially) as suggested by Jason.

I believe Jason's suggestion (restoring the "at least 50% utilization of
each allocation and assignment" condition to the 8.5.7 conditions) would
adequately address the "transfer /16s as fast as you can until total
utilization is below 80%" abuse concern, while still leaving the option
open for someone who has a legitimate need for another /16 in less than 6
months (without requiring the burden of documenting forward-looking plans
and getting ARIN to agree that they're "good enough").

Is there anyone who feels that the every-6-month restriction is sufficient
but the 50%-usage-of-each-block restriction is not?  If so, can you outline
the scenario that you think the former would protect against and the latter
would not?

Thanks,
Scott

On Tue, Jan 31, 2017 at 8:04 AM, Jason Schiller <jschiller at google.com>
wrote:

> As one of the originators of this policy change I welcome the rewrite,
> with the exception the mechanism to avoid abuse.
>
> Can someone explain the "abuse" concerns if I have not correctly captured
> it?
>
>
> Abuse concern:
> ---------------------
> As far as I can tell, the combination of 2016-5 and this proposal (2016-3)
> is where the issue comes from.
> One of the goals of 2016-5 was to separate section 4 from transfers.
>
> As a result, NRPM 4.2.4.1 & 4.3.6.1 which specifies that organizations
> must show efficient utilization of 80% in aggregate, and 50% for each
> allocation/assignment is no longer a restriction to transfers.
>
> Without applying 4.2.4.1 & 4.3.6.1 an organization that is holding a /8
> that is 90% utilized, could then use 8.5.7 to justify a specified transfer
> of a /16.
>
> Once completed, the total holding of a /16 and a /8 would be 89.65%
> utilized and could immediately use 8.5.7 to justify another specified
> transfer of a /16.
>
> This process could be used 33 times and could result in drawing down a /11
> and a /16 without putting a single new address into service.
>
>
> Basic idea of 2016-3 and 2016-4:
> ---------------------------------------------
>
> 1. Make an easy to use process with an easily predictable outcome for
>     "simplified" transfers
> 2. Modify slow start and make it applicable to transfers for end-sites and
> ISPs
> 3. Give blanket approval for a "first", "small" starter block
> 4. Show that you have used what you got and then double what you have
> 5. Can always get more than double following the non-simplified process
>
>
> Intended Cap implementation:
> ----------------------------------------
>
> Doubling more than a /16 could provide way too much IP space
> (consider an efficiently used org than is not growing)
> Instead the doubling policy is limited at a /16.
> However if an organization is growing and has legitimate need for more
> than a /16, then it can get a /16 put it into service and then come back
> and get another dip.
>
>
> Suggested Anti-abuse text:
> -------------------------------------
>
> To this, 2016-3 now adds a new paragraph:
>
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
> address blocks by demonstrating both
> - 80% utilization of their currently allocated space
> - at least 50% utilization of each allocation and assignment
> If they do so, they qualify to receive one or more transfers up to the
> total size of their current ARIN IPv4 address holdings, with a maximum size
> of /16.
>
> Taking the abuse example above of an organization with a /8 that is is 90%
> utilized,
> the organization would need to transfer in a /16.
> Then the organization would need to put 32,768 of the new IPs into
> service,
> or renumber the use of 32,768 of IPs from the older IP space to the new
> space.
>
> I argue that need to show growth or the renumbering of usage into the new
> IP space
> is of sufficient pain to avoid abuse by organizations that don't actually
> need the IP space.
>
> __Jason
>
>
>
>
> On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <daveid at panix.com>
> wrote:
>
>> Hello,
>>
>> TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an
>> abuse vector.  We kept the original text and just incorporated it in the
>> new section 8.5 so it works, and time limited it to once every 6 months.
>>
>> Background:
>>
>> At the ARIN meeting in Dallas, there was a discussion about 2016-3, a
>> policy which seeks to remove Needs Testing for smaller 8.3 and 8.4
>> transfers (with a cap of /16).  Some more work needed to be done on it, and
>> a vote at the Dallas meeting had 27 people ask the AC to continue working
>> on it, with 1 person against.
>>
>> We've done some work, and the new text is ready for your review and
>> comment.
>>
>>
>> New NRPM Coming Out Affects 2016-3:
>>
>> Policy 2016-5 was ratified by the board, and will be entering the NRPM
>> shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are
>> the qualifying criteria for transfers.  It looks like this:
>>
>> 8.5. Specified Transfer Recipient Requirements
>>
>> 8.5.1. Registration Services Agreement
>> The receiving entity must sign an RSA covering all resources to be
>> transferred unless that entity has a current (within the last two versions)
>> RSA on file.
>>
>> 8.5.2. Operational Use
>> ARIN allocates or assigns number resources to organizations via transfer
>> solely for the purpose of use on an operational network.
>>
>> 8.5.3. Minimum transfer size
>> ARINs minimum IPv4 transfer size is a /24.
>>
>> 8.5.4. Initial block
>> Organizations without direct assignments or allocations from ARIN qualify
>> for transfer of an initial IPv4 block of ARINs 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 IPv4 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 their cumulative IPv4 address blocks
>> in order to receive additional space. This includes all space reassigned to
>> their customers.
>>
>>
>> To this, 2016-3 now adds a new paragraph:
>>
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
>> address blocks by demonstrating 80% utilization of their currently
>> allocated space. If they do so, they qualify to receive one or more
>> transfers up to the total size of their current ARIN IPv4 address holdings,
>> with a maximum size of /16.
>>
>> An organization may only qualify under 8.5.7 once every 6 months.
>>
>>
>> Conclusion:
>>
>> This text is pretty much the same text that was originally proposed in
>> 2016-3, simply incorporated into the new NRPM language that's coming out.
>>
>> It also puts in a mechanism to avoid abuse -- people trying to get around
>> the /16 cap -- by limiting it to once every 6 months.
>>
>> The AC welcomes your feedback.
>>
>> Thank you,
>> David
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
>
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-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/20170131/a0b3899e/attachment.htm>

From jcurran at arin.net  Tue Jan 31 16:42:50 2017
From: jcurran at arin.net (John Curran)
Date: Tue, 31 Jan 2017 21:42:50 +0000
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <20170130201400.GD35120@Vurt.local>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
Message-ID: <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>

On 30 Jan 2017, at 3:14 PM, Job Snijders <job at ntt.net> wrote:
> 
>> Is it the presence of legal constraints that it is the concern, or the
>> fact that ARIN requires explicit downloading (and thus awareness of
>> this fact) that is the issue?
> 
> Both are a concern. Please note that I am not advocating that all legal
> constraints should be lifted, for me its the results that matter: at
> this point in time it appears that ARIN's TAL is not bundled with common
> RPKI tools, and that to me is a problem.

Job - 

ARIN?s TAL is readily available (for any who wish it) via a simple download
that requires a trivial amount of technical effort when compared to the related 
task of introducing RPKI data into a networks routing decisions. The act of 
obtaining ARIN?s TAL, while technically quite simple, is one that must be done 
explicitly.

The reason that obtaining ARIN?s TAL must be done explicitly that the use 
of ARIN?s RPKI data is not an activity to be undertaken lightly, and includes 
responsibilities that we wish parties to carefully consider.   As others have 
noted elsewhere in this thread, under US law it is indeterminate whether use 
of an open RPKI repository would entail agreement to the corresponding terms 
of usage (despite this practice being used by other RIRs), whereas obtaining
ARIN?s TAL via explicit act is much more certain in this regard. 

> We seek to reduce friction down to the point of:
>    `sudo apt-get install -y arin-rpki-magic`,
> or that the RIPE NCC RPKI Validator can add the TAL directly to its
> source code repository.

I am certain that an appropriate (and equally short) wget command could 
suffice technically for installing ARIN?s TAL, but including such in a script
(or including the TAL directly in the source code repository) would deprive 
parties of the ability to fully consider and accept the responsibilities involved.  

While ARIN?s Board of Trustees has been quite consistent in its position that 
RPKI services are to be offered under clear terms and conditions, I will also 
bring this email thread to their attention for further consideration.

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers (ARIN)








From bill at herrin.us  Tue Jan 31 19:58:32 2017
From: bill at herrin.us (William Herrin)
Date: Tue, 31 Jan 2017 19:58:32 -0500
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
Message-ID: <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>

On Tue, Jan 31, 2017 at 4:42 PM, John Curran <jcurran at arin.net> wrote:
> ARIN?s Board of Trustees has been quite consistent in its position that
> RPKI services are to be offered under clear terms and conditions

Then it is the Board's position that BGP shall not be secured.

Imagine if you had to agree to a contract in order to verify ARIN's
https web site certificate. Absurdity!

Regards,
Bill Herrin


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


From owen at delong.com  Tue Jan 31 21:37:40 2017
From: owen at delong.com (Owen DeLong)
Date: Tue, 31 Jan 2017 18:37:40 -0800
Subject: [arin-ppml] 2016-3 Revisited
In-Reply-To: <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
References: <Pine.NEB.4.64.1701310811440.16594@panix1.panix.com>
 <CAC4yj2XgtRUgLQYFsk4N+Tem+f2Wcq6oBcqest66eQ3kF5YjBA@mail.gmail.com>
Message-ID: <FDBD1CD0-8B05-4A4B-A4B5-29B69BF1F2E4@delong.com>

I argue that it is insufficient and that a 6-month moratorium on a second simplified transfer is easier for everyone to understand and implement.

The reason I feel it is insufficient is that renumbering a DHCP server handing out a /17 (or cobbling up a DHCP server handing out a /17) isn?t a particularly difficult barrier.

Given that the preponderance of addresses handed out by larger service providers these days are dynamic in nature, renumbering large swaths of address space to circumvent the intent of the /16 limit on this policy is relatively trivial.

Any organization that truly needs a larger transfer is free to get the approval through the conventional process and this simplified process is probably not a good fit as a result.

I believe that is congruent with your original intent and that the six-month recycle limit is a quite reasonable safeguard.

Owen

> On Jan 31, 2017, at 08:04 , Jason Schiller <jschiller at google.com> wrote:
> 
> As one of the originators of this policy change I welcome the rewrite, 
> with the exception the mechanism to avoid abuse.
> 
> Can someone explain the "abuse" concerns if I have not correctly captured it?
> 
> 
> Abuse concern:
> ---------------------
> As far as I can tell, the combination of 2016-5 and this proposal (2016-3) is where the issue comes from. 
> One of the goals of 2016-5 was to separate section 4 from transfers.
> 
> As a result, NRPM 4.2.4.1 & 4.3.6.1 which specifies that organizations must show efficient utilization of 80% in aggregate, and 50% for each allocation/assignment is no longer a restriction to transfers.
> 
> Without applying 4.2.4.1 & 4.3.6.1 an organization that is holding a /8 that is 90% utilized, could then use 8.5.7 to justify a specified transfer of a /16.  
> 
> Once completed, the total holding of a /16 and a /8 would be 89.65% utilized and could immediately use 8.5.7 to justify another specified transfer of a /16.  
> 
> This process could be used 33 times and could result in drawing down a /11 and a /16 without putting a single new address into service.
> 
> 
> Basic idea of 2016-3 and 2016-4:
> ---------------------------------------------
> 
> 1. Make an easy to use process with an easily predictable outcome for 
>     "simplified" transfers
> 2. Modify slow start and make it applicable to transfers for end-sites and ISPs
> 3. Give blanket approval for a "first", "small" starter block
> 4. Show that you have used what you got and then double what you have
> 5. Can always get more than double following the non-simplified process
> 
> 
> Intended Cap implementation:
> ----------------------------------------
> 
> Doubling more than a /16 could provide way too much IP space
> (consider an efficiently used org than is not growing)
> Instead the doubling policy is limited at a /16.
> However if an organization is growing and has legitimate need for more 
> than a /16, then it can get a /16 put it into service and then come back 
> and get another dip.
> 
> 
> Suggested Anti-abuse text:
> -------------------------------------
> 
> To this, 2016-3 now adds a new paragraph:
> 
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating both 
> - 80% utilization of their currently allocated space 
> - at least 50% utilization of each allocation and assignment
> If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.
> 
> Taking the abuse example above of an organization with a /8 that is is 90% utilized, 
> the organization would need to transfer in a /16.  
> Then the organization would need to put 32,768 of the new IPs into service, 
> or renumber the use of 32,768 of IPs from the older IP space to the new space.
> 
> I argue that need to show growth or the renumbering of usage into the new IP space 
> is of sufficient pain to avoid abuse by organizations that don't actually need the IP space.
> 
> __Jason
> 
>  
> 
> 
> On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <daveid at panix.com <mailto:daveid at panix.com>> wrote:
> Hello,
> 
> TL;DR:  We updated 2016-3 to fit into the upcoming NRPM, and closed an abuse vector.  We kept the original text and just incorporated it in the new section 8.5 so it works, and time limited it to once every 6 months.
> 
> Background:
> 
> At the ARIN meeting in Dallas, there was a discussion about 2016-3, a policy which seeks to remove Needs Testing for smaller 8.3 and 8.4 transfers (with a cap of /16).  Some more work needed to be done on it, and a vote at the Dallas meeting had 27 people ask the AC to continue working on it, with 1 person against.
> 
> We've done some work, and the new text is ready for your review and comment.
> 
> 
> New NRPM Coming Out Affects 2016-3:
> 
> Policy 2016-5 was ratified by the board, and will be entering the NRPM shortly.  2016-5 adds a new section to section 8 -- it adds 8.5, which are the qualifying criteria for transfers.  It looks like this:
> 
> 8.5. Specified Transfer Recipient Requirements
> 
> 8.5.1. Registration Services Agreement
> The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file.
> 
> 8.5.2. Operational Use
> ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network.
> 
> 8.5.3. Minimum transfer size
> ARINs minimum IPv4 transfer size is a /24.
> 
> 8.5.4. Initial block
> Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARINs 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 IPv4 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 their cumulative IPv4 address blocks in order to receive additional space. This includes all space reassigned to their customers.
> 
> 
> To this, 2016-3 now adds a new paragraph:
> 
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. If they do so, they qualify to receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, with a maximum size of /16.
> 
> An organization may only qualify under 8.5.7 once every 6 months.
> 
> 
> Conclusion:
> 
> This text is pretty much the same text that was originally proposed in 2016-3, simply incorporated into the new NRPM language that's coming out.
> 
> It also puts in a mechanism to avoid abuse -- people trying to get around the /16 cap -- by limiting it to once every 6 months.
> 
> The AC welcomes your feedback.
> 
> Thank you,
> David
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> 
> 
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com <mailto:jschiller at google.com>|571-266-0006
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

From owen at delong.com  Tue Jan 31 21:41:39 2017
From: owen at delong.com (Owen DeLong)
Date: Tue, 31 Jan 2017 18:41:39 -0800
Subject: [arin-ppml] Revisit RPKI TAL Relying Party Agreement?
In-Reply-To: <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
References: <20170130084222.GA1111@hanna.meerval.net>
 <6EA7FE13-5311-4FD3-BF53-9C36B79110BE@arin.net>
 <20170130201400.GD35120@Vurt.local>
 <E2AAF50A-57C3-496F-A8F8-FCA58D3A85F3@arin.net>
 <CAP-guGW5mbmsagQtfdxBaq3a+-8BLO27PtOneZkrJvL_jKTFtQ@mail.gmail.com>
Message-ID: <53584583-FB61-40F5-BC78-BDD15561FE01@delong.com>

RPKI doesn?t secure BGP.

All it does is provide a cryptographically signed mechanism by which
you can suggest what ASN should be forged as the origin of a route that
you want to hijack.

Owen

> On Jan 31, 2017, at 16:58 , William Herrin <bill at herrin.us> wrote:
> 
> On Tue, Jan 31, 2017 at 4:42 PM, John Curran <jcurran at arin.net> wrote:
>> ARIN?s Board of Trustees has been quite consistent in its position that
>> RPKI services are to be offered under clear terms and conditions
> 
> Then it is the Board's position that BGP shall not be secured.
> 
> Imagine if you had to agree to a contract in order to verify ARIN's
> https web site certificate. Absurdity!
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.