From farmer at umn.edu  Mon Mar  2 15:24:11 2015
From: farmer at umn.edu (David Farmer)
Date: Mon, 02 Mar 2015 14:24:11 -0600
Subject: [arin-ppml] Draft Policy ARIN-2014-21: Modification to CI Pool
 Size per Section 4.4
In-Reply-To: <5474E803.9020504@arin.net>
References: <5474E803.9020504@arin.net>
Message-ID: <54F4C6EB.80308@umn.edu>

This Draft Policy was discussed at the PPC in San Antonio last month, 
the meeting report for the PPC is at the following link;

https://www.arin.net/participate/meetings/reports/ppc_nanog63/index.html

And there is a staff and legal assessment of the Draft Policy posted at;

https://www.arin.net/policy/proposals/2014_21.html

At the PPC there was some opposition expressed, basically that an 
additional reservation for the CI pool is not justified based on use of 
the current reservation.  However, I feel the community in general 
supports this Draft Policy, and still thinks the expanded reservation is 
justified.

There was a suggestion to modify the text to provide additional 
editorial clean up of Section 4.4, however given the feedback received 
so far, I'd suggest we stick with the text as-is, and deal with these 
issues elsewhere.

So, as shepherd for this Draft Policy I plan to ask the AC to advance 
this Draft Policy to Recommended Draft Policy on our next call, and 
present this as Recommended Draft Policy at the PPM next month in San 
Francisco.

However, if anyone thinks the previously proposed editorial changes or 
any other changes to the text are necessary please speak up ASAP, as the 
text will need to be frozen for the PPM within the next week or so.

Thanks.

On 11/25/14 14:35 , ARIN wrote:
...
> Draft Policy ARIN-2014-21
> Modification to CI Pool Size per Section 4.4
>
> Date: 25 November 2014
>
> Problem Statement:
>
> At the time that this section of policy was written, IXP growth in North
> America was stagnant. Efforts of late have increased significantly
> within the IXP standards and other communities to improve critical
> infrastructure in North America. This effort is paying dividends and we
> project that a /16 will not be enough to continue to improve global
> interconnect conditions and support needed IXP CI infrastructure.
>
> Policy statement:
>
> Change to text in section 4.4 Micro Allocations:
>
> Current text:
>
> ARIN will place an equivalent of a /16 of IPv4 address space in a
> reserve for Critical Infrastructure, as defined in section 4.4. If at
> the end of the policy term there is unused address space remaining in
> this pool, ARIN staff is authorized to utilize this space in a manner
> consistent with community expectations.
>
> Proposed text to replace current text entirely:
>
> ARIN will place an equivalent of a /15 of IPv4 address space in a
> reserve for Critical Infrastructure, as defined in section 4.4.
>
> Timetable for implementation: Immediate


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


From hannigan at gmail.com  Mon Mar  2 15:26:18 2015
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 2 Mar 2015 15:26:18 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-21: Modification to CI Pool
 Size per Section 4.4
In-Reply-To: <54F4C6EB.80308@umn.edu>
References: <5474E803.9020504@arin.net> <54F4C6EB.80308@umn.edu>
Message-ID: <CAMDXq5MEUkBvdNhGCOe0sODHsa=NcSsV0GxgDj1quQtHP9cymA@mail.gmail.com>

The editorial changes are a no op and a waste of perfectly good deck chairs.

Best,

-M<




On Mon, Mar 2, 2015 at 3:24 PM, David Farmer <farmer at umn.edu> wrote:

> This Draft Policy was discussed at the PPC in San Antonio last month, the
> meeting report for the PPC is at the following link;
>
> https://www.arin.net/participate/meetings/reports/ppc_nanog63/index.html
>
> And there is a staff and legal assessment of the Draft Policy posted at;
>
> https://www.arin.net/policy/proposals/2014_21.html
>
> At the PPC there was some opposition expressed, basically that an
> additional reservation for the CI pool is not justified based on use of the
> current reservation.  However, I feel the community in general supports
> this Draft Policy, and still thinks the expanded reservation is justified.
>
> There was a suggestion to modify the text to provide additional editorial
> clean up of Section 4.4, however given the feedback received so far, I'd
> suggest we stick with the text as-is, and deal with these issues elsewhere.
>
> So, as shepherd for this Draft Policy I plan to ask the AC to advance this
> Draft Policy to Recommended Draft Policy on our next call, and present this
> as Recommended Draft Policy at the PPM next month in San Francisco.
>
> However, if anyone thinks the previously proposed editorial changes or any
> other changes to the text are necessary please speak up ASAP, as the text
> will need to be frozen for the PPM within the next week or so.
>
> Thanks.
>
> On 11/25/14 14:35 , ARIN wrote:
> ...
>
>> Draft Policy ARIN-2014-21
>> Modification to CI Pool Size per Section 4.4
>>
>> Date: 25 November 2014
>>
>> Problem Statement:
>>
>> At the time that this section of policy was written, IXP growth in North
>> America was stagnant. Efforts of late have increased significantly
>> within the IXP standards and other communities to improve critical
>> infrastructure in North America. This effort is paying dividends and we
>> project that a /16 will not be enough to continue to improve global
>> interconnect conditions and support needed IXP CI infrastructure.
>>
>> Policy statement:
>>
>> Change to text in section 4.4 Micro Allocations:
>>
>> Current text:
>>
>> ARIN will place an equivalent of a /16 of IPv4 address space in a
>> reserve for Critical Infrastructure, as defined in section 4.4. If at
>> the end of the policy term there is unused address space remaining in
>> this pool, ARIN staff is authorized to utilize this space in a manner
>> consistent with community expectations.
>>
>> Proposed text to replace current text entirely:
>>
>> ARIN will place an equivalent of a /15 of IPv4 address space in a
>> reserve for Critical Infrastructure, as defined in section 4.4.
>>
>> Timetable for implementation: Immediate
>>
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20150302/1cc1eb20/attachment.htm>

From narten at us.ibm.com  Fri Mar  6 00:53:02 2015
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 06 Mar 2015 00:53:02 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201503060553.t265r2oj000472@rotala.raleigh.ibm.com>

Total of 3 messages in the last 7 days.
 
script run at: Fri Mar  6 00:53:02 EST 2015
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |    1 | 45.78% |    14346 | hannigan at gmail.com
 33.33% |    1 | 30.27% |     9486 | farmer at umn.edu
 33.33% |    1 | 23.95% |     7505 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    3 |100.00% |    31337 | Total



From andrew.dul at quark.net  Wed Mar 11 11:36:46 2015
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 11 Mar 2015 08:36:46 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for
 some IPv4 Transfers - Revised
In-Reply-To: <54ECB219.7030707@arin.net>
References: <54ECB219.7030707@arin.net>
Message-ID: <5500610E.1070107@quark.net>

This policy draft has been significantly revised by the AC, including a
new problem statement and substantially different draft policy
language.  Conversation on PPML so far has been quite limited on this
new draft.  The AC would like to hear from members of the community on
this new language.  Specifically if you could address the following
questions it would be appreciated.

Do you agree with the new problem statement?

Do you support the new policy language?  If not, are there areas of the
text which could be modified so that you could support the draft?

If you don't support this revised language, do you believe the AC should
abandon this draft policy?

Thanks for your feedback,
Andrew

On 2/24/2015 9:17 AM, ARIN wrote:
> ARIN-2014-14 has been revised. This draft policy is open for discussion
> on this mailing list.
>
> ARIN-2014-14 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_14.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2014-14
> Needs Attestation for some IPv4 Transfers
>
> Date: 24 Feb 2015
>
> Problem Statement:
>
> The process of 'needs testing' or 'needs basis' allocation has evolved
> over the history of the Internet registry system. The earliest number
> resource policy required that an operator intend to use the number
> resources on an operational Internet Protocol network before the
> resource would be registered to an organization. Organizations were
> assigned either a Class A, B, or C block roughly depending on the
> organization's size. With the implementation of CIDR, additional 'needs
> testing' was done to right size allocations to fit organizations. These
> testing requirements continued to evolve under various organizations
> prior to the RIRs inception and then later formally under the RIR's
> policy development process.
>
> In the 2000s, ARIN began a systematic "trust but verify" process for
> IPv4 requests. This was necessary due to both IPv4 address registration
> hijackings in ARIN Whois and the accelerated amount of systematic fraud
> being perpetrated on ARIN.
>
> As IPv4 exhaustion occurred, some RIRs have reconsidered the necessity
> of some of the needs testing requirements and implemented policies
> which reduced the requirements on organizations to show need or
> utilization for some transfer transactions with the RIR.
>
> The cost of performing a needs assessment and auditing of this
> information vs. the public benefit of restricting allocations to
> specifically qualified organizations has been noted by some
> organizations to be out of alignment. The ability to predict future use
> toward a 24-month utilization rate can also be challenging for some
> organizations and relies on projections and estimates rather than
> verifiable facts. Thus, the current needs testing requirements may be
> more than is necessary and desirable for small transfers. This policy
> seeks to reduce the complexity of transfers by removing the utilization
> needs testing requirement and replacing it with a needs attestation by
> a corporate officer.
>
> Additionally, other requirements are placed around the 'needs
> attestation only' requirement to reduce the Number Resource Community's
> concern that this type of policy could be abused for speculation or
> hording. Furthermore, the policy includes a sunset clause to limit the
> total number of transfers under this policy proposal. This sunset is
> intended to force the community to reexamine the success or failure of
> the practices contained in this policy proposal.
>
> Policy statement:
>
> Section 8.3
>
> Replace the 'Conditions on recipient of the transfer' with
> the following conditions.
>
> Conditions on recipient of the transfer:
>
>   The organization must sign an RSA.
>
>   The resources transferred will be subject to current ARIN policies.
>
> In addition, the recipient must meet one of the following requirements
> sets:
>
> 1. The organization must demonstrate the need for up to a 24-month
> supply of IP address resources under current ARIN policies.
>
> OR
>
> 1.The organization, its parent(s), or subsidiary organizations, must
> not have received IPv4 address resources, via transfer, within the
> past 12 months.
>
> 2.An officer of the organization must attest that the IPv4 address
> block is needed for and will be used on an operational network.
>
> 3.The maximum transfer size is /20.
>
> 4.Fewer than 5,000 needs attestation transfers have occurred.
>
>
> Section 8.4
>
> Replace the 'Conditions on recipient of the transfer' with
> the following conditions.
>
> Conditions on recipient of the transfer:
>
>   The conditions on a recipient outside of the ARIN region will be
>   defined by the policies of the receiving RIR.
>
>   Recipients within the ARIN region will be subject to current ARIN
>   policies and sign an RSA for the resources being received.
>
>   The minimum transfer size is a /24.
>
> In addition, the recipient must meet one of the following requirements
> sets:
>
> 1. The organization must demonstrate the need for up to a 24-month
> supply of IP address resources under current ARIN policies.
>
> OR
>
> 1.The organization, its parent(s), or subsidiary organizations, must
> not have received IPv4 address resources, via transfer, within the
> past 12 months.
>
> 2.An officer of the organization must attest that the IPv4 address
> block is needed for and will be used on an operational network.
>
> 3.The maximum transfer size is /20.
>
> 4.Fewer than 5,000 needs attestation transfers have occurred.
>
> Comments:
>
> 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 mike at iptrading.com  Thu Mar 12 11:08:33 2015
From: mike at iptrading.com (Mike Burns)
Date: Thu, 12 Mar 2015 11:08:33 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for
	some IPv4 Transfers - Revised
In-Reply-To: <5500610E.1070107@quark.net>
References: <54ECB219.7030707@arin.net> <5500610E.1070107@quark.net>
Message-ID: <026801d05cd6$8302cd20$89086760$@iptrading.com>

On 2/24/2015 9:17 AM, ARIN wrote:
> ARIN-2014-14 has been revised. This draft policy is open for 
> discussion on this mailing list.
>
> ARIN-2014-14 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_14.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2014-14
> Needs Attestation for some IPv4 Transfers
>
> Date: 24 Feb 2015
>
> Problem Statement:
>
> The process of 'needs testing' or 'needs basis' allocation has evolved 
> over the history of the Internet registry system. The earliest number 
> resource policy required that an operator intend to use the number 
> resources on an operational Internet Protocol network before the 
> resource would be registered to an organization. Organizations were 
> assigned either a Class A, B, or C block roughly depending on the 
> organization's size. With the implementation of CIDR, additional 
> 'needs testing' was done to right size allocations to fit 
> organizations. These testing requirements continued to evolve under 
> various organizations prior to the RIRs inception and then later 
> formally under the RIR's policy development process.
>
> In the 2000s, ARIN began a systematic "trust but verify" process for
> IPv4 requests. This was necessary due to both IPv4 address 
> registration hijackings in ARIN Whois and the accelerated amount of 
> systematic fraud being perpetrated on ARIN.
>
> As IPv4 exhaustion occurred, some RIRs have reconsidered the necessity 
> of some of the needs testing requirements and implemented policies 
> which reduced the requirements on organizations to show need or 
> utilization for some transfer transactions with the RIR.
>
> The cost of performing a needs assessment and auditing of this 
> information vs. the public benefit of restricting allocations to 
> specifically qualified organizations has been noted by some 
> organizations to be out of alignment. The ability to predict future 
> use toward a 24-month utilization rate can also be challenging for 
> some organizations and relies on projections and estimates rather than 
> verifiable facts. Thus, the current needs testing requirements may be 
> more than is necessary and desirable for small transfers. This policy 
> seeks to reduce the complexity of transfers by removing the 
> utilization needs testing requirement and replacing it with a needs 
> attestation by a corporate officer.
>
> Additionally, other requirements are placed around the 'needs 
> attestation only' requirement to reduce the Number Resource 
> Community's concern that this type of policy could be abused for 
> speculation or hording. Furthermore, the policy includes a sunset 
> clause to limit the total number of transfers under this policy 
> proposal. This sunset is intended to force the community to reexamine 
> the success or failure of the practices contained in this policy proposal.
>
> Policy statement:
>
> Section 8.3
>
> Replace the 'Conditions on recipient of the transfer' with the 
> following conditions.
>
> Conditions on recipient of the transfer:
>
>   The organization must sign an RSA.
>
>   The resources transferred will be subject to current ARIN policies.
>
> In addition, the recipient must meet one of the following requirements
> sets:
>
> 1. The organization must demonstrate the need for up to a 24-month 
> supply of IP address resources under current ARIN policies.
>
> OR
>
> 1.The organization, its parent(s), or subsidiary organizations, must 
> not have received IPv4 address resources, via transfer, within the 
> past 12 months.
>
> 2.An officer of the organization must attest that the IPv4 address 
> block is needed for and will be used on an operational network.
>
> 3.The maximum transfer size is /20.
>
> 4.Fewer than 5,000 needs attestation transfers have occurred.
>
>
> Section 8.4
>
> Replace the 'Conditions on recipient of the transfer' with the 
> following conditions.
>
> Conditions on recipient of the transfer:
>
>   The conditions on a recipient outside of the ARIN region will be
>   defined by the policies of the receiving RIR.
>
>   Recipients within the ARIN region will be subject to current ARIN
>   policies and sign an RSA for the resources being received.
>
>   The minimum transfer size is a /24.
>
> In addition, the recipient must meet one of the following requirements
> sets:
>
> 1. The organization must demonstrate the need for up to a 24-month 
> supply of IP address resources under current ARIN policies.
>
> OR
>
> 1.The organization, its parent(s), or subsidiary organizations, must 
> not have received IPv4 address resources, via transfer, within the 
> past 12 months.
>
> 2.An officer of the organization must attest that the IPv4 address 
> block is needed for and will be used on an operational network.
>
> 3.The maximum transfer size is /20.
>
> 4.Fewer than 5,000 needs attestation transfers have occurred.
>
> Comments:
>
> 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.

Hi Andrew,

I think it would be clearer if the line:

4.Fewer than 5,000 needs attestation transfers have occurred.

Was changed to: 

4. Fewer than 5,000 transfers under this requirement set have completed.

But I would support it with the current language. 
The maximum number of addresses which could be transferred in aggregate
under this policy is 1.25 /8 equivalents.
And at the current rate of transfers this would take years.
Does anybody still fear damaging market manipulation could occur under this
policy?

Regards,
Mike Burns
IPTrading.com



From owen at delong.com  Thu Mar 12 13:54:46 2015
From: owen at delong.com (Owen DeLong)
Date: Thu, 12 Mar 2015 10:54:46 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for
	some IPv4 Transfers - Revised
In-Reply-To: <026801d05cd6$8302cd20$89086760$@iptrading.com>
References: <54ECB219.7030707@arin.net> <5500610E.1070107@quark.net>
	<026801d05cd6$8302cd20$89086760$@iptrading.com>
Message-ID: <F83FA862-9FBE-4E3A-ABC5-DC0EDD3DCF15@delong.com>

Mike,

Your proposed language is clearer in the context of policy development, but would lack clarity when placed in the NRPM as ?this requirement? becomes somewhat ambiguous.

Owen

> On Mar 12, 2015, at 08:08 , Mike Burns <mike at iptrading.com> wrote:
> 
> On 2/24/2015 9:17 AM, ARIN wrote:
>> ARIN-2014-14 has been revised. This draft policy is open for 
>> discussion on this mailing list.
>> 
>> ARIN-2014-14 is below and can be found at:
>> https://www.arin.net/policy/proposals/2014_14.html
>> 
>> Regards,
>> 
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> ## * ##
>> 
>> 
>> Draft Policy ARIN-2014-14
>> Needs Attestation for some IPv4 Transfers
>> 
>> Date: 24 Feb 2015
>> 
>> Problem Statement:
>> 
>> The process of 'needs testing' or 'needs basis' allocation has evolved 
>> over the history of the Internet registry system. The earliest number 
>> resource policy required that an operator intend to use the number 
>> resources on an operational Internet Protocol network before the 
>> resource would be registered to an organization. Organizations were 
>> assigned either a Class A, B, or C block roughly depending on the 
>> organization's size. With the implementation of CIDR, additional 
>> 'needs testing' was done to right size allocations to fit 
>> organizations. These testing requirements continued to evolve under 
>> various organizations prior to the RIRs inception and then later 
>> formally under the RIR's policy development process.
>> 
>> In the 2000s, ARIN began a systematic "trust but verify" process for
>> IPv4 requests. This was necessary due to both IPv4 address 
>> registration hijackings in ARIN Whois and the accelerated amount of 
>> systematic fraud being perpetrated on ARIN.
>> 
>> As IPv4 exhaustion occurred, some RIRs have reconsidered the necessity 
>> of some of the needs testing requirements and implemented policies 
>> which reduced the requirements on organizations to show need or 
>> utilization for some transfer transactions with the RIR.
>> 
>> The cost of performing a needs assessment and auditing of this 
>> information vs. the public benefit of restricting allocations to 
>> specifically qualified organizations has been noted by some 
>> organizations to be out of alignment. The ability to predict future 
>> use toward a 24-month utilization rate can also be challenging for 
>> some organizations and relies on projections and estimates rather than 
>> verifiable facts. Thus, the current needs testing requirements may be 
>> more than is necessary and desirable for small transfers. This policy 
>> seeks to reduce the complexity of transfers by removing the 
>> utilization needs testing requirement and replacing it with a needs 
>> attestation by a corporate officer.
>> 
>> Additionally, other requirements are placed around the 'needs 
>> attestation only' requirement to reduce the Number Resource 
>> Community's concern that this type of policy could be abused for 
>> speculation or hording. Furthermore, the policy includes a sunset 
>> clause to limit the total number of transfers under this policy 
>> proposal. This sunset is intended to force the community to reexamine 
>> the success or failure of the practices contained in this policy proposal.
>> 
>> Policy statement:
>> 
>> Section 8.3
>> 
>> Replace the 'Conditions on recipient of the transfer' with the 
>> following conditions.
>> 
>> Conditions on recipient of the transfer:
>> 
>>  The organization must sign an RSA.
>> 
>>  The resources transferred will be subject to current ARIN policies.
>> 
>> In addition, the recipient must meet one of the following requirements
>> sets:
>> 
>> 1. The organization must demonstrate the need for up to a 24-month 
>> supply of IP address resources under current ARIN policies.
>> 
>> OR
>> 
>> 1.The organization, its parent(s), or subsidiary organizations, must 
>> not have received IPv4 address resources, via transfer, within the 
>> past 12 months.
>> 
>> 2.An officer of the organization must attest that the IPv4 address 
>> block is needed for and will be used on an operational network.
>> 
>> 3.The maximum transfer size is /20.
>> 
>> 4.Fewer than 5,000 needs attestation transfers have occurred.
>> 
>> 
>> Section 8.4
>> 
>> Replace the 'Conditions on recipient of the transfer' with the 
>> following conditions.
>> 
>> Conditions on recipient of the transfer:
>> 
>>  The conditions on a recipient outside of the ARIN region will be
>>  defined by the policies of the receiving RIR.
>> 
>>  Recipients within the ARIN region will be subject to current ARIN
>>  policies and sign an RSA for the resources being received.
>> 
>>  The minimum transfer size is a /24.
>> 
>> In addition, the recipient must meet one of the following requirements
>> sets:
>> 
>> 1. The organization must demonstrate the need for up to a 24-month 
>> supply of IP address resources under current ARIN policies.
>> 
>> OR
>> 
>> 1.The organization, its parent(s), or subsidiary organizations, must 
>> not have received IPv4 address resources, via transfer, within the 
>> past 12 months.
>> 
>> 2.An officer of the organization must attest that the IPv4 address 
>> block is needed for and will be used on an operational network.
>> 
>> 3.The maximum transfer size is /20.
>> 
>> 4.Fewer than 5,000 needs attestation transfers have occurred.
>> 
>> Comments:
>> 
>> 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.
> 
> Hi Andrew,
> 
> I think it would be clearer if the line:
> 
> 4.Fewer than 5,000 needs attestation transfers have occurred.
> 
> Was changed to: 
> 
> 4. Fewer than 5,000 transfers under this requirement set have completed.
> 
> But I would support it with the current language. 
> The maximum number of addresses which could be transferred in aggregate
> under this policy is 1.25 /8 equivalents.
> And at the current rate of transfers this would take years.
> Does anybody still fear damaging market manipulation could occur under this
> policy?
> 
> Regards,
> Mike Burns
> IPTrading.com <http://iptrading.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.

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

From mike at iptrading.com  Thu Mar 12 14:22:05 2015
From: mike at iptrading.com (Mike Burns)
Date: Thu, 12 Mar 2015 14:22:05 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for
	some IPv4 Transfers - Revised
In-Reply-To: <F83FA862-9FBE-4E3A-ABC5-DC0EDD3DCF15@delong.com>
References: <54ECB219.7030707@arin.net> <5500610E.1070107@quark.net>
	<026801d05cd6$8302cd20$89086760$@iptrading.com>
	<F83FA862-9FBE-4E3A-ABC5-DC0EDD3DCF15@delong.com>
Message-ID: <02fc01d05cf1$71d45940$557d0bc0$@iptrading.com>

Your proposed language is clearer in the context of policy development, but would lack clarity when placed in the NRPM as ?this requirement? becomes somewhat ambiguous.

 

Hi Owen,

 

It should be read not as ?this requirement? but as ?this requirement set?. Maybe it should read:

 

In addition, the recipient must meet one of the following requirement-sets:

 

...

4.Fewer than 5,000 transfers have completed under this requirement-set

 

?

 

Or the two requirement sets might be labeled clearly as the ?Needs-tested? option and the ?Needs-attested? option.

This comports with the current language of Line 4.

But so long as it is clear to everyone who considers the proposal I am fine with the current language.

 

Regards,
Mike

 

 

 

 

From: Owen DeLong [mailto:owen at delong.com] 
Sent: Thursday, March 12, 2015 1:55 PM
To: Mike Burns
Cc: andrew.dul at quark.net; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-14: Needs Attestation for some IPv4 Transfers - Revised

 

Mike,

 

Your proposed language is clearer in the context of policy development, but would lack clarity when placed in the NRPM as ?this requirement? becomes somewhat ambiguous.

 

Owen

 

On Mar 12, 2015, at 08:08 , Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

 

On 2/24/2015 9:17 AM, ARIN wrote:



ARIN-2014-14 has been revised. This draft policy is open for 
discussion on this mailing list.

ARIN-2014-14 is below and can be found at:
https://www.arin.net/policy/proposals/2014_14.html

Regards,

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


## * ##


Draft Policy ARIN-2014-14
Needs Attestation for some IPv4 Transfers

Date: 24 Feb 2015

Problem Statement:

The process of 'needs testing' or 'needs basis' allocation has evolved 
over the history of the Internet registry system. The earliest number 
resource policy required that an operator intend to use the number 
resources on an operational Internet Protocol network before the 
resource would be registered to an organization. Organizations were 
assigned either a Class A, B, or C block roughly depending on the 
organization's size. With the implementation of CIDR, additional 
'needs testing' was done to right size allocations to fit 
organizations. These testing requirements continued to evolve under 
various organizations prior to the RIRs inception and then later 
formally under the RIR's policy development process.

In the 2000s, ARIN began a systematic "trust but verify" process for
IPv4 requests. This was necessary due to both IPv4 address 
registration hijackings in ARIN Whois and the accelerated amount of 
systematic fraud being perpetrated on ARIN.

As IPv4 exhaustion occurred, some RIRs have reconsidered the necessity 
of some of the needs testing requirements and implemented policies 
which reduced the requirements on organizations to show need or 
utilization for some transfer transactions with the RIR.

The cost of performing a needs assessment and auditing of this 
information vs. the public benefit of restricting allocations to 
specifically qualified organizations has been noted by some 
organizations to be out of alignment. The ability to predict future 
use toward a 24-month utilization rate can also be challenging for 
some organizations and relies on projections and estimates rather than 
verifiable facts. Thus, the current needs testing requirements may be 
more than is necessary and desirable for small transfers. This policy 
seeks to reduce the complexity of transfers by removing the 
utilization needs testing requirement and replacing it with a needs 
attestation by a corporate officer.

Additionally, other requirements are placed around the 'needs 
attestation only' requirement to reduce the Number Resource 
Community's concern that this type of policy could be abused for 
speculation or hording. Furthermore, the policy includes a sunset 
clause to limit the total number of transfers under this policy 
proposal. This sunset is intended to force the community to reexamine 
the success or failure of the practices contained in this policy proposal.

Policy statement:

Section 8.3

Replace the 'Conditions on recipient of the transfer' with the 
following conditions.

Conditions on recipient of the transfer:

 The organization must sign an RSA.

 The resources transferred will be subject to current ARIN policies.

In addition, the recipient must meet one of the following requirements
sets:



 

 


1. The organization must demonstrate the need for up to a 24-month 
supply of IP address resources under current ARIN policies.

OR

1.The organization, its parent(s), or subsidiary organizations, must 
not have received IPv4 address resources, via transfer, within the 
past 12 months.

2.An officer of the organization must attest that the IPv4 address 
block is needed for and will be used on an operational network.

3.The maximum transfer size is /20.

4.Fewer than 5,000 needs attestation transfers have occurred.


Section 8.4

Replace the 'Conditions on recipient of the transfer' with the 
following conditions.

Conditions on recipient of the transfer:

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

 Recipients within the ARIN region will be subject to current ARIN
 policies and sign an RSA for the resources being received.

 The minimum transfer size is a /24.

In addition, the recipient must meet one of the following requirements
sets:

1. The organization must demonstrate the need for up to a 24-month 
supply of IP address resources under current ARIN policies.

OR

1.The organization, its parent(s), or subsidiary organizations, must 
not have received IPv4 address resources, via transfer, within the 
past 12 months.

2.An officer of the organization must attest that the IPv4 address 
block is needed for and will be used on an operational network.

3.The maximum transfer size is /20.

4.Fewer than 5,000 needs attestation transfers have occurred.

Comments:

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


Hi Andrew,

I think it would be clearer if the line:

4.Fewer than 5,000 needs attestation transfers have occurred.

Was changed to: 

4. Fewer than 5,000 transfers under this requirement set have completed.

But I would support it with the current language. 
The maximum number of addresses which could be transferred in aggregate
under this policy is 1.25 /8 equivalents.
And at the current rate of transfers this would take years.
Does anybody still fear damaging market manipulation could occur under this
policy?

Regards,
Mike Burns
 <http://iptrading.com/> IPTrading.com

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ( <mailto:ARIN-PPML at arin.net> 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  <mailto:info at arin.net> 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/20150312/8ffaf3b1/attachment.htm>

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

Total of 5 messages in the last 7 days.
 
script run at: Fri Mar 13 00:53:03 EDT 2015
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 40.00% |    2 | 40.30% |    43077 | mike at iptrading.com
 20.00% |    1 | 42.40% |    45328 | owen at delong.com
 20.00% |    1 | 11.20% |    11972 | andrew.dul at quark.net
 20.00% |    1 |  6.10% |     6519 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    5 |100.00% |   106896 | Total



From info at arin.net  Thu Mar 19 10:57:46 2015
From: info at arin.net (ARIN)
Date: Thu, 19 Mar 2015 10:57:46 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - February 2015
In-Reply-To: <54ECBACB.4010102@arin.net>
References: <54ECBACB.4010102@arin.net>
Message-ID: <550AE3EA.8050008@arin.net>

> The AC abandoned 2014-19. Anyone dissatisfied with this decision may
> initiate a petition. The deadline to begin a petition will be five
> business days after the AC's draft meeting minutes are published.

The minutes from the ARIN Advisory Council's 19 February meeting have
been published:
https://www.arin.net/about_us/ac/ac2015_0219.html

The petition deadline is 26 March 2015.

For more information on starting and participating in petitions, see PDP
Petitions at: https://www.arin.net/policy/pdp_petitions.html

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

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

Regards,

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






On 2/24/15 12:54 PM, ARIN wrote:
> In accordance with the ARIN Policy Development Process (PDP), the ARIN
> Advisory Council (AC) met on 19 February 2015.
>
> The AC moved the following to last call (to be posted separately to last
> call):
>
>    Recommended Draft Policy ARIN-2014-17: Change Utilization
> Requirements from last-allocation to total-aggregate
>
> The AC abandoned the following:
>
>    Recommended Draft Policy ARIN-2014-19: New MDN Allocation Based on
> Past Utilization
>
> The AC provided the following statement:
> "The ARIN AC abandoned Recommended Draft Policy ARIN-2014-19: New MDN
> Allocation Based on Past Utilization.  In the process of investigating
> and working on this policy the AC discovered that ARIN staff practice is
> already consistent with the language in this policy proposal, and as a
> result this policy would not change current ARIN staff practice.  In
> particular, if an MDN has a 1 year utilization history then it is not a
> new MDN and would be treated as an existing MDN.  The AC has noted,
> however, that some clarification of the MDN policy and current staff
> procedures is needed in the NRPM, and has requested that ARIN staff
> update online documentation to clarify existing staff practice around
> MDN policy."
>
> The AC is continuing to work on:
>
>    Recommended Draft Policy ARIN-2014-1: Out of Region Use
>    Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text
>    Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers
>    Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4
>    Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10
>
> The AC abandoned 2014-19. Anyone dissatisfied with this decision may
> initiate a petition. The deadline to begin a petition will be five
> business days after the AC's draft meeting minutes are published. For
> more information on starting and participating in petitions, see PDP
> Petitions at:
> https://www.arin.net/policy/pdp_petitions.html
>
> Draft Policy and Proposal texts are available at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)



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

Total of 2 messages in the last 7 days.
 
script run at: Fri Mar 20 00:53:02 EDT 2015
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    1 | 53.71% |     7632 | info at arin.net
 50.00% |    1 | 46.29% |     6578 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    2 |100.00% |    14210 | Total



From desiree at relax.co.uk  Mon Mar 23 13:46:44 2015
From: desiree at relax.co.uk (Desiree)
Date: Mon, 23 Mar 2015 17:46:44 +0000
Subject: [arin-ppml] Survey on Trust in RIRs
Message-ID: <5A0E9028-E896-4981-9577-FBBF2820A189@relax.co.uk>

Hi

As part of my research on Trust in Internet governance, I would hugely
appreciate up to 15 minutes of your time, that you will never get back,
to complete a short survey on Trust in RIRs.

The survey was launched on March 20th and it ends on March 30th, 2015.
This is *not* an RIR-initiated survey.

The survey is part of University of Malta's Program in Internet
governance, designed to conduct research into the trust that members
have in the RIR's work and overall governance processes. The RIR and
their members have done a huge amount of good work during the past year
on the IANA Stewardship Transition Process. This work is very important
and will be ongoing. A number of issues will arise; two of them being
Governance and Trust. This study examines existing views as a
contribution to the overall work.

Participants are given an absolute assurance of individual confidentiality.

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

Apologies for any cross-posting to members.

Thank you so much in advance for taking part in this!

Desiree Miloshevic
--


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

From info at arin.net  Tue Mar 24 15:33:38 2015
From: info at arin.net (ARIN)
Date: Tue, 24 Mar 2015 15:33:38 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - March 2015
Message-ID: <5511BC12.0@arin.net>

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

The AC recommended the following to the ARIN Board for adoption:

   Recommended Draft Policy ARIN-2014-17: Change Utilization 
Requirements from last-allocation to total-aggregate

Having found the following Draft Policies to be fully developed and
meeting ARIN's Principles of Internet Number Resource Policy, the AC
recommended them for adoption; they will be posted as Recommended Draft
Polices for discussion:

   Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text
   Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4
   Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10

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

   ARIN-prop-215 Modification to Criteria for IPv6 Initial End-User 
Assignments

The AC is continuing to work on:

   Recommended Draft Policy ARIN-2014-1: Out of Region Use (the AC 
reaffirmed this as a Recommended Draft Policy)
   Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

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


From info at arin.net  Tue Mar 24 15:33:53 2015
From: info at arin.net (ARIN)
Date: Tue, 24 Mar 2015 15:33:53 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-6: Remove
 Operational Reverse DNS Text
Message-ID: <5511BC21.407@arin.net>

Recommended Draft Policy ARIN-2014-6
Remove Operational Reverse DNS Text

On 19 March 2015 the ARIN Advisory Council (AC) recommended
ARIN-2014-6 for adoption, making it a Recommended Draft Policy.

ARIN-2014-6 is below and can be found at:
https://www.arin.net/policy/proposals/2014_6.html

You are encouraged to discuss Draft Policy 2014-6 on the PPML prior to
the upcoming ARIN Public Policy Consultation at ARIN 35 in San Francisco 
in April 2015. Both the discussion on the list and at the meeting will 
be used by the ARIN Advisory Council to determine the community 
consensus for adopting this as policy.

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

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

Regards,

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


## * ##


Recommended Draft Policy ARIN-2014-6
Remove Operational Reverse DNS Text (was: Remove 7.1)

Date: 21 January 2014

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

2014-6 enables fair and impartial number resource administration by 
removing technical statements that are not related to number policy from 
the NRPM. It is technically sound to remove operational practice from 
the NRPM; indeed this act serves as a forcing function for a best 
practices document that is both more detailed and more approachable than 
the policy statement that was removed. Discussion of the previous 
revision of 2014-6 centered around "why are you fixing this for IPv4 and 
not IPv6", and the most recent changes reflect that community feedback. 
There has not been notable opposition to the notion of removing 
operational language from the NRPM.

Problem Statement:

7.1 attempts to assert rules on rDNS management at ARIN. It fails to do 
so because it only addresses in-addr.arpa (missing equally important 
rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary 
decision made by ARIN technical staff. We should remove this text from 
policy, as it represents operational practice rather than ARIN number 
policy.

In feedback received at public policy meetings and on the PPML mailing 
list, the Community expressed a desire for IPv4 and IPv6 policy on 
reverse DNS to be congruent (that is to say, it makes no sense to remove 
7.1 without addressing 6.5.6 which is similarly operationally 
prescriptive) and bring this proposal forward again.

Policy statement:

Remove 7.1

Remove 6.5.6

Comments:

a.Timetable for implementation: Immediate

b.Anything else:
7.1. Maintaining IN-ADDRs

All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses 
from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain 
records for their respective customers. For blocks smaller than /16, and 
for the segment of larger blocks  smaller than /16, ARIN can maintain 
IN-ADDRs.

6.5.6. Reverse lookup

When an RIR delegates IPv6 address space to an organization, it also 
delegates the responsibility to manage the reverse lookup zone that 
corresponds to the allocated IPv6 address space. Each organization 
should properly manage its reverse lookup zone. When making an address 
assignment, the organization must delegate to an assignee organization, 
upon request, the responsibility to manage the reverse lookup zone that 
corresponds to the assigned address.

#####

ARIN STAFF & LEGAL ASSESSMENT

Draft Policy ARIN-2014-6
Remove Operational Reverse DNS Text

Date of Assessment: March 17, 2015

1. Summary (Staff Understanding)
This proposal would remove 6.5.6 and 7.1, thus removing reverse DNS 
language from the NRPM.

2. Comments
A. ARIN Staff Comments
This change to NRPM will not change the DNS service that ARIN performs. 
This proposal can be implemented as written.

ARIN registration services staff occasionally receives a telephone or 
email inquiry asking how reverse DNS services can be set up for a 
company. In the cases the company is a downstream customer of an ISP who 
has received a direct allocation from ARIN, staff explains this service 
can be set up for them by their service provider. On rare occasion, the 
company presses for a reference that states this is done by their ISP, 
and not ARIN. In those cases staff will refer them to the language 
currently in the NRPM.

In the case the language is removed from NRPM, ARIN staff will create a 
resource for the ARIN public website that describes how ARIN's Reverse 
DNS services are provided; including who is able to establish Reverse 
DNS service for different types of registration records.

B. ARIN General Counsel ? Legal Assessment
The policy does not create legal concerns.

3. Resource Impact
This policy would have minimal impact from an implementation standpoint. 
It is estimated implementation would occur within 3 months after 
ratification by the ARIN Board of Trustees. The following tasks will be 
completed for implementation:
Versioned change to NRPM
Updated guidelines on ARIN website describing reverse DNS services (to 
act as general information resource and serve as new reference point for 
situation described in staff comments).
Staff training

4. Proposal / Draft Policy Text Assessed

Draft Policy ARIN-2014-6
Remove Operational Reverse DNS Text (was: Remove 7.1)

Date: 21 January 2015

Problem Statement:

7.1 attempts to assert rules on rDNS management at ARIN. It fails to do 
so because it only addresses in-addr.arpa (missing equally important 
rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary 
decision made by ARIN technical staff. We should remove this text from 
policy, as it represents operational practice rather than ARIN number 
policy.

In feedback received at public policy meetings and on the PPML mailing 
list, the Community expressed a desire for IPv4 and IPv6 policy on 
reverse DNS to be congruent (that is to say, it makes no sense to remove 
7.1 without addressing 6.5.6 which is similarly operationally 
prescriptive) and bring this proposal forward again.

Policy statement:

Remove 7.1

Remove 6.5.6

Comments:

a.Timetable for implementation: Immediate

b.Anything else:

7.1. Maintaining IN-ADDRs

All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses 
from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain 
records for their respective customers. For blocks smaller than /16, and 
for the segment of larger blocks smaller than /16, ARIN can maintain 
IN-ADDRs.

6.5.6. Reverse lookup

When an RIR delegates IPv6 address space to an organization, it also 
delegates the responsibility to manage the reverse lookup zone that 
corresponds to the allocated IPv6 address space. Each organization 
should properly manage its reverse lookup zone. When making an address 
assignment, the organization must delegate to an assignee organization, 
upon request, the responsibility to manage the reverse lookup zone that 
corresponds to the assigned address.


From info at arin.net  Tue Mar 24 15:34:07 2015
From: info at arin.net (ARIN)
Date: Tue, 24 Mar 2015 15:34:07 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-21: Modification to
 CI Pool Size per Section 4.4
Message-ID: <5511BC2F.8090109@arin.net>

Recommended Draft Policy ARIN-2014-21
Modification to CI Pool Size per Section 4.4

On 19 March 2015 the ARIN Advisory Council (AC) recommended
ARIN-2014-21 for adoption, making it a Recommended Draft Policy.

ARIN-2014-21 is below and can be found at:
https://www.arin.net/policy/proposals/2014_21.html

You are encouraged to discuss Draft Policy 2014-21 on the PPML prior to
the upcoming ARIN Public Policy Consultation at ARIN 35 in San Francisco 
in April 2015. Both the discussion on the list and at the meeting will 
be used by the ARIN Advisory Council to determine the community 
consensus for adopting this as policy.

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

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

Regards,

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


## * ##


Recommended Draft Policy ARIN-2014-21
Modification to CI Pool Size per Section 4.4

Date: 25 November 2014

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

This proposal enables fair and impartial number resource administration 
by ensuring IPv4 resources are available for critical infrastructure and 
Internet Exchanges in particular after IPv4 resources are no longer 
readily available from the ARIN free pool. This benefits more than just 
the individual organizations receiving these resources; it benefits the 
entire Internet Community by contributing to the stability and 
scalability of the Internet as a whole. This proposal is technically 
sound and is supported by the community.

Problem Statement:

At the time that this section of policy was written, IXP growth in North 
America was stagnant. Efforts of late have increased significantly 
within the IXP standards and other communities to improve critical 
infrastructure in North America. This effort is paying dividends and we 
project that a /16 will not be enough to continue to improve global 
interconnect conditions and support needed IXP CI infrastructure.

Policy statement:

Change to text in section 4.4 Micro Allocations:

Current text:

ARIN will place an equivalent of a /16 of IPv4 address space in a 
reserve for Critical Infrastructure, as defined in section 4.4. If at 
the end of the policy term there is unused address space remaining in 
this pool, ARIN staff is authorized to utilize this space in a manner 
consistent with community expectations.

Proposed text to replace current text entirely:

ARIN will place an equivalent of a /15 of IPv4 address space in a 
reserve for Critical Infrastructure, as defined in section 4.4.

Timetable for implementation: Immediate

#####

ARIN STAFF ASSESSMENT

Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4
Date of Assessment: 14 January 2015

1. Summary (Staff Understanding)

This policy changes one section of existing NRPM policy 4.4 to extend 
the current reservation size for critical infrastructure and exchange 
points from a /16 equivalent to a /15 equivalent.


2. Comments

A. ARIN Staff Comments

? For informational purposes:
? A total of 35 /24s have been issued from the reserved /16 equivalent 
for CI and IXPs since the policy was amended and implemented on 20 March 
2013, leaving 221 /24s available in this reserved block.

? There are currently 381 free /24s remaining in the two /8 ranges used 
for CI and IXP micro-allocations.

? This policy could be implemented as written.


B. ARIN General Counsel - Legal Assessment

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect. It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:
? Updated guidelines and internal procedures
? Staff training

4. Proposal/Draft Policy Text Assessed
Draft Policy ARIN-2014-21
Modification to CI Pool Size per Section 4.4
Date: 25 November 2014
Problem Statement:
At the time that this section of policy was written, IXP growth in North 
America was stagnant. Efforts of late have increased significantly 
within the IXP standards and other communities to improve critical 
infrastructure in North America. This effort is paying dividends and we 
project that a /16 will not be enough to continue to improve global 
interconnect conditions and support needed IXP CI infrastructure.
Policy statement:
Change to text in section 4.4 Micro Allocations:
Current text:
ARIN will place an equivalent of a /16 of IPv4 address space in a 
reserve for Critical Infrastructure, as defined in section 4.4. If at 
the end of the policy term there is unused address space remaining in 
this pool, ARIN staff is authorized to utilize this space in a manner 
consistent with community expectations.
Proposed text to replace current text entirely:
ARIN will place an equivalent of a /15 of IPv4 address space in a 
reserve for Critical Infrastructure, as defined in section 4.4.
Search This Section


From info at arin.net  Tue Mar 24 15:34:19 2015
From: info at arin.net (ARIN)
Date: Tue, 24 Mar 2015 15:34:19 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-22: Removal of
 Minimum in Section 4.10
Message-ID: <5511BC3B.9040307@arin.net>

Recommended Draft Policy ARIN-2014-22
Removal of Minimum in Section 4.10

On 19 March 2015 the ARIN Advisory Council (AC) recommended
ARIN-2014-22 for adoption, making it a Recommended Draft Policy.

ARIN-2014-22 is below and can be found at:
https://www.arin.net/policy/proposals/2014_22.html

You are encouraged to discuss Draft Policy 2014-22 on the PPML prior to
the upcoming ARIN Public Policy Consultation at ARIN 35 in San Francisco 
in April 2015. Both the discussion on the list and at the meeting will 
be used by the ARIN Advisory Council to determine the community 
consensus for adopting this as policy.

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

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

Regards,

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


## * ##


Recommended Draft Policy ARIN-2014-22
Removal of Minimum in Section 4.10

Date: 25 November 2014

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

This proposal is technically sound in that it ensures the minimum 
allocation from a section 4.10 (Dedicated IPv4 block to facilitate IPv6 
Deployment) is large enough to be widely accepted on the public Internet 
today. This policy received community and operator support on the public 
policy mailing list and at the February Nanog PPM from many who believe 
that prefixes smaller than /24 will not propagate widely. This proposal 
enables fair and impartial number resource administration by being 
applied to all that request a section 4.10 allocation.

Problem Statement:

The current section 4.10 Dedicated IPv4 block to facilitate IPv6 
Deployment creates an issue where a small new organization that requires 
an IPv4 allocation or assignment would potentially receive a block that 
today would be unroutable and therefore unusable for it intended purposes.

Policy statement:

Change

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

To

"This block will be subject to an allocation of /24. ARIN should use 
sparse allocation when possible within that /10 block."

Timetable for implementation: Immediate

#####

ARIN STAFF ASSESSMENT

Draft Policy ARIN-2014-22
Removal of Minimum in Section 4.10
Date of Assessment: 20 Feb 2015

1. Summary (Staff Understanding)
This proposal will modify existing policy NRPM 4.10 Dedicated IPv4 block 
to facilitate IPv6 deployment. The current policy sets the minimum 
allocation size as /28 to a maximum of /24. This proposal changes the 
allocation size to simply be a /24 with no maximum or minimum.

2. Comments

A. ARIN Staff Comments

? ARIN has issued one /24 from this reserved pool to date.
? This proposal can be implemented as written.

B. ARIN General Counsel - Legal Assessment

? Counsel sees no material legal issue with this proposal.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect. It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:
? Updated guidelines and internal procedures
? Staff training

4. Proposal/Draft Policy Text Assessed
Draft Policy ARIN-2014-22
Removal of Minimum in Section 4.10
Date: 25 November 2014
Problem Statement:
The current section 4.10 Dedicated IPv4 block to facilitate IPv6 
Deployment creates an issue where a small new organization that requires 
an IPv4 allocation or assignment would potentially receive a block that 
today would be unroutable and therefore unusable for it intended purposes.

Policy statement:
Change
"This block will be subject to a minimum size allocation of /28 and a 
maximum size allocation of /24. ARIN should use sparse allocation when 
possible within that /10 block."
To
"This block will be subject to an allocation of /24. ARIN should use 
sparse allocation when possible within that /10 block."
Timetable for implementation: Immediate


From info at arin.net  Tue Mar 24 15:34:35 2015
From: info at arin.net (ARIN)
Date: Tue, 24 Mar 2015 15:34:35 -0400
Subject: [arin-ppml] Draft Policy ARIN-2015-1: Modification to Criteria for
 IPv6 Initial End-User Assignments
Message-ID: <5511BC4B.6050508@arin.net>

Draft Policy ARIN-2015-1
Modification to Criteria for IPv6 Initial End-User Assignments

On 19 March 2015 the ARIN Advisory Council (AC) accepted "ARIN-prop-215 
Modification to Criteria for IPv6 Initial End-User Assignments" as a 
Draft Policy.

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

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

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

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

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

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

Regards,

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


## * ##


Draft Policy ARIN-2015-1
Modification to Criteria for IPv6 Initial End-User Assignments

Date: 24 March 2015

Problem Statement:

Current policy for assignment to end users excludes a class of users 
whose costs to renumber would far exceed what current policy is designed 
to mitigate.

Current measures designed to minimize the economic cost of renumbering 
per NRPM 6.5.8.1 (Initial Assignment Criteria) are:

c. By having a network that makes active use of a minimum of 2000 IPv6 
addresses within 12 months, or;
d. By having a network that makes active use of a minimum of 200 /64 
subnets within 12 months, or;

These two measures fail to take into account end users who have a large 
number of potentially geographically dispersed sites, or sites with low 
subnet and/or user counts. The economic costs for this class of end user 
would likely far exceed the costs that 6.5.8.1 c. and d. are designed to 
mitigate.

While an end user could possibly apply (and receive an assignment) under 
6.5.8.1 e. ("By providing a reasonable technical justification 
indicating why IPv6 addresses from an ISP or other
LIR are unsuitable"), it fails to provide a concrete threshold under 
which this class of end-user can be reasonably assured of receiving 
address space.

Without having the reasonable assurance of IPv6 address number resource 
continuity that a direct assignment allows, many smaller enterprises are 
unlikely to adopt IPv6 (currently perceived as
an already tenuous proposition for most users given current 
cost/benefit); or are likely to adopt technical measures (such as using 
ULA addressing + NAT66) that are widely held to be damaging to the IPv6 
Internet.

Policy Statement:

Replace the contents of NRPM 6.5.8.1 with:

6.5.8.1. Initial Assignment Criteria

Organizations may justify an initial assignment for addressing devices 
directly attached to their own network infrastructure, with an intent 
for the addresses to begin operational use within 12 months, by meeting 
one of the following criteria:

a. Having a previously justified IPv4 end-user assignment from ARIN or 
one of its predecessor registries, or;
b. Currently being IPv6 Multihomed or immediately becoming IPv6 
Multihomed and using an assigned valid global AS number, or;
c. By having a network that makes active use of a minimum of 2000 IPv6 
addresses within 12 months, or;
d. By having a network that makes active use of a minimum of 200 /64 
subnets within 12 months, or;
e. By having a contiguous network that has a minimum of 13 active sites 
within 12 months, or;
f. By providing a reasonable technical justification indicating why IPv6 
addresses from an ISP or other LIR are unsuitable.

Examples of justifications for why addresses from an ISP or other LIR 
may be unsuitable include, but are not limited to:

An organization that operates infrastructure critical to life safety
or the functioning of society can justify the need for an assignment 
based on the fact that renumbering would have a broader than expected 
impact than simply the number of hosts directly involved. These would 
include: hospitals, fire fighting, police, emergency response, power or 
energy distribution, water or waste treatment, traffic management and 
control, etc.

Regardless of the number of hosts directly involved, an organization
can justify the need for an assignment if renumbering would affect 2000 
or more individuals either internal or external to the organization.

An organization with a network not connected to the Internet can
justify the need for an assignment by documenting a need for guaranteed 
uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 
4193).

An organization with a network not connected to the Internet, such as
a VPN overlay network, can justify the need for an assignment if they 
require authoritative delegation of reverse DNS.

Comments:
a. Timetable for implementation: Immediate
b. General Comments:

- Changes to NRPM 6.5.8.1 are to renumber subsection e. to f. and and 
insert a new subsection e. with the following text:

"By having a contiguous network that has a minimum of 13 active sites 
within 12 months, or;

- The threshold of 13 sites was chosen based on NRPM 6.5.8.2, which 
specifies 13 sites as the minimum number of sites required to receive a 
/40 initial assignment, to attempt to provide a balance
between the costs of carrying the prefix vs. the costs to the end-user 
in renumbering.

- Further constraints were added in that the sites must be in a 
contiguous network, to further attempt to reduce the costs of carrying 
the prefix

- By introducing this new threshold, we attempt to restore equivalency 
of number resources for those end-users whose economic costs to renumber 
are equal to that of other end-users who would qualify
for a direct assignment under 6.5.8.1 c. and d.

c. Example:

Example of an end-user who would not qualify under 6.5.8.2 c. or d.:

- 50 locations (IPVPN) spread across the country/continent
- 10 staff per location (average; 500 total)
- 20 devices per location (average; 1000 total)
- 2 subnets (voice & data) per location (average, 100 total)
- Not multihomed
- Currently using RFC1918 IPv4 space + NAT

This end-user only benefits minimally from IPv6 multihoming as they are 
using an IPVPN, and multihoming provides benefit only for Internet 
transit, not within their IPVPN. As such requiring the end-user to 
multihome under NRPM 6.5.8.2 b. is wasteful.

This end user currently uses RFC1918 IPv4 address space + a relatively 
small amount of IPv4 GUA + NAT (currently accepted industry practice for 
IPv4). Changing providers involves only renumbering the small amount of 
IPv4 GUA. Forcing the end-user to acquire an IPv4 direct assignment 
under NRPM 6.5.8.2 a. in order to be able to get a direct IPv6 
assignment is incredibly wasteful of a valuable and limited number 
resource. It also forces the customer occupy more routing table space, 
as now an IPv4 PI prefix must be routed in addition to an IPv6 PI 
prefix, instead of using IPv4 PA + IPv6 PI (where only space for an IPv6 
PI prefix is required).



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

Total of 7 messages in the last 7 days.
 
script run at: Fri Mar 27 00:53:03 EDT 2015
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 71.43% |    5 | 74.69% |    47539 | info at arin.net
 14.29% |    1 | 15.13% |     9628 | desiree at relax.co.uk
 14.29% |    1 | 10.18% |     6480 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    7 |100.00% |    63647 | Total